Modelagem Orientada a Objetos Com a UML - Jose Eduardo Zindel Deboni

8/22/2019 Modelagem Orientada a Objetos Com a UML - Jose Eduardo Zindel Deboni

http://slidepdf.com/reader/full/modelagem-orientada-a-objetos-com-a-uml-jose-eduardo-zindel-deboni 1/902



Dedicatória

Ao meu filho, Murilo, pelo estímulo,carinho e compreensão.



A quem se destina estelivro

Este livro se destina a diferentesclasses de leitores, que tem em comum o

desejo de conhecer técnicas para sedescrever um software, seja porque sãoprofissionais da área da computação,seja porque acreditam que um softwarepossa ajudá-los a melhorar o seunegócio, seja ele qual for. Os leitoresdeste livro podem ser:

· Estudantes e Professores quepodem encontrar neste livro apoio parao desenvolvimento de cursos de

Engenharia de Software, de Análise e



Projeto de Sistemas e para odesenvolvimento de projetos desoftware. Apesar da abordagem dada a

este trabalho não ter uma ênfasedidática, ele pode ser utilizado comouma leitura complementar.Especialmente nos capítulos iniciais,onde o livro tece os fundamentos daorientação a objetos, o teor introdutóriopode ser de grande ajuda a estudantes d

computação e áreas afins.· Analistas de Sistema e

Programadores de Computador

envolvidos em projetos de sistemas desoftware, que encontrarão reunidas nestivro algumas técnicas úteis para o

desenvolvimento de modelos orientados



a objeto destes projetos. A adoçãodestas técnicas pode ajudá-los aconstruir sistemas de software mais

robustos, mais confiáveis e demanutenção mais fácil.

· Usuários ou Gerentes deProjeto de Software que podem adotaralgumas das idéias presentes no livropara facilitar o planejamento de um

projeto de software. A leitura ajudará acriar uma linguagem comum entre ousuário, o gerente de projeto e a equipeécnica de desenvolvimento. Como um

projeto orientado a objetos requer umagrande dose de modelagem, este livropode uniformizar os termos usados nacomunicação com a equipe de projeto e



ajudar a definir as etapas e produtos doprojeto de software.



Convenções adotadasneste livro

Para facilitar a leitura, este livro adotaas seguintes convenções tipográficas:

· Os termos e conceitosmportantes para o texto são escritos em

negrito na primeira vez em que elesaparecem. Estes termos podem ser encontrados novamente no glossário, aofinal do livro, onde recebem uma breve

explicação.· Os comandos e extratos de

código, escritos em linguagem de

programação usam fonte currier, assim



como os nomes de componentes eelementos do modelo, quando citados noexto são escritos também em fonte

currier, para diferenciá-los do seusignificado fora do escopo do programa

· As citações, os extratos de texto

da bibliografia e palavras em línguaestrangeira são escritos com caractér tálico.

· A lista de referênciasbibliográficas escontra-se no final doivro. Quando citadas no texto, as

referências aparecem entre parêntesescom o nome do autor e o ano depublicação. Por exemplo: (Beck, 1999)ou citado por Beck (1999).



· Os endereços de websitescitados no texto e na bibliografia quepodem ser acessados pela internet são

grifados como no exemplo:www.omg.org

http://www.omg.org/



1. Introdução

Este capítulo discute a importância

de se criar um modelo nos projetos desoftware. Inicialmente, apresenta ocaráter dualista do software: ora

roduto da criatividade, ora trabalho

sistemático de engenharia, para entãodiscutir o porquê, em ambos os casos, modelo do software ser colocado nocentro do processo de desenvolvimentocomo forma de unificar a visão dosoftware entre os participantes do

rojeto. O capítulo termina fazendo

uma apresentação do restante do livro



e de como ele pode ser lido.



1.1. Introdução aoDesenvolvimento deSoftware

software é um produto da inteligênciahumana, por meio dele é possível sepreservar uma boa idéia e transmití-lapara muitas outras pessoas. O software

uma das poucas maneiras disponíveiscapazes de capturar o conhecimento dealguém e colocá-lo à serviço de outros.Existem algumas formas para se fazer sso, como os livros ou as aulas nas

escolas, mas nenhuma delas tem acapacidade de interação que o software

oferece, e que pode transformar o



conhecimento capturado, diretamente,em uma habilidade para o seu usuário.Um usuário, de posse de um software

adequadamente contruído, passa a ter novas habilidades e pode fazer coisasque antes não sabia. Esta versatilidade,faz com que haja um grande interesse emconverter conhecimentos e habilidades,cada vez mais complexas, em software.Este livro trata desta conversão, discute

se aqui como se transforma uma idéiaem um software útil. Como se capturauma idéia para que o desenvolvedor crium sistema de software que irá dar esta

habilidade ao usuário:



Figura 1- O software pode

ransformar uma idéia em umahabilidade

Na construção de um software existe

uma boa dose de criatividade, mas háuma dose ainda maior de pensamentoógico e trabalho discipliando. O

computador, uma das maiores invençõesdo homem, é uma mero escravo dosoftware. Todas as maravilhas que umcomputador é capaz de desempenhar,

dependem, diretamente, da



disponibilidade de um softwareprojetado para realizá-las. Além dacriatividade são necessários métodos,

procedimentos e muita disciplina paracriar um software útil. Toda estaorganização é conseqüência da distânciaque separa os computadores doshomens, e das suas idéias. Oscomputadores são meros autômatos,sabem realizar com grande velocidade,

e por repetidas vezes, tarefas simples,escritas em um programa decomputador. Os programas decomputador são seqüências de

comandos simples escritos em umainguagem de programação que pode ser

entendida pelo computador, e que aindaestá muito longe da linguagem humana, e



da complexidade do pensamentohumano.

A distância entre o conhecimentohumano e as linguagens de programaçãose reflete nas inúmeras dificuldadesencontradas durante o desenvolvimento

de um software. Utiliza-se aqui o termosoftware para descrever um conceitomuito mais amplo do que um mero

programa de computador. O sofware,que se refere este livro, compreendeoda a estratégia utilizada para resolver

um problema real com apoio de um

computador. Mais do que uma sérieorganizada de instruções, o softwareatende uma finalidade, serve a umobjetivo do seu utilizador. Nesta visão,



o software se completa ao hardware, ocomputador propriamente dito, e seusequipamentos periféricos, que em

conjunto compõem o que se podechamar de sistema computacional. Oconjunto de partes relativa ao softwareno sistema computacional é o chamadosistema de software.

A atividade de programação de

computadores é apenas uma etapa dorabalho de desenvolvimento de umsoftware. Programar é escrever asolução de um problema, que já está

definida, em uma linguagem que possaser entendida pelo computador.Desenvolver um software compreendeainda muitas outras atividades como a



de analisar o problema que se pretenderesolver, e fazer o design da solução.Desenvolver software é resolver

problemas por intermédio daprogramação de computadores é umaatividade de engenharia, da assimchamada “ Engenharia de Software”.

Engenharia de Software é a ciênciada computação aplicada na

ransformação do computador em umaferramenta de trabalho para os seusutilizadores. Ela é aplicada hoje aosmais diferentes desafios, desde a

manipulação de dados administrativosem um sistema de informação gerencialaté a transmissão de voz e imagem emequipamentos de telecomunicação. O



software é hoje uma tecnologiaonipresente. Do telefone ao despertadorda televisão ao supermercado, do

brinquedo ao avião, do elevador ànternet , o software está presente, dand

uma importante contribuição àprodutividade das empresas e àqualidade de vida das pessoas.

Pressman (1995) destaca a importânci

da Engenharia de Software afirmando,que as práticas de engenharia desoftware se intensificaram com oagravamento dos problemas relativos ao

software:

a) A sofisticação dos problemasultrapassaram a nossa capacidade de

construir software que extraia o



potencial oferecido pelo hardware,

b) Nossa capacidade de construir

software de qualidade não podeacompanhar a demanda por novasaplicações da computação, e

c) Nossa capacidade de manter ossoftware existentes foi ameaçada por projetos ruins e recursos inadequados

Observa-se, nestas considerações, quea Engenharia de Software lidantimamente com as limitações da

capacidade humana em criar software. Ocrescimento do poder dosmicroprocessadores torna mais aparenteos limites da nossa capacidade de

conceber e criar software que aproveite



odo esta potencialidade. As demandascrescentes por parte dos usuáriospressionam os desenvolvedores para

uma luta contra o tempo na busca por bons projetos de software, que possamser construídos e mantidosadequadamente. Os problemas atuais, aserem resolvidos pelo software, nãoapenas se tornaram complexos, elesestão se modificando continuamente, e

se integrando a outros problemas,gualmente complexos, em umarede global de computadores que é anternet . A digitalização da informação

por exemplo, ajuda a criar novasdemandas por software, com apossibilidade da distribuição ampla danformação promovida pela internet .



Aparentemente, a distância entre osdesafios propostos para o software e asinguagens de programação disponíveis

para construí-los é intransponível. Asinguagens se mantém relativamente

simples, com instruções elementares,criando programas de computador ongos, ambígos e sujeitos à muitas

falhas. A principal razão desta limitaçãoé a própria arquitetura das máquinas de

Von Neumann, base de todoscomputadores e processadorescomerciais existentes hoje (Eck, 1995).Este uso, quase universal, da arquitetura

de Von Neumann, como base para oscomputadores é o fator mais importantepara o projeto de linguagens deprogramação, e conseqüentemente, dos



métodos disponíveis para se criar software, como observa Sebesta (1996)

Para se aproximar o mundo dosproblemas reais do universo virtual deum computador é necessário que seselecione um paradigma único, no qual

se possam descrever os problemasreais, ao mesmo tempo, que possuamuma trqadução direta para a linguagem

do computador. A busca desteparadigma pode ser usada para retratar o histórico das linguagens deprogramação desde a sua criação, e

resulta no que hoje são as linguagens deprogramação que se utilizam doparadigma de objetos, as chamadasinguagens orientadas a objetos.



Essencialmente, a programaçãoorientada a objetos busca a solução dosproblemas de software pela

dentificação objetos do mundo real, qusão depois traduzidos em outros objetosde um modelo de software (Sebesta,1996). As linguagens orientadas a objetcomo Java, Delphi, Visual Basic, C++ eC# facilitam esta tradução por seutilizarem dos mesmos fundamentos do

paradigma de objetos que foram usadosna modelagem. A disponibilidade eampla divulgação destas linguages sãoas grandes motivadoras para a evolução

da análise e do projeto de sistemasorientados a objeto, como tentativaspara se transpor o abismo entre as boasdéias e o software que as



mplementaria.

Este livro objetiva capacitar analistas

programadores e gerentes de projeto desoftware na construção de um modeloorientado a objetos de um problema domundo real. A principal meta deste

rabalho é organizar um conjuntocoerente de técnicas de análise e projetode sistemas orientados a objetos, de

modo que o modelo construído por estasécnicas sirva de ponte para aconstrução do software.



1.2. Como este livroestá organizado

Para cumprir os objetivos propostospara este livro, a construção de modelo

de um sistema de software foi divididaem 6 capítulos, um glossário de termos um apêndice, que são descritos a seguir

Capítulo 1 – Introdução. Apresentaesta introdução aos objetivos do livro, aorganização proposta, como ele pode

ser lido, o seu público alvo e destaca amportância da modelagem para odesenvolvimento de software.

Capítulo 2 - Fundamentos da



Modelagem Orientada a Objetos.Apresenta os conceitos fundamentais daorientação a objetos e a sua relação com

o processo de desenvolvimento desoftware. As características que diferema abordagem de objetos das outrasabordagens são aqui descritas comdetalhe. Os conceitos deencapsulamento, herança, mensagens epolimorfismo são definidos e

exemplificados por uma aplicaçãosimples de automação comercial. É umcapítulo de leitura obrigatória paraquem deseja revisar os conceitos da

ecnologia de objetos e conhecer anomenclatura utilizada no restante doivro. Aos leitores que já possuem estes

conceitos, a leitura deste capítulo pode



ser dispensada.

Capítulo 3 - O Modelo de Contexto.

Apresenta o primeiro modelo a ser desenvolvido para uma abordagemnicial de um problema de software. O

modelo de contexto é um modelo altonível baseado na análise funcional, quevisa definir a fronteira do sistema e osseus objetivos principais. Neste modelo

são utilizados os diagramas de casos deuso propostos por Jacobson (1992) eadotados porteriormente pelaUML (Jacobson, 1998). A fronteira

sola o sistema de software doscomponentes externos ao software, masque interagem com ele. Este capítulo éespecialmente importante para os



eitores envolvidos nas definiçõesniciais de um sistema computacional,

que devem, em contato direto com os

clientes do software, especificar osrequisitos do sistema.

Capítulo 4 - O Modelo Conceitualapresentado é baseado nos cartões CRCDescreve a técnica dos cartõesCRC aplicada na definição inicial de um

sistema orientado a objetos. Esta técnicautiliza cartões comuns de arquivo pararepresentar os objetos, e ajudam nadistribuição das funcionalidades

esperadas entre os objetos do modelo.Este capítulo é recomendado para oseitores envolvidos na concepção de

sistemas, com experiência ou não em



sistemas não orientados a objetos e quedevem passar a "pensar" em objetos.

ão é um capítulo essencial para quem

á posssui os conceitos de objetos bemconsolidados. Mesmo neste caso esteeitores podem se servir da técnica dos

cartões CRC como um método quepermite envolver os clientes e usuáriosno levantamento de requsitos de projetoe no processo de concepção do

software.Capítulo 5 - O Modelo de Detalhado

de Objetos. Descreve, finalmente, os

diagramas do modelo orientado aobjetos na notação proposta pela UML:diagrama de classes, estados, seqüênciaatividades, colaboração, componentes e



distribuição. Cada diagrama é descritoem conjunto com seus elementoscomponentes e aplicado em diversos

exemplos, que permitem ao leitor visualizar as diversas alternativas dasua aplicação na modelagem desistemas. É um capítulo essencial para acompreensão da notação e dos detalhesconstrutivos dos diversos diagramas quecompõem os modelos orientados a

objeto.Capítulo 6 – Estudo de Casos.

Aplica os modelos apresentados nos

capítulos 3, 4 e 5 em três estudos decaso. Inicialmente o estudo de caso daaplicação comercial do capítulo 2 érevisado, assim como o exemplo do



ogo da forca utilizado no capítulo 4, e oexemplo de estoque do capítulo 5.Desenvolvido com uma visão didática,

ele permite ao leitor compreender antegração que existe entre os modelos e

diagramas. O leitor pode, se desejar,niciar a leitura do livro por este

capítulo tendo uma abordagem inicialmais prática, para dai se aprofundar nosassuntos de maior interesse nos

capítulos anteriores.Um Glossário finaliza o trabalho

istando os principais termos utilizados

na modelagem orientada a objetos.Como alguns destes termos pode ter umsignificado diferente fora do contexto damodelagem, o glossário deve ser



consultado sempre que surgir dúvida emalgum termo durante a leitura do texto.

O Apêndice mostra o resultador daradução dos modelos da UML em

códigos Java, transformando osexemplos em aplicações completas. Láencontram-se os códigos dos programase o endereço do website para executá-os. Todos os exemplos usados ao longo

do texo estão disponíveis para acessopela internet .

São várias as possibilidades de leitura

do texto do livro, e elas estãoesquematizadas na figura abaixo,partindo do interesse do leitor por umavisão teórica, uma visão prática ou por



um interesse específico por algum tema:

Figura 2 - Encadeamento possível ara leitura dos capítulos

Pode-se iniciar a leitura pelo Capítulo

2 para os que desejam consolidar os



fundamentos da orientação a objetos. Noentanto, se os leitores já são familiares estes conceitos, podem utilizar este

capítulo para familiarizarem-se com anomenclatura utilizada no restante doexto. Os capítulos 3, 4 e 5 sãorelativamente independentes por seratarem de 3 modelos que diferem em

escala e objetivo. Podem, por isso, ter uma leitura independente, mas que em

conjunto apresentam as possibildades dmodelagem que a orientação a objetosnos oferece. A leitura seqüencial desterês capítulos favorece o entendimento

da evolução dos modelos que ocorre,naturalmente, durante o desenvolvimentode um sistema de software. Entretando,se o objetivo do leitor é apenas criar



uma especificação de alto nível dosistema pode interromper a sua leiturano capítulo 3. Se além do modelo de

especificação deseja umaprofundamento dos conceitos dosistema em um modeloconceitual preliminar, ou se estiver diretamente envolvido na análise dosistema, deve continuar sua leitura pelocapítulo 4. O capítulo 5 se destina aos

eitores que desejam compreender osdetalhes de um modelo orientado aobjetos criado com a notação da UML,provavelmente por estarem envolvidos

nas etapas de design e construção desoftware. Uma alternativa possível parao leitor que desejar uma visão rápidadas técnicas de modelagem apresentada



aqui é ir diretamente para o capítulo 6 eutilizar-se das referências citadas nestecapítulo para um aprofundamento nos

tens de maior interesse nos capítulosanteriores. Se no decorrer da leiturahouver dúvida sobre algum termoécnico empregado, o leitor pode

procurar uma explicação no glossário dermos.

Com esta organização é possívelcobrir várias possibilidades deabordagem da orientação a objetos,desde uma abordagem mais formal, até

uma abordagem mais prática e informalCom um grande número de exemplos,procura-se sempre apresentar asaplicações típicas dos conceitos



apresentados. O leitor deve, entretanto,manter-se atento à limitação dosexemplos propostos e imaginar como

utilizar estes conceitos em seus próprioproblemas e aplicações.



1.3. A importânciada modelagem

É fácil observar que outras áreas doconhecimento, as outras disciplinas de

engenharia, usam extensivamente damodelagem para representar seusprojetos. A figura clássica de umengenheiro civil é alguém envolvidocom plantas e diagramas, gerenciandouma construção. Uma planta de uma obrcivil é uma representação gráfica do

produto final, o edifício. A plantapermite que o cliente avalie o produto egaranta que o resultado final é muitopróximo do que ele deseja. A

capacidade de gerenciamento da



ndústria da construção civil, permiteuma razoável precisão na data deentrega das obras graças à padronização

de processos de construção e a umantensa padronização de componentes.

Com exceção talvez apenas daalvenaria, uma edificação é composta dpartes já construídas e que sãontegradas para formar o produto final.

Estas partes pré-fabricadas são os

objetos da construção civil.A engenharia mecânica, na indústria

automobilística por exemplo, é uma

ndústria com um alto nível deautomação, padronização eespecialização. Um carro é fruto de umprojeto básico que define os



requisitos para os projetos de cadapeça. Ele movimenta uma grandemercado para as indústrias de auto-

peças que criam, isoladamente, osobjetos individuais do carro. Aconstrução do carro é uma montagem,uma integração de objetos.

A engenharia de software procurarazer para a ciência da computação

estas lições, e incentivar a elaboraçãode um projeto de software, em ummodelo orientado a objetos. Visando apadronização de componentes de

software, o projeto e o processo dedesenvolvimento são desenvolvidossegundo a orientação de se criar objetos

Projetar software nada mais é do que



construir um modelo do software. Ummodelo que representa,simplificadamente, o que se pretende

construir, como uma planta de umaresidência. Um modelo que mostra nãosó os requisitos do problema masambém como eles serão atendidos peloelementos da solução. Um modelo quepermita avaliar a qualidade da solução simular o resultado final, de modo que

projetista, cliente, construtor tenhamodos uma mesma visão do projeto.

O processso de desenvolvimento de

software é um processo composto nãoapenas de componentes tecnológicos.Uma componente importante, e decisivapara o sucesso de um empreendimento,



a componente social. A componenteecnológica nos projetos de software seencontra, principalmente, nas atividades

de contrução do software. Acomponente social está ligada aorelacionamento entre o usuário e odesenvolvedor, e uma parcelamportante da interação do usuário com

o software. Pfleeger (1999) afirma que sucesso do software depende mais até

do sucesso das interações sociais do quda aplicação da tecnologia. Não se deveesquecer que software é desenvolvidopor pessoas para ser utilizado por outra

pessoas. A interação do software é umanteração entre pessoas, mediada pelaecnologia.



A qualidade de um software pode ser avaliada pela satisfação do cliente. Ocliente que se serve do software cria, ao

estabelecer os requisitos de umsoftware, uma expectativa que só verárealizada quando o software estiver concluído. Ao desenvolvedor cabecaptar e atender estas expectativas comas possibilidades de realização. Parasso cliente deve contar, desde o início

com um modelo do software.Este trabalho objetiva auxiliar os

desenvolvedores na criação de modelos

orientados a objetos dos sistemas desoftware. A principal proposta évalorizar a atividade de criação domodelo para reduzir a incerteza do



software, aproximar a expectativa darealização, facilitar a padronização e aautomação dos projetos, incentivar a

reutilização dos componentes desoftware e aumentar a maturidade daengenharia de software nas equipes deprojeto.



2. Fundamentos

da ModelagemOrientada a

Objetos

Este capítulo descreve os conceitosundamentais da modelagem orientada

a objetos por intermédio de umexemplo de aplicação. O exemplomostra a herança, o encapsulamento ea troca de mensagens entre os objetos

sob um ponto de vista prático.



presenta ainda as característicasrincipais do processo de

desenvolvimento de software, os fluxos

de trabalho e a importância damodelagem de objetos presentes neste

rocesso.



2.1. Processo deDesenvolvimento deSoftware

O desenvolvimento de um softwaredepende de muito trabalho disciplinadoTer uma boa idéia para um software sónão basta, ela deve vir acompanhada da

organização e da disposição necessáriapara realizar o trabalho de transformá-lem um produto. Um sistema de softwareé resultado da união da criatividade , daecnologia e do trabalho organizado. Um

não funciona bem sem os demais. Aecnologia sozinha não resolve os

problemas, o esforço solitário fica



solado se não for criativo. O que une aecnologia com a criatividade e

direciona o trabalho é uma idéia comum

uma visão, representada em um modelo.Estudando-se as etapas para transformaruma idéia em um produto de software,verifica-se a importância em criar ummodelo.

Os métodos para desenvolvimento de

software descrevem a organizaçãonecessária para se criar um software.Métodos sugerem passos a seremseguidos para cumprir o vazio existente

entre a idéia e o produto de software.Este estudo não pretende desenvolver um novo método, nem tão pouco indicarum determinado método como sendo o



mais adequado. Pretende sim destacar algumas propriedades presentes emodos os métodos, e observar que as

écnicas de modelagem estão no centrodos métodos, e dão a sustentaçãonecessária para a edificação dosoftware.

Os métodos são organizados em fases,que caracterizam as etapas de evolução

pelas quais o software deve passar. Emcada fase uma série de atividades sãorealizadas, produzindo documentos,esquemas e diagramas que finalizam no

código do programa de computador.Sobre cada um destes subprodutos dométodo de desenvolvimento podem ser realizados testes, para garantir que se



está evoluindo na direção prevista, ecom a qualidade esperada.

Ao avaliar as etapas de um projeto desoftware, observa-se que elas não sãomuito diferentes das etapas de qualquer outro projeto típico de engenharia.

Como todo projeto de engenharia, oprojeto de software tem como principalobjetivo resolver um problema. A

solução do problema irá trazer benefícios para os usuários do produtodo projeto, no caso, o software. Asolução do problema, no caso da

engenharia de software, é o própriosistema de software.

Identificar os objetivos e reconhecer



os requisitos do problema são asatividades realizadas na fase de análiseOs requisitos variam de caso para caso,

e dependem de um bom entendimento daárea de conhecimento na qual serádesenvolvida o projeto, das condiçõesniciais e das necessidades dos clientes

Pode-se dizer que a análise serve parase formular o problema que o sistemará resolver. Conhecidos os requisitos e

as necessidades do cliente pode-seelaborar uma estratégia para resolver oproblema, ou fazer, o que se chama aquido design da solução. Na fase de

design são tomadas todas as decisõesque envolvem a solução do problema, ea partir dele inicia-se a construção dos

componentes da solução. Este



componentes podem ser novos oureutilizados de outros projetos, jáestados e aprovados. Com os

componentes da solução disponíveisrealiza-se a integração que colocaodas as partes juntas para se obter oproduto final. É interessante notar queesta descrição aplica-se igualmente àconstrução de umar edificação, umprojeto de instalação elétrica ou um

projeto mecânico qualquer. Estacoincidência sugere uma grandesemelhança na organização dasatividades de engenharia seja qual for a

disciplina.

Um elemento importante e presente emodos os projetos de engenharia são as



plantas de engenharia. Todo projeto deengenharia é realizado sobre uma plantaque é uma representação gráfica

minuciosa do que se pretende construir.Sobre a planta são avaliadas possíveisalternativas de solução, tomadas asdecisões de projeto e a partir dela sãoobtidas as orientações para a construçãodo produto. A planta é, essencialmente,um elemento de comunicação entre os

participantes do projeto. A plantarepresenta o projeto de uma formasimplificada, é um modelo do sistemafinal.

Os modelos são contruídos para ajudaa entender um problema e paracomunicar este entendimento a outros. A



simplicidade, própria dos modelos,permite apenas que ele represente asnformações importantes, deixando de

ado detalhes que dificultem acompreensão do problema. Entendido oproblema, o analista pode utilizar omodelo para comunicar ao cliente o queentendeu e como pretende resolvê-lo. Oprojetista comunica, por um modelo,como deverão ser construídos os

componentes e como estes serãontegrados na solução. Terminado oprojeto, o modelo ainda ajuda acomunicar aos responsáveis pela

operação e manutenção do sistema, oscuidados que devem ser tomados ao serealizar uma modificação ou um reparono sistema. Como é uma poderosa



ferramenta de comunicação o modelodeve ser representado em umainguagem ao mesmo tempo precisa e

clara, que comunique sem gerar dúvidasde interpretação. Este é talvez o maior desafio da modelagem, e a principalrazão deste trabalho: como criar ummodelo de software claro, preciso e aomesmo tempo simples.

Outra propriedade importante dosmodelos é a de poder acompanhar aevolução do projeto. No início, écomum os modelos serem apenas linhas

gerais e esboços. Em alguns casos, nemos limites do problema estão ainda emdefinidos. Com um entendimento melhordo problema, o modelo passa a agregar



mais informação e a se tornar-se umavisão mais completa de onde sepretende chegar. Um simples esboço

pode dar lugar a um diagrama maispreciso, a partir do qual várias decisõesde projeto podem ser tomadas.Concluída a etapa de design, o modelocontém todas as informações necessáriapara se iniciar a construção da solução,o modelo está agora bastante detalhado

e preciso. Finalmente, com o produtoconstruído e em operação é importantemanter-se o modelo atualizado e vivo,refletindo nele as eventuais alterações

feitas no produto quando ele sofre umamanutenção, ou são realizadasexpansões.



O modelo é uma parte importante doprojeto e deve evoluir com ele. Assim épossível resumir as qualidades

desejáveis de um modelo como sendo aclareza, a precisão, a simplicidade e afacilidade de evolução. A figura mostraum esquema das atividades em umprojeto de desenvolvimento de softwarequalquer, e a correspondente evoluçãodo modelo deste sistema.



Figura 3 - Esquema de um projeto desoftware

Com base neste esquema analisa-se aevolução do modelo no projetode sistemas, as atividades realizadaspara obtê-los e os principais

personagens envolvidos nestasatividades. Estuda-se, inicialmente, osdois principais fluxos de atividades

representados neste esquema: o ciclode desenvolvimento, representado pelasatividades do lado do desenvolvedor, eo ciclo de teste do produto, representad

pela seta vertical à esquerda, do lado docliente.



2.1.1. Ciclo deteste do software

O ciclo de teste do software é umprocesso de responsabilidade docliente, ou do seu representante. Visagarantir que as necessidades levantadaspara a definição dos problemas estejamsendo atendidas pelo produto. No ciclo

de teste o cliente verifica se o produtofornecido pelo ciclo dedesenvolvimento está de acordo com osrequisitos de projeto, e para isso ele

realiza testes sobre o produto. Testesque colocam o produto em situações deuso normal, e procuram detectar falhas enovos requisitos não identificados



ainda. Como um sub-produto dos testessurgem correções e novas necessidadesque devem ser incorporadas aos

requisitos de uma nova versão desteproduto, dando início a um novo ciclode desenvolvimento.

Os clientes são todos os que contratamo serviço de desenvolvimento dosoftware, porque estão interessados pel

resultado que o software irá dar ao seunegócio. Os clientes podem ser osusuários finais, que irão usar o softwarepodem ser seus gerentes que devem

garantir a qualidade e a funcionalidadedo software ou patrocinadores dosoftware que irão incentivar odesenvolvimento e arcar com seus



custos

Gerente da aplicação é o

responsável pela operação dosistema no ambiente do usuário.Durante o desenvolvimento do projeto o gerente é o lider dosusuários e atua como facilitador dos relacionamento entre eles e aequipe de desenvolvedores. Uma

vez desenvolvido o sistema desoftware o gerente da aplicação passa a responder por eleinternamente à organização.

Usuário final é quem se utilizarádo sistema para auxiliá-lo em suasatividades. Em problemascomplexos os usuários podem



variar de departamento, função,hierarquia na organização. Nestescasos é importante se criar um

comissão de usuários,representativa da comunidade, paraorientar o desenvolvimento dosistema.Patrocinadores fazem parte dogrupo de clientes que dão apoiofinanceiro, técnico ou político ao

desenvolvimento do sistema. Esteapoio é vital para que osdesenvolvedores possam ter acessoàs informações e possam executar,

se necessário, as alterações naorganização para a implantação dosistema.



2.1.2. Ciclo dedesenvolvimento do

software

O ciclo de desenvolvimento do

sistema é um fluxo de trabalho cíclicoque gera novos produtos a partir dasnformações obtidas no levantamento de

necessidades do problema. É dades

cíclico porque o produto de saídaalimenta o ciclo seguinte, de modo que cada volta aproxima-se o produto dasnecessidades levantadas. Espera-se queo ciclo seja convergente, isto é, em umdeterminado estágio o produto atenderáodos os requisitos e poderá ser

considerado terminado. Este ciclo é



realizado inteiramento no lado dodesenvolvedor, mas possui interaçõescom o lado cliente, no ciclo de testes do

produto.

O ciclo de desenvolvimento de umsistema é caracterizado por 4 atividades

principais: análise, design, construçãode componentes e integração. A seguir verifica-se o papel do modelos nas fase

e os papel dos participantes de cadauma delas.

Fase de Análise

A análise é a fase de levantamento dorequisitos do problema a ser resolvido.



ela estabelecem-se os limites doproblema, e identificam-se asnecessidades do sistema. Deve-se

procurar limitar a análiseexclusivamente ao problema em estudo,evitando a influência de elementos queestão fora do escopo do problema.Detalhes de implementação que podemofuscar a definição do problema, falsosrequisitos, limitações inexistentes

devem ser deixadas de lado. Para ajudao analista na busca de uma maior clareznas definições inciais, ele deve criar ummodelo do problema. Este modelo

deverá ter apenas as informaçõesrelevantes para o entendimento doproblema e deverá receber a aprovaçãopor parte do cliente, garantindo que o



caminho está correto e servindo de baspara as demais fases do projeto.

As técnicas aplicáveis à análise sãomuitas, e dependem, grandemente, daexperiência do analista. Quanto maiscomplexo o problema, mais difícil é a

análise e mais importante o uso demodelos para reduzir e gerenciar estacomplexidade. Todas as informações

obtidas do cliente devem ser avaliadas evadas em consideração na análise.ão existe um momento preciso que

ndica o final da análise, mas o analista

pode identificar este momento quantoodas as facetas do problema foram

exploradas e a visão que o modeloraduz é suficiente para iniciar as fases



seguintes do projeto. Mesmo que algunsrequisitos foram esquecidos, não émotivo de preocupação, como o

processo de desenvolvimento é cíclicosempre será possível rever a análise encluir estes novos requisitos.

A análise é tarefa do analista desistemas. Em projetos mais simples estatividade pode ser desempenhada por

um desenvolvedor sênior, ou pelopróprio gerente de projeto, se estespossuirem um conhecimento básico demodelagem de sistemas, e a

disponibilidade para entrevistar usuários, levantar e organizar asnformações disponíveis para o início

do projeto. Em projetos mais complexos



esta tarefa pode ser dividida entrediversos profissionais como o Analistade Negócios, o Analista de

Documentação e o Analista de Banco deDados.

Analista de Negócios - deve ser um especialista na área deconhecimento a que o sistema sedestina, e tem como objetivo

identificar asresponsabilidades que o sistemadeve cumprir para o negócio docliente. O analista de negócios

pode desenvolver uma análise doretorno esperado com oinvetimento no sistema, e estudar aviabilidade técnica do sistema,



integrando-o ao ambientecomputacional existente. Osrequisitos de negócio, as regras e

os processos de negócios devemser modelados por este profissional.Analista de Banco de Dados -como uma grande parte dossistemas de informação são baseados na tecnologia de banco d

dados, é importante ter umentendimento preciso dasinformações já existentes em bancos de dados, antes de iniciar

um novo projeto. O analista podese utilizar de técnicas próprias eferramentas de software para criar os esquemas dos bancos de dados



existentes e que serão úteis para onovo projeto de sistema.Analista de Documentação - é o

responsável por elaborar adocumentação do sistema, osdocumentos de especificação,manuais e diagramas. Como a fasede análise é uma fase onde ageração de documentos é maior, éimportante ter-se um profissional

técnico especializado encarregadoda produção desta documentação.Uma prática interessante pode ser de produzir o manual do usuário do

sistema já na fase de análise, eutilizá-lo com parte daespecificação técnica derequisitos do sistema.



Como parte importante da fase deanálise temos um modelo inicial dosistema que fará parte do documento de

especificação, produto da fase deanálise. Porque as correções nas fasesniciais de um projeto são sempre mais

fáceis de serem feitas, do que em fasesmais avançadas, os documentos e osmodelos desta fase devem ser,continuamente, avaliados e verificados

pelos clientes.

Fase de Design

O design se concentra na solução doproblema identificado na fase de

análise. Busca incorporar aos modelos,



os elementos que formam um sistemapara resolver o problema de projeto.Como quase sempre a seleção de uma

estratégia de solução traz compromissoscom outros sistemas, deve-se, nesta faseavaliar o melhor caminho, testar eescolher a alternativa de solução maisadequada. O designer conta com a suaexperiência e o apoio de modelos dosistema em projeto para apoiar sua

decisão.O design é uma tarefa para engenheiro

de software experientes. Em um projeto

mais complexo, diversos aspectos de umsistema de software devem ser considerados, o que exige a participaçãde outros especialistas, como o



Engenheiro de Redes e o Designer denterfaces.

Engenheiro de Software - é oespecialista em criar o operar osmodelos dos sistemas para levá-loao código. Deve possuir habilidade de conceber oscomponentes do sistema ecaracterizá-los de modo a que

atendam os requisitos do problemaPode testar soluções e se utilizar d padrões de soluções já consagradae aplicá-las a novos problemas. O

engenheiro de software devegarantir também que as boas práticas de engenharia sejamrespeitadas no projeto, assegurand



a qualidade do produto. Engenheiro de Redes - é umespecialista importante quando o

sistema será implementado em umambiente de processamentodistribuído. Neste caso, acomunicação entre os componentesdo sistema será feita pela rede decomunicação de dados, que deveser projetada para dar vazão ao

volume de comunicação esperado.Existindo uma grande interaçãoentre os componentes da solução pode exigir, em alguns casos, que

componentes especiais decomunicação sejam especificados construídos.

Designer de Interfaces - é um



especialista na comunicação entreos usuários e o computador. É um profissional muito importante em

sistemas com grande interação comos usuários como os sistemas parainternet . O aumento do número deusuários nos sistemas deinformação tem feito com que este profissional tenha um papel cadavez mais importante para a

aceitação e para a usabilidade dosistema. Ele deve possuir ahabilidade de e a criatividade paracriar metáforas para a operação do

sistema.

Ao final da fase de design todas asdefinições do projeto devem estar



registradas no documento deespecificação. Modelos, listas eesquemas servem como referências para

os construtores dos componentes e paraa integração do sistema. O modeloproduzido pelo design pode variar muitono nível dos seus detalhes. No início doprojeto apresenta poucos detalhesmostrando conceitualmente a solução,para uma avaliação inicial, ou para a

validação de um cliente. Nos ciclosmais avançados do projeto, o modelodeve estar muito bem detalhado paradeterminar aos programadores todos os

pormenores do software.

Fase de Construção doms



Componentes

Na fase de construção decomponentes inicia-se as atividades deprogramação na construção do softwareA boa prática de construção recomenda

a adoção do conceito de componentes dsoftware reutilizáveis para reduzir prazos e custos no desenvolvimento,mantendo a qualidadade do produto. É

cada vez mais comum se dispor decomponentes pré-fabricados prontospara serem utilizados em diversos

projetos, organizados em um frameworkestes casos a construção decomponentes se limitará a criar oscomponentes que são específicos para o

novo projeto.



A construção civil é um exemplo típicde padronização de peças pré-fabricadas. Poucas são as partes criadas

específicamente para uma construção.a área mecânica o exemplo mais

nteressante de criação de componentesencontra-se na indústria automobilísticaonde um carro é efetivamente amontagem de peças e partes completasfeitas por outras empresas,. Muitas

vezes a mesma peça é utilizada emdiferentes carros. Esta abordagem aindaé nova na engenharia de software, masestá, aos poucos, revolucionando o

desenvolvimento de software.

A construção dos componentes é umrabalho para o programador de



computadores, que é o especialista nasinguagens de programação. Um mesmo

sistema pode possuir compontentes

escritos em diferentes linguagens, noentanto, para facilitar a manutenção esimplificar o sistema quanto menor onúmero de linguagens mais facilmente osistema será mantido. O programador segue princípios e práticas próprias, qunão farão parte deste trabalho. Como

uma grande parte dos sistema atuais seutiliza de um banco de dados paraarmazenar as informações e possui umagrande dose de interação com os

usuários, é importante também envolverna fase da construção outrosespecialistas: o programador de bancode dados, o programador de



componentes e o programador denterfaces.

Programador de interfaces é o profissional responsável por desenvolver os componentes deinteração entre o sistema e os seususuários. Os componentes deinterface devem se caracterizar pela facilidade de uso e pela

precisão na comunicação. O uso deuma interface gráfica e regras próprias para criar estescomponentes, projetador por um

designer, exigem que um programador especializado nestatarefa seja convocado para realizála.



Programador de Componentesescreve os componentes de negócioobedecendo as regras de negócio

definidas pelo Analista de Negócios e projetadas peloEngenheiro de Software. Sua principal tarefa é garantir aqualidade do componente, suaeficáfica e robustez. Utiliza, emgeral, uma linguagem robusta em

um ambiente de desenvolvimento próprio. Programador de Banco deDados é um profissional important

na fase de construção se houver necessidade de criar componentesespecíficos para o armazenamento

e recuperação de informação. Em



sistema orientados a objeto o usodo banco de dados é limitado eorganizado pelos objetos, sendo

que este profissional deve ser responsável por integrar ossistemas orientados a objeto comos sistema legados em bancos dedados.Analista de Teste. Como o produto final da fase de

construção são os próprioscomponentes. Cada componente próprio ou adquirido de ter terceiros deve ser testado

individualmente, para garantir queele esteja de acordo com aespecificação do projeto. Este teste

faz parte do processo de criação de



componentes mas não deve ser desprezado. Pode-se criar, em projetos maiores, uma função

específica com estaresponsabilidade, garantindo a suaqualidade e funcionalidade. Oanalista de testes não pode ter umafunção acumulada com a função de programador, para evitar umconflito de interesses.

Fase de Integração

A fase de integração encerra oprocesso de desenvolvimento gerando,como produto final, uma nova versão do

software. Nesta fase, a atividade mais



mportante é a de configuração daversão do software, compilando enstalando os componentes necessários

nos equipamentos servidores. É umafase de trabalho minucioso e organizadoonde se deve assegurar que todos oscomponentes necessários foramntegrados. Após este integração émportante realizar uma fase de teste. É

comum nesta fase se criar roteiros

automatizados de teste, assim comopode ser necessária alguma atividade deprogramação para integração final doscomponentes.

As atividades de integração podem, esistemas mais simples, ser realizadaspelo Engenheiro de Software ou pelo



próprio Gerente de Projetos. Emsistemas mais complexos é comumencontrarmos o Gerente de integração

ou Gerente de Configuração que irácoordenar uma equipe de profissionais,os Integradores que responderão pela

união correta dos componentes.Os modelos, na fase de integração,

servem de mapa para a configuração do

sistema, e união dos componentes. Emmuitos casos, não se está interessado emcriar um sistema totalmente novo, massim em adaptar um sistema existente

para as necessidades específicas de umcliente. Chama-se ao processo deadaptar um software especialmente paraas necessidades de um cliente de



customização[1]

. O processo decustomização passa por todas as fasesdo processo de desenvolvimento, masem uma ênfase maior na fase dentegração, onde são realizadas a maior

parte das atividades de configuração do

software.



2.2. Modelos de umSoftware

O processo de desenvolvimento de umsoftware apresentado é baseado na

evolução de uma visão que osdesenvolvedores controem, em conjuntocom os clientes, sobre o problema a serresolvido. Esta visão é concretizada emmodelos, que devem representar estavisão e evoluir com ela. No início, avisão é incompleta e pode possuir

ambiqüidades e distorções, que ao longdo processo de desenvolvimento, com oentendimento do problema, sãoeliminadas. No final, o modelo

resultante é equivalente em significado



ao código gerado para implementar asolução do problema, eles devem ter gual riqueza de detalhes e precisão.

Em um problema complexo,dificilmente uma visão única, completae bem definida será obtida logo no

nício do processo. É importante que oscompromissos do softwarerepresentados no modelo sejam

assumidos aos poucos, acompanhando oentendimento que se tem do problema.As técnicas de modelagem, que serãoexploradas em detalhes nos próximos

capítulos, ajudam os analistas edesigners a documentar e comunicar oentendimento que adquirem do problemaem diagramas de forma precisa,



evitando a construção de sistemas desoftware inconsistentes.

Um único modelo apenas é insuficientepara representar todos os fenômenosexistentes em um sistema complexo, sãonecessários um conjunto coerente de

modelos com diferentes escalas, criadoa partir de diferentes pontos de vista.Jacobson (1992) propõe que a

complexidade seja introduzidagradualmente no modelo do sistema,com a ajuda de uma série de sucessivosmodelos que aos poucos são capazes de

gerenciar essa complexidade. Elepropõe 5 tipos diferentes de modelos:

modelo de requisitos, que captura

requisitos funcionais do sistema,



modelo de análise, que dá aosistema uma estrutura de objetos,modelo de design, que refina esta

estrutura para a implementação,modelo de implementação, queefetivamente implementa o sistemamodelo de teste que verifica osistema.

Este estudo utiliza apenas três modelo

para representar os sistema de softwaremodelo de contexto,modelo conceitual e

modelo detalhado.

A idéia central aqui também éntroduzir a complexidade aos poucos.

O modelo de contexto equivale ao



modelo de requisitos de Jacobson,enquanto o modelo conceitual seequivale ao modelo de análise de

Jacobson. O modelo detalhado pode seraplicado ao design, à implementação ouao teste do sistema, dependendo donível de detalhes e da finalidade a queele se destina; assim, substitui os 3outros modelos propostos por Jacobson

O modelo de contexto inicia adefinição do problema. É construído emuma escala grande, onde grande partedos detalhes do problema estão

encobertos. Representa os aspectosfuncionais de alto nível do sistema,analogamente ao modelo derequisitos de Jacobson (1992). Serve



para representar o sistema proposto nocontexto do negócio do cliente. Devepossuir uma representação simples, sem

uma formalidade excessiva, para poder ser entendido e validado pelo cliente,que normalmente é leigo em assuntos desoftware. No modelo de contexto definese a fronteira do problema e osprincipais objetivos que o sistema devecumprir para os seus usuários. Este

modelo é, essencialmente, desenvolvidodurante a fase de análise pois refere-se,principalmente, à uma visão doproblema a ser resolvido. Deve ser

possível ao modelo de contexto situar osistema no contexto do cliente,dentificando pontos de integração com

outros sistemas já existentes e



caracterizar a contribuição do novosistema.

O modelo conceitual é um modelo quereúne todos os conceitos presentes noproblema em estudo. Construído comuma escala menor do que o modelo decontexto, cria a estrutura do sistema,usando para isso um modelosimplificado de classes. Nele devem

estar representadas os principaiscomponentes do sistema e suas relaçõeso modelo conceitual está caracterizada

as proposta de solução do problema,

mas sem o detalhe necessário para a suamplementação. A idéia central é

representar, simplificadamente, empoucos diagramas, o sistema como um



odo e as partes principais que oconstituem. Como o modelo final dosistema pode ser muito complexo, o

modelo conceitual serve de índice, deorientação, para que dele sejamdetalhados os modelos demplementação. É um modelo

desenvolvido nas fases de análise edesign porque recebe não só os detalhesdo problema a ser resolvido, como

ambém os elementos incorporados aomodelo durante o design da solução.

A quantidade de detalhes do modelo

conceitual deve estar entre aabstração do modelo de contexto e agrande quantidade de detalhes domodelo detalhado. Como o modelo



conceitual possui um nível maior dedetalhamento que o modelo de contexto,é possível, a partir dele estabelecer um

planejamento do desenvolvimento e umdimensionamento mais preciso dosrecursos necessários para a construçãodo sistema. Estas definições sãompossíveis de serem feitas apenas com

o modelo contextual, assim o modeloconceitual assume também um

mportante papel no gerenciamento doprocesso de desenvolvimento desoftware.

O modelo detalhado, por sua vez,ncorpora todos os detalhes de uma

versão projetada do software. O modelodetalhado pode possuir um nível de



detalhe equivalente ao código dosoftware, podendo-se até criar umacorrespondência biunívoca com ele.

Para cada versão de um software omodelo detalhado pode mudar,ncorporando as novidades desta versão

Podem ser gerados quandos modelosdetalhados quantas versões do produtoexistirem. O objetivo principal domodelo detalhado é a construção do

sistema, assim nele devem estar representados todos os detalhesconstrutivos e as definições de projeto.É um modelo que se inicia na fase de

design, com os detalhes comcomponentes a serem construídos e édetalhado na fase de construção. Como modelo detalhado possui uma



escala ainda menor que o modeloconceitual, os detalhes do sistemas sãorevelados com precisão, na medida da

necessidade do desenvolvimento, sejapara uma maior definição precisa dodesign, seja para implementação ou sejapara testes.

A figura abaixo mostra, de formaesquemática, as relações entre a

escala proposta de modelos e osprodutos de software em suas diversasversões.



Figura 4 - Seqüência de Modelos emum Projeto de Software Típico



2.3. Documento deEspecificação deProjeto

O principal documento dodesenvolvimento do software é oDocumento de Especificação deProjeto. Como seu próprio nome diz, ele

deve descreve, detalhadamente, oprojeto de um software. Normalmente, aespecificação é tomada como umdocumento feito para orientar aconstrução do software, mas nesteestudo a especificação é tomada comoum espelho do projeto do sistema, e

assim deve ser mantida atualizada



durante toda a evolução do sistema,nclusive após a sua construção. Na fase

de análise a especificação deve

considerar os objetivos do problema,apresentando os modelos de contexto econceitual. Na fase de design aespecificação recebe os detalhes dassoluções escolhidas, para que naconstrução todas as alterações nosistema possam ser representadas em

modelos detalhados na especificação.Mantém-se assim o documento vivo,acompanhando todo o projeto dosistema.

Como este trabalho não se propõe aapresentar um método paradesenvolvimento de um software, o



documento de especificação não serádetalhado. Entretanto, é de esperar,encontrar muitos diagramas e modelos

em um documento de especificação desoftware.



2.4. A ModelagemOrientada a Objetos

Para criar um modelo é precisoescolher o que é considerado

mportante, e por isso será representadono modelo, do que pode ser omitido. Aseleção do que é, e do que não é,mportante segue um paradigma, um

ponto de vista, uma forma de olhar arealidade que se vai modelar. Descrevese aqui algumas características dos

diferentes paradigmas usados paramodelar sistemas de software.

Para desenvolver um sistema de

software é necessário criar uma visão



do problema, representada em ummodelo que orienta o processo dedesenvolvimento. Para se estabelecer

esta visão deve-se definir um ponto devista, isto é, deve-se a olhar o softwaresegundo um paradigma. O paradigmadefine uma unidade de decomposição dosistema, destacando alguns aspectos emprejuízo de outros. Algumas possíveisvisões e as unidades de decomposição

associadas são:A Visão Funcional decompõe umsistema em funções;

A Visão dos Dados decompõe umsistema em estruturas de dados; eA Visão de Objetos decompõe umsistema em classes de objetos.



A visão funcional valoriza o fluxo denformação do sistema, buscando

responder o que o sistema deve fazer. A

déia, que se traduz em uma análisefuncional, é a de definir o sistema comouma grande função, que pode ser quebrada em funções menores, em umaécnica de análise chamada de análiseop-down (de cima para baixo). Este

procedimento parte do princípio que um

sistema de software deve fazer algo paro seu usuário. Uma função complexapode ser decomposta em funções maissimples, continuamente, até que a quebr

funcional leva a funções tão simples aponto de poderem ser implementadas eestadas. Testadas isoladamente, as

funções elementares são agrupadas e



ntegradas em uma estratégia dentegração botton-up (de baixo para

cima). Integrando todas as

funcionalidades tem-se, ao final, osistema completo com toda afuncionalidade pretendida.

O termo “função” é quem orienta todoo processo de desenvolvimento. O que osistema deve fazer conduz o processo d

análise e construção. Por isso, se for necessário introduzir alterações,modificações e novas funcionalidadesnos softwares desenvolvidos sobre este

paradigma a tarefa mais difícil. Ao sentroduzir uma alterção, uma série de

outras funcionalidades que decorreramdesta podem ser afetada. A quantidade



de código envolvido pode ser muitogrande, inviabilizando grandesmudanças em sistemas desenvolvidos

sob uma visão exclusivamente funcional

Figura 5 - Esquema da Modelagemuncional

Na modelagem de dados, outro

paradigma possível no desenvolvimento



de software, o destaque se volta para aestrutura da informação que é tratadapelo sistema, ao contrário das operaçõe

ou funções às quais estas informaçõesestarão sujeitas. A estrutura danformação de um sistema corresponde

ao conjunto organizado de entidades queguardam alguma informação para osoftware e como elas se relacionam. Oprincípio por trás da modelagem de

dados é que um sistema de informaçãoprocessa informação. Dá-se uma maiorem qual informação é processada e nãoem como se dá este processamento.

Na modelagem de dados não há lugar para representar as característicasdinâmicas do problema, suas funções,



operações ou algorítmos. Ainda quealgumas regras de negócio reflitamapenas em elementos estáticos ou limite

destes elementos, a maioria das regrasde negócio exige a criação dealgorítmos mais complexos que nãoencontram abrigo no modelo de dados.Existe, entretanto, na modelagem dedados uma grande reutilização dasnformações armazenadas e da sua

estrutura. A capacidade em se adaptar uma mesma estrutura de dados emproblemas semelhantes é muito grande,dando amplas possibilidades de uma

grande reutilização deste tipo demodelo. Problemas semelhantes usamestruturas de informação semelhantes.



importante se observar que nemsempre a estrutura da informação refletea estrutura do problema. Algumas vezes

redundâncias e hierarquias presentes noproblema são eliminadas ao se analisar apenas a informação armazenada. Oprocesso de normalização de tabelas deum banco de dados é um exemplo destasimplificação.

Outra observação importante é que umsistema exige dados e funções, e quenem sempre uma abordagem permiteuma visão se integra perfeitamento na

outra. Desenvolver um sistema peloparadigma de dados ou pelo paradigmafuncional resulta em um sistema comgrande acoplamento, onde qualquer



modificação necessária, seja em dados,seja em funções pode resultar em umrabalho complexo demais. A figura

mostra que um dado pode ser necessáriopara mais de uma função e que quemodificar um dado requer modificar muitas funções.



Figura 6 - Um programa combinadados e funções

A orientação a objetos enfoca a buscda estrutura do problema, e não apenasda informação. Identifica em objetos, oselementos importantes do domínio do



problema, que guardam dados epossuem funções que podem operar seudados. Não são apenas as funções que o

sistema deve desempenhar, como namodelagem funcional, nem somente osdados que serão armazendados, como namodelagem de dados; a importânciamaior é encontrar os elementos doproblema que possuem todas estaspropriedades.

Sebesta (1996) estuda a evolução dasinguagens de programação e verifica

que enquanto a programação procedural

foi desenvolvida na década de 70, nadécada de 80 começou-se a combinaçãode algoritmos e estruturas de dados emobjetos com a linguagem Smalltalk. As



déias da programação orientada aobjetos foram incorporadas à linguagemC gerando C++ que ajudou a populariza

as linguagens orientadas a objeto.

Apesar de ser possível haver programação orientada a objetos desde

1980, os conceitos que envolvem oprojeto de sistema com esta filosofianão são simples, e por isso demoraram

ser utilizados pela comunidade dedesenvolvedores. Os programascontinuavam, até meados da década de90, a serem projetados com uma

separação clara entre a análise funcionae a análise de dados. Num sistema ondequalquer função pudesse se utilizar dequalquer dado armazenado, seria



mpossível saber quais dados sãonecessários para cada função, semanalisar cada uma das funções

separadamente. Esta grande dependêncientre os dados e as funções dificulta umalteração nos dados ou nas funções,porque as conseqüências sãomprevisíveis. É importante criar um

critério para se unir dados e funções emconjuntos organizados e coerentes.

Desta idéia surge a modelagemorientada a objetos.

Um objeto, segundo Jacobson et al

1992), é caracterizado por um conjuntode operações e um estado que armazenaos efeitos das operações que o objeto écapaz de realizar. Assim os dados



armazenados no estado objeto servempara armazenar o efeito das funções,criando-se o vínculo desejado entre as

operações e os dados. Os objetos temuma dimensão maior do que apenas osdados e as funções isoladamente, comoexemplifica a figura.



Figura 7 - Objetos reúnem dados eunções

A orientação a objetos parte daconstatação que o mundo é formado porelementos autônomos e relativamentendependentes, e que criar um modelo d

um sistema de software é identificar quais destes elementos são relevantespara o software. Os objetos que devem

ser incluídos no modelo são os querealizam algo de destaque para oproblema em questão. Esta abordagemreduz a distância entre o modelo e o

mundo real, porque utiliza elementos darealidade para criar o modelo,facilitanto o entendimento do problemapelo analista e pelo cliente.



Selecionar a orientação a objetos paraanalisar um problema, inclui uma sériede características intrínsicas à

ecnologia de objetos que devem ser bem entendidas para que o analistapossa fazer um uso correto desteparadigma. Dentre estas característicasdestacam-se o conceito deencapsulamento das classes, a herança, roca de mensagens e o polimorfismo.

Estas características serão apresentadasa seguir, acompanhadas de exemplospráticos que visam a facilitar oentendimento.



2.4.1.Encapsulamento

Todos os dados e operaçõesnecessárias para um objeto existir, erealizar suas responsabilidades para osistema, devem estar armazenadas nopróprio objeto. Diz-se que ocomportamento e os dados estão

encapsulados no objeto. Envoltos emuma cápsula os dados dos objetos nãoestão mais isolados das funções, elescaminham juntos.



Figura 8 - Esquema do

encapsulamento

O encapsulamento é a principalcaracterística para se identificar um

objeto. O princípio por trás desta idéia que o objeto possua todos os dados e asfunções necessárias para sua existência.

Selecionar um objeto da realidade para



o modelo indica que ele representa algoque existe de fato no domínio doproblema, e que será transportado para

o domínio do modelo do software, comoda a sua autonomia.

Figura 9 - Um objeto deverepresentar algo que existe de verdade

Um lâmpada, como a da figura, é um

objeto importante, por exemplo, para um



sistema de controle doméstico. Aspropriedades que a lâmpada possui,para este sistema são uma tensão

elétrica e um preço. A lâmpada oferecepara este sistema as funcionalidades deacender a um determinado preço peloqual foi comprada.

O encapsulamento protege os dados deum objeto do acesso descontrolado por

outros objetos. O acesso é realizado porntermédio de mensagens trocadas entreobjetos, que nada mais são do quechamadas das funções do objeto. Apena

a interface do objeto, formada peloconjunto de funções, é exposta,oferecendo serviços deste objeto aomundo exterior. Como as mensagens



passam por uma função do objeto antesde acessar os dados, esse acesso écontrolado e o dado protegido. As

nformações do objeto e como elemplementa estes serviços são mantidos

ocultos. A este conceito chamamos deocultamento de informações, e é outradecorrência importante doencapsulamento de objetos.

O encapsulamento dos objetosencontra analogia em diversas situaçõesda vida diária. Um exemplo de sucessode encapsulamento presente em nossas

casas é o caso do aparelho de TV e doaparelho de reprodução de DVD. Vamoobservar que as funções da TV e daunidade de DVD são muito bem



definidas: o aparelho de TV possuicomo função apresentar imagens,enquanto o a unidade de DVD reproduz

magens armazenadas no formato padrãodo DVD. Eles se complementam paraservir o seu usuário, e ao mesmo tempose mantêm independentes.

Figura 10 - Exemplos reais de



encapsulamento

Além das funções específicas, os

aparelhos possuem uma interface bemdefinida e padronizada que permite quesejam operados sem a necessidade de seconhecer o funcionamento interno dos

aparelhos. Assim como nos objetos,estes aparelhos protegem oscomponentes e suas informações de um

uso indevido, expondo apenas umanterface externa.

O encapsulamento implica em outra

característica própia da orientação aobjetos, que é a colaboração entre osobjetos pela troca de mensagens. Antegração dos componentes ocorre

nterligando a saída de um objeto com a



entrada do outro, de modo que um objetpossa acionar uma função do outroobjeto. De modo análogo, o DVD se

comunica com a TV para utilizar afunção de exibição de imagens. Oaparelho de DVD pede à TV queapresente as imagens, e para isso eleenvia pela interface externa decomunicação , a mensagem com amagem a ser apresentada. A operação

em separado dos aparelhos é confiável segura, o que leva a uma confiabilidadee segurança da operação em conjunto.

O encapsulamento leva à reutilização,outro grande benefício da orientação aobjetos. Com ela é possível separar acriação de objetos, da integração destes



objetos em sistemas. A reutilização éuma das conseqüências mais procuradasno projeto orientado a objeto, pois dela

decorre uma redução no custo dodesenvolvimento de novos sistemas euma maior facilidade de manutenção eexpansão. Um objeto bem projetado,estado e confiável pode ser utilizado

em diversas situações, diluindo o seucusto entre várias aplicações. A

manutenção é simplificada e a expansãopode ser realizada de forma maiscontrolada. Usando ainda o exemplo daTV e do DVD deve-se observar que a

TV pode ser utilizada como um objetopara apresentação de imagens emdiversos sistemas de multimídia, assimcomo quando um aparelho de vídeo



cassete pode ser substituido, quasesempre, por um aparelho de DVD, maismoderno, sem necessariamente alterar o

aparelho de TV.

Figura 11 - Exemplo de interfaceadronizada

A figura mostra uma interfacepadronizada para a operação da maioriados aparelhos eletrônicos de reprodução

de som e imagem. O uso repetidopermite que seja qualquer for amplementação interna, o usuário saberá

o que irá acontecer se escolher a seta

reproduzir) ou o quadrado



interromper).

O que caracteriza um

encapsulamento eficiente é a definiçãoprecisa da interface. A interface é a aista dos serviços que o objeto oferece,

ela esconde como o objeto as

mplementa. Muitas interfaces já estãopadronziadas e há um grande esforçogeral de padronização para tornar o

acesso aos serviços de objetos maisfácil e simplificado. Existem boasperspectivas para a modelagemorientada a objetos nos serviços de

objetos distribuidos. Diversos serviçoscomuns a muitos sistemas podem ser oferecidos aos objetos desde elesatendam a uma interface padronizada,



como o padrão CORBA ou o padrãoEJB. (Orfali, 1998).



2.4.2. Mensagens

A comunicação entre os objetos se dápor meio de mensagens. Um objeto qudesejar uma informação de outrosobjetos deve solicitar às funções destes

objetos, na forma de mensagens, queresponda ao seu pedido. Como umsistema é formado por um conjunto deobjetos, o processamento do sistemas éobtido mediante a troca de mensagensentre os objetos.

Uma mensagem é a chamada de umafunção de um objeto, é o acionamento deuma operação encapsulada no objeto dedestino, feita a partir do objeto de

origem. A informação transmitida é



passada ao objetos de destino pelosparâmetros da função, enquanto aresposta da mensagem é obtida pelo

parâmetro de retorno da função. Assim,por definição, toda mensagem tem umaresposta de retorno e pode transmitir uma informação na chamada e noretorno.

Para que os objetos se comuniquem é

necessário que haja algum tipo devínculo integrando estes objetos. Estesvínculos, que podem ser relacionamentos existentes entre os

objetos, asseguram um conhecimentoque um objeto tem da existência dooutro.



Figura 12 - Troca de mensagens entrobjetos



Retomando o exemplo o DVD, nota-seque ele se comunica com a TV por ntermédio da função de exibir imagens

que a TV possui. Esta função estádisponível na interface da TV, o quepermite que outros aparelhos possamservir a TV com imagens. Outra formanteressante de comunicação existente

entre estes objetos é a comunicaçãoexistente entre os equipamentos

eletrônicos e o controle remoto. Ocontrole remoto recebe os comando dousuário e os transmite para a TV comomensagens. Esta comunicação é

facilitada porque as interfaces entre ocontrole e a TV, e entre a TV e o DVDsão padronizadas.



O que permite esta forma decomunicação entre os objetos é adefinição de uma interface precisa.

Assim, como o encapsulamento isola asestruturas internas do objeto, ele deveexpor uma interface que permita que oobjeto receba mensagens de outros,formando o sistema. Vale observar que comunicação entre os objetos é bastanterestrita, as mensagens recebidas por um

objeto se limitam às operações expostasna interface. Caso o sistema exija queuma nova mensagem seja enviada, énecessário criar uma função específica

para receber esta mensagem no objetode destino. A definição das interfaces edas mensagens a serem implementadasnos objetos é uma importante atividade



de modelagem do sistema,desempenhada durante a fase dedesign no projeto de um software.


http://slidepdf.com/reader/full/modelagem-orientada-a-objetos-com-a-uml-jose-eduardo-zindel-deboni 139/902 Figura 13 - Exemplo da comunicação



entre objetos



2.4.3. Tipos,Classes e Objetos

Aplicando o encapsulamento em largaescala, observa-se que existem gruposde objetos compartilham a mesmanterface, isto é, apesar se serem objeto

distintos, oferecem os mesmos serviçospara o sistema. Estes objetos seguem a

mesma estrutura e definem o que chama-se de um tipo abstrato de dados. Um tipé uma estrutura de dados com umconjunto de definições de operações que

afetam esta estrutura. No tipo não existea preocupação de implementar estasoperações, ele serve apenas para sedefinir um padrão no modelo, reduzindo



a complexidade da modelagem.

A implementação de um tipo é uma

classe. A classe possui, além dasdefinições, a implementação dasoperações, para criar um componenteautônomo para o sistema. A classe é ummolde para a criação de objetos, porquepermite descrever um conjunto deobjetos que compartilha a mesma

estrutura de dados e as mesmasdefinições operações. Todos os objetosde uma classe possuem as mesmasdefinições mas podem possuir valores

diferentes nos dados, respondendo demodo diferente às mensagens enviadas àele.



Figura 14 - Exemplos de Classes eObjetos

Um objeto é uma instância de umaclasse, ele realiza a classe para o

sistema. A estrutura do objetos édefinida pela classe, mas as operações estados são definidos na instânciaJacobson, 1992). No mundo real os

objetos existem e trocam mensagens. É apartir destes objetos que se abstrai asclasses para o modelo, porque nomodelo se está interessado nas



estruturas dos objetos. O processo declassificação dos objetos, isto é,determinar a classe a que o objeto deva

pertencer, é a essência da modelagemorientada a objetos.

Em um exemplo típico de uma

nstalação de engenharia é possívelclassificar os equipamentos comoequipamentos elétricos e equipamentos

hidráulicos. A figura abaixo mostra estaclassificação na forma de conjuntos . Asclasses estão associadas aos conjuntos,eos objetos aos seus elementoss destes

conjuntos, que compartilham as mesmaspropriedades. Pertencer ao conjuntoequivale dizer que o elementocompartilha algumas características.



Podem existir equipamentos quepossuem características de mais de umconjunto.

Figura 15 - Subclasses da classeeprodutor de Imagens

O exemplo pode mostrar aclassificação não é única e pode estar sujeita a múltiplas interpretações,dependendo do enfoque que se queira

dar ao problema. O importante é



verificar em cada classe quais aspropriedades que estão sendocompartilhadas pelos seus elementos,

para haver uma boa relação entre omodelo e a realidade.

Figura 16 - Classes se assemelham aconjutos de objetos



2.4.4. Herança

A herança é uma das principaiscaracterísticas da orientação a objetos, que está intimamente associada aoconceito de agrupamento dos objetos

segundo um conjunto de propriedadescomuns. Uma classe de um objeto é oagrupamento de objetos quecompartilham a mesma estrutura dedados e funções. É possível se encontragrupos que possuam um conjunto depropriedades, e que a partir deste grupo

seja possível criar outros grupos quepossuam propriedades ainda maisespecíficas, formando assim umsubconjunto do anterior. A orientação a

objetos permite criar uma relação entre



as classes de objetos de modo queclasse pode ser gerada a partir de outraclasse, herdando dela suas propriedade

estáticas (atributos) e dinâmicasfunções).

A herança permite ainda que as

características herdadas da classemãe possam ser alteradas e expandidaspela classe filha. Incluindo novas

características, ou modificandocaracterísticas existentes. Estacapacidade dos modelos orientados aobjetos permite que a modelagem seja

feita em camadas de classes, criandouma árvore para cada classe, com umnível decrescente de abstração, quandose caminha da mãe para a filha.



O uso da herança permite criar classesmais genéricas, com funcionalidadesgerais e que podem ser herdadas por

várias classes em diferentes situaçõessimplificando a modelagem emplementação. A herança de classes

aumenta muito a capacidade dereutilização das classes, porque pode-secriar classes genéricas compropriedades gerais e que podem ser

utilizadas em diversas situações. Oreuso de classes apresenta um efeitopositivo no prazo e no custo dodesenvolvimento de projetos de

software.



Figura 17 - Exemplo real de herança

No exemplo, a herança é utilizada paradistribuir os equipamentos emcategorias. Observa-se que,

nicialmente, todos são equipamentos.Os equipamentos podem ser para casa,podem ser elétricos e podem ser mecânicos. Alguns equipamentos para

casa são também elétricos, criando a



classificação dos eletrodomésticos.

O conceito de herança e de objetos em

software não é novo, mas foi poucoutilizado nos projetos de sistema até queas linguagens de programação quepermitissem implementar em software

estes conceitos com facilidade. Hojeexistem várias linguagens orientada aobjetos que permitem incorporar

herança e encapsulamento nos sistemade software.



2.4.5.Polimorfismo

Uma decorrência interessante dacomunicação por mensagens e daherança a orientação a objetos é opolimorfismo. Define-se polimorfismocomo a propriedade que o emissor deuma mensagem não precisa conhecer a

nstância da classe que recebe estamensagem. (Jacobson, et al, 1992). Estapropriedade leva ao fato de que umamesma mensagem pode ser interpretada

de modos diferentes, quando for recebida por objetos diferentes. Assim,como as implementações das funçõesque recebem a mensagem são diferentes



elas podem responder de formadiferente (poli = múltiplas,morfo="forma"). Polimorfismo é a

propriedade de que a mesma mensagempode ser respondida de forma diferentepor duas ou mais classes.

Há alguma confusão entre oencapsulamento e opolimorfismo porque ambos se referem

ao ocultamento da implementação domundo externo ao objeto. No entanto, opolimorfismo está centrado napossibilidade de uma resposta diferente

devido ao desconhecimento dodestinatário da mensagem, enquanto noencapsulamento a implementação estáapenas oculta do mundo exterior.



Figura 18 - Polimorfismo: a mesmamensagem tem respostas diferentes



2.4.6. Vantagensda Orientação a Objetos

Ao escolher desenvolver umsoftware pelo paradigma deobjetos, o desenvolvedor procuraobter uma série de vantagens,decorrentes das característicasdesta abordagem:

O uso de objetos na modelagemtorna mais fácil descrever asestruturas e o comportamentoexistente no mundo real. Essa

proximidade faz com que osclientes possam se identificar maisdiretamente com os problemas nosmodelos.



O encapsulamento do conhecimentoem componentes isola ocomportamento, o que permite que

as mudanças nos requisitos possamtambém serem isoladas em cadacomponente sem afetar o sistemacomo um todo.O uso de classes e objetos facilitaa integração das fases do processode desenvolvimento, porque ao

contrario de outros modelos ondecada fase possui técnicas e paradigmas próprios, na orientaçãa objetos o mesmo paradigma é

conduzido da análise à construção.O encapsulamento favorece o testedos sistemas de software, que podeser isolado para cada componente.



O resultado é um aumento naqualidade do sistema.O encapsulamento permite ainda

que os componentes possam ser desenvolvido por fornecedoresdiferentes,A reutilização, decorrente doencapsulamento, reduz custos e prazos no desenvolvimento desoftware porque possibilita que o

mesmo componente seja usado emvários projetos,A herança associada aoencapsulamento permite abordar

problemas mais complexos do quecom outras abordagems dedesenvolvimento. A herança criauma família de objetos com uma



complexidade crescente e que podem ser aplicados em vários problemas diferentes.

Algumas das vantagens da orientação objetos podem ser compravadas naprática com o estudo de caso que se

segue.



2.5. Estudo de Caso:Automação de Vendas

Para melhor entender os conceitos daecnologia de objetos, segue um exempl

da aplicação desta tecnologia. Oobjetivo é destacar, didaticamente, ascaracterísticas da orientação a objetosem um sistema que reproduz umaautomação de vendas. Não se pretenderesolver o problema de automaçãocomercial, mas utilizar como exemplo o

problema do sistema de informaçõespara apoio às vendas em uma loja.Como um sistema de informaçãogerencial, ele deve atender as regras do

negócio e, simultaneamente, ser flexível



para acomodar as mudanças destasregras, resultado natural da evolução donegócio. A adoção do paradigma de

objetos ajuda a obter esta flexibilidade,conseguida pelo uso correto dascaracterísticas desta tecnologia como:encapsulamento, as mensagens, aherança e o polimorfismo, que serãodemonstradas a seguir.

Este estudo de caso também serve paraexemplificar a abrangência eaplicabilidade dos modelos em umsistema prático. Inicia-se formulando o

problema por meio de uma visão docontexto onde este sistema se encontra.Segue-se construindo um modeloconceitual do sistema, que define as



principais classes do sistema e suasrelações. Das definições preliminarespassa-se para um detalhamento que se

raduz na implementação do sistema. Oescopo do exemplo é limitado aoentendimento dos princípios daorientação a objetos, sem descer emdetalhes excessivos dos códigos e dasopções de implementação, que podemser encontrados no capítulo 6, no final

do livro.



2.5.1. Contexto doProblema

O estudo de caso ocorre com uma lojade departamentos e o seu processo devenda. Um cliente escolhe os produtosque deseja comprar. Ele se encaminha aum caixa que deve finalizar a venda. Emgeral, o caixa possui um terminal com

um leitor de código de barras queobtém, com base em um código, o preçodos produtos. Alguns produtos podemer descontos para pagamento a vista, ou

parcelamento em 2 ou 3 vezes, com ousem juros. Este estudo se interessa pelasetapas de determinação do preço e dascondições de pagamento do produto.



Deseja-se um sistema de informação qudado o código do produto informe opreço e as condições de pagamento

deste produto. As condições depagamento serão definidas em função docrédito que o cliente tem com a loja emuma regra de negócio pré-estabelecida.Segue-se a arquitetura do sistema e asregras de negócio:

Arquitetura do Sistema

O sistema é processado em uma

rede de postos de venda, tambémconhecidos como POS (do inglês: pointof sale). Eles fazem a interface entre o

caixa, funcionário da loja, e um



computador central que processa asrequisições do processo de venda. Afigura abaixo descreve esta arquitetura:

Figura 19 - Esquema da Arquiteturado Sistema da Loja

O computador central armazena osdados dos produtos, dos clientes e dohistórico das vendas em um banco dedados. As regras do negócio também sã

processadas no computador central. Os



POS implementam uma camada deapresentação e comunicação com ocaixa, e fazem as requisições ao

computador central. Existe um pequenopoder de processamento local nos POSque pode ser utilizado, dependendo daaplicação e da estratégia dedesenvolvimento escolhida.

Regras de negócio

O processo de venda proposto paraesta loja resume-se a três ações,

executadas pelo caixa, por meio doPOS:

1. Identificar o produto pelo seu



código,

2. Identificar o crédito do cliente e

seus dados pessoais pelo seu CGC[2], e

3. Informando o número de parcelas,verificar se a venda parcelada foiaprovada.

A principal regra de negócio neste

sistema está na aprovação do crédito navendas à prazo. Por uma normaestabelecida pela administração da lojaodo cliente tem um crédito gerenciado

pela loja e que pode ser elevado pelogerente, conforme as novas compras docliente na loja. No entanto, o cliente nãopode financiar compras acima do seu



crédito. Se o saldo de uma compraparcelada for superior ao crédito docliente, a venda não é aprovada.

Por exemplo, se um cliente possui umcrédito de R$1.200,00 e deseja comprarum produto de R$ 2.100,00 ele pode

comprar à vista porque não fica comsaldo devedor. Pode também parcelar em duas vezes de R$1.050,00 porque o

saldo devedor será de R$1.050,00 enferior ao seu crédito de R$1.200,00.o entanto, se ele quiser parcelar em 3

vezes iguais de R$700,00 terá um saldo

de R$1400,00 superior ao seu crédito, enão conseguirá aprovar a venda.

Esta regra pode ser expressa pelo

pseudocódigo abaixo, para uma venda



de n parcelas, onde:

saldo - valor que resta a pagar após

a entradapreco - preço do produto à vistan - número de parcelas da

vendacredito - limite de crédito do

cliente com a loja

saldo = (n-1)*preco

se (saldo<=credito)então vendaAprovadasenão vendaNãoAprovada

Para incentivar a venda para alguns

clientes especiais identificados como



ClientesVIP a loja dá um créditodobrado para estes clientes, de modoque os clientes considerados VIP podem

fazer dívidas com a loja duas vezessuperiores ao valor do crédito, se nãofossem VIP.

É possível que alguns produtos tenhamem época de promoções e descontos,condições especiais de venda a serem

definidos posteriormente. Por exemplo,uma promoção pode permitir a venda dedeterminados produtos, em até 3parcelas independente do crédito do

cliente. O sistema a ser desenvolvidopara automatizar a loja deve ser flexívepara acomodar estas modificações eoutras novas regras de negócio no



futuro.



2.5.2. ModeloConceitual

Estabelecendo-se este contexto e seusrequisitos, é possível definir um sistemapara atendê-los, partindo dos principaisconceitos deste problema. No modeloconceitual já são percebidas ascaracterísticas da orientação a objetos,

onde o primeiro passo é identificar asclasses presentes no sistema.Analisando a descrição do contexto dosistema, observa-se que o processo de

venda ocorre entre os seguintespersonagens:

O Cliente, que pode ser VIP ou não



e possui o crédito;O Caixa que processa os pedidoscomo usuário final;

O POS que define a interface com sistema;A Loja onde estão aramazenadas aregras e informações eO Produto que possui o preço e asofertas.

Com estes personagens, é possível sedefinir o processo de venda, sob o pontode vista da orientação a objetos,caracterizando as mensagens que os

objetos trocam entre si. Sob este pontode vista, o processo de venda ocorre em3 fases, a saber:



Fase 1 - Identificação do Produto

Para identificar o produto pelo seucódigo, o caixa inicialmente lê o códigono produto e pergunta para a loja: Qualé o produto com o código xxxxx? . A

pergunta é dirigida para a loja porque aoja é responsável por manter uma listade seus produtos. A loja então, procuranesta lista o produto desejado e o

retorna ao caixa com as informaçõessobre este código. O caixa pode então,se quiser, descobrir o nome e o preço dproduto.

Fase 2 - Identificação do Cliente



Analogamente ao produto, o caixapode pegar o número do CGC docliente, e perguntar para a a loja, quem é

o cliente que possui o CGC yyyyyy? Aresposta da loja, caso o cliente esiver presente na lista de clientes da loja, sero próprio cadastro do cliente, queretorna ao POS. Neste cadastro o caixapode verificar os dados do cliente comonome, o crédito que este cliente possui,

entre outras informações.

Fase 3 - Autorização do Crédito,

para vendas à Prazo

O caixa, representado pelo POS,

possui, após as consultas anteriores, um



produto e um cliente. Sabendo que ocliente deseja fazer a compra em nparcelas, algum elemento do sistema

deve informar se esta venda pode ser realizada ou não. No exemplo, a vendaserá realizada se a dívida do cliente, nacompra parcelada, for menor do que ocrédito que o cliente possui com a loja,como manda a regra de negócio. Algumcomponente da loja precisa ser

responsável por testar esta regra denegócio. Tomando uma decisão deprojeto, optou-se em atribuir estaresponsabildade para o produto. Assim,

para saber se a venda pode ser realizado caixa pergunta para o produto: Vocêproduto, pode ser vendido para estecliente por n parcelas? O produto,



conhecedor da regra de negócios,responde com um sim ou não e terminaesta etapa do processo de venda.

Estas três ações podem sedecompostas na forma de mensagensrocadas entre os componentes

principais do negócio: caixa/POS,produto e cliente e loja. Imaginemosestes componentes como personagens de

um mundo fictício, onde oprocessamento do sistema é realizadocom uma coleção de perguntas erespostas entre estes componentes,

esquematizada na figura abaixo:



Figura 20 - Comunicação entre osComponentes da Loja

Neste modelo conceitual pode-seanalisar as características deencapsulamento das classes, integraçãocom banco de dados, mensagens eherança; próprias do modelo orientado aobjetos.



Encapsulamento

A primeira característica que seobserva na descrição do problema é aexistência de alguns objetos bemdentificados. Na descrição foram

usados o POS, a Loja, o Cliente e oProduto. Nenhuma ação ficou sem umaorigem ou um destino entre estesobjetos. O hábito de fazer compras em

ojas, torna estes conceitos familiarespara a maioria dos leitores, o quefacilita muito o entendimento do

processo. Todos sabem que uma loja éum estabelecimento comercial onde osclientes encontram os produtos e podemadquirí-los. Pra facilitar o processo de

venda a loja mantém, além de uma lista



de produtos para venda, uma lista declientes cadastrados, com um limite decrédito.

A lista de produtos é análoga a umaestante onde os produtos a seremvendidos estariam expostos para a

venda. Cada Produto possui um preço,uma descrição e um código para facilitaa venda. Qualquer outro objeto do

sistema pode escolher um Produto everificar seu nome, preço e códigosimplesmente “perguntando” para ele. OProduto possui estas informações a seu

respeito, e possui ainda meios pararesponder à perguntas o tipo: Qual é oseu preço? A característica do Produtode ser auto-suficiente em prover



nformações sobre si mesmo éconseqüência do encapsulamento.

No modelo, a Loja é uma entidade quese relaciona com os POS para prover nformações para as vendas. O POS é

uma interface de acesso às informaçõesda Loja, e por isso ele pergunta para aLoja o que ele quer saber. Paraconseguir dar todas as respostas como o

preço do produto, ou o crédito docliente a Loja conta com outros objetosencapsulados na própria Loja: umaistaDeClientes, que guarda a lista deodos os clientes da loja e umaistaDeProdutos, que guarda todos os

produtos à venda. Ao ser questionada

sobre qual é o produto que possui um



determinado código, a Loja procura estproduto na sua lista e devolve o objetooProduto. Este produto é criado e

ransferido para fora da classe Loja,para uso do POS. Esta é uma importantecaracterística relacionada ao

encapsulamento dos objetos: o objetooProduto é transferido para o POS emresposta à esta mensagem, todas asnformações e a capacidade de receber

mensagens e dar respostas vai com ele.Como está encapsulado no objeto todasestas habilidades, elas são transferidasem conjunto com o objeto.



Figura 21 - Esquema dos Objetos do

Sistema

O POS de posse do objeto Produto,fornecido pela Loja pode fazer perguntas diretamente para ele, eprosseguir o processamento do sistema.Analogamente, a Loja fornece um

Cliente ao POS quando pede paradentificar o Cliente pelo seu CGC. Onome, o crédito próprios deste clientesão transferidos encapsulados no objeto



Em um sistema orientado a objetos nãohá como separar uma informação do seuproprietário. Não é possível existir um

método sem que um objeto seja o seudono. O encapsulamento é obrigatório.

Temos, neste exemplo, duas classes: a

dos Produtos e a dos Clientes. Asclasses definem tipos de objetos. Umaclasse define uma estrutura que é

compartilhada por todos os objetos queforem criados a partir daquela classe.Esta estrutura é formada por um conjuntde dados armazenados pelo objeto, e um

conjunto de funções que o objeto usapara se comunicar. Os dados e asfunções estão encapsuladas no objeto esó existem enquanto existir o objeto.



Cada função é uma possível mensagemque o objeto está habilitado a responder

A análise de um sistema parte,nicialmente, por uma definição dasclasses do sistema para então definir como os objetos, gerados a partir destas

classes, irão interagir. O modeloconceitual de um sistema é, em síntese,um modelo das classes do sistema, e da

sua estrutura. No modelo conceitualdevem ser descritas as classes extraídasdo domínio do problema e como elas seorganizam. É de se esperar que

erminada esta descrição, grande partedos problemas estejam, conceitualmenteresolvidos. Resta entretanto, odetalhamento necessário para a



mplementação.

Integração com Banco de Dados

A lista de clientes e a lista de produtosda loja devem estar disponíveis para apesquisa assim que o sistema inicia aoperação. Para que isto seja possívelelas devem ficar armazenadas em um

banco de dados, na forma das tabelas:Tabelas de Clientes, Tabela deProdutos.



Figura 22 - Fluxo dos dados na carga

do banco de dadosPara efeito de testes serão utilidadas

as seguintes tabelas de dados, que

mostram a estrutura dos dadosdisponíveis para a loja



Um objeto pode receber chamadas demensagens de outros objetos, para issoele dispõem de funções que sãoacionadas pelo objeto chamador. Uma



mensagem pode enviar com ela umanformação e recebe outras informações

como resposta. A comunicação entre o

caixa, que é uma pessoa, e o POS, umaclasse de um software orientado aobjetos, ocorre na forma de mensagens.O Caixa ativa eventos no POS,pressionando botões para enviar asmensagens, e recebendo as respostas emuma tela. As mensagens enviadas pelo

Caixa ao POS se transformam e outrasmensagens que o POS e pode enviar aoutros objetos do sistema como a Loja.Aexecução do sistema se inicia com a

criação da lista de clienteslistaClientes) e de produtoslistaProdutos). Antes da execução do

programa esta lista estava armazenada



no banco de dados da loja, pararansferir estas tabelas para os objetos

foi criada uma classe auxiliar: BDLoja

Esta classe cria os objetos com base nodados existentes no banco de dados.

este exemplo optamos por executar esta criação na inicialização do sistema

o entando, ela pode ser feita em tempode execução, isto é, na medida em queos objetos são solicitados pelo sistema

eles são procurados no banco de dados.

Mensagens

A comunicação entre os objetosocorre na forma de mensagens. Uma

mensagem é a chamada de uma função



de um objeto, requerida por outroobjeto. O objeto POS é uma interfacegráfica criada para o caixa poder

acionar as funcionalidades disponíveisnos objetos da loja, ou em objetosocais. Ele recebe a solicitação feita

pelo Caixa e as transfere para os outrosobjetos do sistema. Esta seqüência demensagens forma o processamento emum sistema orientado a objetos.

O POS é uma classe criada para secolocar entre o usuário final, o caixa, eos demais objetos do sistema. Os

elementos presentes no POS são caixasde diálogo e botões. Uma caixa dediálogo permite que se entre com dadosem caixas de texto apropriadas. Outras



caixas de diálogo apresenta uma formado POS se comunicar com o usuáriopelas mensagens escritas. Os botões

representam as funcionalidade que oPOS oferece ao Caixa.

Figura 23 - Interface do POS

A classe Cliente, por exemplo,oferece ao sistema a funcionalidade de

nformar o seu crédito. As mensagenspodem ser entendidas como perguntasfeitas de um objeto a outro. As perguntanão são formuladas na forma

nterrogativa como Qual é o crédito?,



mas sim escritas na forma imperativacomo obtenha o crédito ( ou getCredito. Assim dado o objeto comprador do

ipo Cliente (Cliente:comprador);podemos perguntar ao comprador qual seu crédito, usando a função

getCredito

[3]

, que devolve um valor decrédito como resposta, na forma damensagem:

vCredito = comprador.getCredito()

Neste comando, a variável vCreditorecebe o valor do crédito do

comprador. Como podemos ver, oformato típico de uma mensagem,ambém conhecida como a assinatura de

uma mensagem, é mostrado abaixo.



Entre os parentesis “( )” da funçãopodem ser transferidos parâmetros edados de entrada na pergunta.

Resposta = objeto.função( )

O botão CLIENTE serve para enviar

pergunta para a Loja: Quem é o clienteque possui o CGC yyy? Onde o valor docgc foi digitado na área de entrada de

dados. A mensagem que é enviada aoobjeto Loja é :

Comprador = loja.getCliente(yyy)



Figura 24 - Exemplo da Operação doSistema

O botão PRODUTO pergunta para aLoja: Qual é o produto com o códigoxxx? , com o valor do código digitado nárea de entrada de dados.

oProduto = loja.getProduto(xxx)

O botão PARCELAS pergunta para oproduto, se ele pode ser vendido para

este comprador por n parcelas? Onde nfoi digitado na área de entrada de dadose o oProduto e o comprador foramobtidos nas respostas das perguntas

acionadas por CLIENTE e PRODUTO.



Aprovado = oProduto.isAprovado(n,

comprador)

Figura 25 - Exemplo do sistema emoperação

A figura mostra o processamento quenão aprovou a venda do item de código101 para o cliente 1000 em 3 parcelas.



Herança

No exemplo, foi definida uma regra denegócio na qual o cliente pode se tornarum cliente do tipo VIP que possui asmesmas características do cliente

comum, mas com uma capacidade decrédito dobrada. Isto é, ele pode fazer dívidas duas vezes maiores que o seucrédito. Assim deve-se criar uma classe

ClienteVIP que deriva da classeCliente, ou como se diz na linguagem daorientação a objetos, a classe

ClienteVIP herda da classe Cliente osseus dados e funções.

A capacidade de uma classe herdar de

outra classe é uma das principais



características da orientação a objetos.A classe Cliente é chamada de super classe, ou classe mãe, da

subclasse ClienteVIP ou classe filha. Oque isso que dizer que a classe filha é,nicialmente, uma classe igual à classe

mãe, mas pode modificar ou extender suas habilidades, podendo ser maisespecializada que a classe mãe original

No exemplo, a classe ClienteVIP éuma classe Cliente possuindo por issoum nome, um CGC e um crédito; noentanto, por ser um ClienteVIP ele terá

o seu crédito dobrado. Para implementaesta modificação a função de informar ocrédito é reescrita de modo a responder

com o crédito em dobro, como mostra a



abela que compara estas duas funções:

Cliente.getCredito(

)

ClienteVIP.getCr

)

public int getCredito ()

{ return

(credito);}


{ return

(2*credito);}



Como o ClienteVIP é também uma

classe do tipo Cliente, os objetosgerados por ClienteVIP podem assumiro papel dos objetos do tipo Cliente, istoé podem fazer parte da lista de Clientesda Loja e também ser enviado comoresposta ao POS. Em qualquer situaçãoonde um objeto do tipo Cliente possa

ser usado um outro objeto do tipoClienteVIP também pode. Estaversatilidade dos sistemas orientados aobjeto dá ao analista uma liberdade

muito grande para expandir o sistemasem perder as funcionalidades jámplementadas. O analista pode buscar

as heranças próprias do problema



estudado, e criar árvores de classes,descrevendo o problema por intermédiode camadas crescentes de significado e

funcionalidade. Quando o sistema emprojeto atingir o nível de significaodesejado é interrompido odesenvolvimento.



3. Modelo de

Contexto

Este capítulo descreve o modelo de

contexto do sistema, representado naUML pelo diagrama de casos de uso. ste modelo, o primeiro a ser criadoara definir um problema, representa

as expectativas funcionais dos usuárioe por isso é desenvolvido em conjuntoentre analistas e usuários. São

descritos aqui alguns cuidados



róprios deste tipo de modelagem, e oresultado da aplicação desta técnicaem um exemplo de aplicação.



3.1. Introdução

A escala de observação é o fator quedefine o nível dos detalhes observadosem um modelo. Alguém olhando de umagrande distância pode distinguir umacasa na paisagem e até dizer se háfumaça saindo pela chaminé, mas nãosaberá dizer se as paredes são lisas e

bem cuidadas, ou se há alguém na sala.Ao se aproximar um pouco mais poderádistinguir as portas e janelas e atéenumerá-las. Aproximando-se ainda

mais da janela da sala, por exemplo,poderá olhar por ela e saber se háalguém na sala, mas deixa de observar achaminé. Perde-se a noção do todo ao s



manter atento a um único detalhe. Deve-se escolher a distância e o ponto devista em função do que se pretende

analisar com o modelo.

Observando um fenômeno com umagrande escala pode-se ver o seu

comportamento global e o balanço entreas entradas e saídas, mas perde-se odetalhe de cada processo independente.

Reduzindo a escala, o número dedetalhes aumenta, e observa-separticularidades que estavam perdidasna visão geral, o problema é que agora

perde-se, inevitavelmente, a visãoglobal. Não é possível observar globalmente e ao mesmo tempo ter todoos detalhes. Cada fenômeno a ser



estudado exige que selecionemos umaescala adequada para modelá-lo.

Este estudo propõe-se organizar amodelagem de sistemas desoftware segundo três modelos: modelode contexto, modelo conceitual e model

detalhado. Este capítulo descreve omodelo de contexto, que observa osistema a uma grande distância, de modo

que um único diagrama é suficiente pararepresentar o sistema como um todo.ão é possível, com o modelo de

contexto, observar detalhes da operação

construtivos ou de implementação. Noentanto, é um modelo suficiente para senotar as funcionalidades principais dosistema e se ter uma definição clara de



quais são os elementos externos aosistema com quem ele deve serelacionar. O modelo de contexto ajuda

a definir onde o sistema estudado sensere na empresa, ou seja, em qual

contexto da empresa o sistema seencontra.

É com o modelo contextual que senicia a definição do problema,

colocando o sistema no contexto donegócio e do cliente. A idéia dedesenvolver um modelo que faça antegração do sistema em estudo com o

contexto do cliente exige que o modeloseja simples, e de certo modo aténtuitivo. Isto é, o cliente deve ser capaz

de reconhecer o sistema no modelo sem



a necessidade de um treinamentoespecial. O modelo de contexto nãodeve possuir uma

formalidade excessiva, para poder ser entendido e validado pelo própriocliente. Deve ser possível ao clientesituar o sistema no seu contexto derabalho, identificando pontos dentegração com outros sistemas e com

seus usuários.

Para criar o modelo decontexto usaremos dois recursos daUML: o diagrama de pacotes e o

diagrama de casos de uso. O modelo depacotes ajuda a dividir um sistema emsubsistemas, e identificar asdependências entre os subsistemas. O



modelo de casos de uso ajuda a definir os requisitos funcionais e a desenhar afronteria de cada subsistema.



3.2. Pacotes,Sistemas eSubsistemas

Ao se estudar um sistema denformações, que se pretendeautomatizar, pode-se chegar a umnúmero de problemas que impledem o

seu tratamento, como um todo porque oconjunto é complexo demais. O analistaprecisa ter neste momento, ferramentaspara organizar este sistema complexoem partes menores, às quais chamam-sede subsistemas. Um subsistema possuiodas as características de um sistema, e

é parte integrante de um sistema



completo maior.

A organização em subsistemas surge,

naturalmente, da análise detalhada de uproblema. Ela pode ser realizada por uparticionamento funcional,organizacional, operacional, ou por

diversas outras formas. A únicaexigência é que a união destas partes, aofinal, formem o sistema completo

proposto inicialmente.O pacote é o elemento da

UML utilizado para agrupar os

elementos de um sistema, para organizáos, um pacote pode abrigar outroselementos, outros diagramas, e atéoutros pacotes. O pacote assume a

simbologia de uma pasta com o nome do



sistema. Um sistema, ou subsistema,quando visto de longe, como umaunidade, pode ser modelado na UML

por um pacote.

Figura 26 - Representação de umacote

A representação gráfica de umpacote é feita pelo o ícone de uma pastametáfora que recorda um armazenador,

um conjunto de conteúdos organizado



sob um nome, o nome do pacote.

Apesar de estarem sendo indicados

aqui para modelar os sistemas esubsistemas, os pacotes podem ser aplicados em qualquer fase dodesenvolvimento de um software,

nclusive para organizar as própriasfases do desenvolvimento, versões dosistema, isolar componentes de

software, etc. Os pacotes se aplicam aodos os modelos da UML, mas tem umaaplicação maior nos diagramasestruturais como os de classes e casos

de uso.

A boa prática manda usar nomessimples, curtos, escrito em letras

minúsculas. Os nomes devem estar



associados aos componentes principais,ou subsistemas, que o pacote representaOs pacotes podem se relacionar com

outros pacotes, através de uma relaçãode dependência. Um subsistema podedepender de outro subsistema. Estarelação pode ser apresentadagraficamente, em um diagrama depacotes. As dependências sãorepresentadas por meio de setas

racejadas. As setas partem dosubsistema dependente e apontam paraos subsistemas independentes.



Figura 27 - Exemplo de dependência

entre subsistemasRetomando o exemplo do sistema de

automação comercial que controla as

vendas de uma loja e gerencia o crédito



e o cadastro dos clientes. Para organizaeste sistema pode-se dividí-lo em trêssubsistemas: vendas, crédito e cadastro

como mostra a figura. Nela pode-se ver que o subsistema vendas depende dosubsistema de crédito e de cadastro,adicionalmente, o subsistema de créditoambém depende do cadastro dos

clientes.

Os pacotes oferecem um meio simplesde se organizar os modelos, que namedida em que eles se tornam maiscomplexos. É comum com o crescimento

do entendimento do problema ou com aevolução do sistema em direção à fasede implementação, os modelos seornam demasiadamente complexos,



grandes ou poluidos com informação emexcesso. O uso de pacotes pode ajudar aorganizar os modelos nestes caso, além

da divisão em subsistemas já vista.Deve-se, no entanto, tomar o cuidadopara não utilizar pacotes em excesso,que uma vez pode ser um elemento quedificulta a leitura de modelos simples.

Em uma primeira abordagem, a

escala dos subsistemas permite definir os limites do sistema e sua divisão,quando necessária, em subsistemas.Deve-se agora observar o interior de

cada subsistema, para criar um modeloque permita observar cadapacote isoladamente, em um únicodiagrama. O modelo de



contexto aumenta o seu nível dedetalhes, mas permite ainda uma visãoglobal, feita com uma grande escala,

com um alto nível de abstração.



3.3. Modelo deContexto

O modelo de contexto define afronteira entre o que é sistema do que

não é sistema. O que é sistema pode sermodificado pelo desenvolvimento dosoftware. O que não é sistema, e por sso ficará fora da fronteira, não pode

ser modificado pelo software, masnterage ele. Utiliza-se os diagramas de

casos de uso propostos por

Jacobson (1992) e adotada pela UML,para descrever o modelo de contexto. Aécnica tem como principal vantagem a

simplicidade da representação, que

permite uma interação direta com os



clientes e usuários na definição dosrequisitos funcionais do sistema

Em 1987, Jacobson apresenta os Casode Uso (Use Cases) usados comoferramenta da metodologia Objectory. Aadoção do termo Caso de Uso possui

claramente a intensão em mostrar umavisão do usuário do sistema, e de que osistema de informação é construído para

os seus usuários. No diagrama de casosde uso o sistema é descrito como umacaixa preta, e que possui algumasfuncionalidades. Cada funcionalidade

corresponde ao que se convencionouchamar de Caso de Uso. Em 1992,Jacobson (1992) lança um livro ondeonde toda a Engenharia de



Software Orientada a Objetos édesenvolvida sob uma abordagem deCaso de Uso. O diagrama de Casos de

Uso foi incorporado desde a primeiraversão da UML (Jacobson, 1998) comouma abordagem funcional feita pelousuário, com finalidade de nortear osdemais diagramas do modelo orientadoa objetosda UML.



3.3.1. Diagrama deCasos de Uso

O objetivo do diagrama de casos deuso é descrever um modelo funcional dealto nível do sistema em projeto. Estediagrama procura identificar os usuárioe representar o sistema segundo a suavisão. Jacobson (1992) afirma que um

conjunto de descrições de casos de usodeve especificar completamente afuncionalidade do sistema, assim osdesenvolvedores devem procurar junto

aos usuários de cada subssistema formaeste conjunto de casos de uso.

Os casos de uso são utilizados em



odas as fases do desenvolvimento deum sistema. No início, durante odesenvolvimento e ao final, quando o

sistema está pronto. A aplicabilidadenicial do diagrama de casos de uso é a

de auxiliar o analista na definição dosrequisitos do sistema. Os requisitos queo sistema devem atender são decorrentedo uso que os usuários pretendem dosistema. As funcionalidades pretendidas

devem ser transformadas em objetivosque o sistema deve cumprir para seususuários. Esta definição de requisitospode ser suficiente para se assumir um

contrato entre os clientes edesenvolvedores na fase inicial doprojeto. Os objetivos dos usuários serãoos casos de uso do sistema, e o



compromisso dos desenvolvedores é deatendê-los.

Durante as fases de design econstrução, os casos de uso são usadospara ajudar a criar outras visões, alémda funcional, do sistema. A análise da

descrição dos casos de uso pode ajudara entender os processos e a dinâmicados problemas envolvidos no sistema. A

partir da descrição, contida nos casos duso, pode-se extrair o que sistema devefazer e como ele deve atender osusuários. Os casos de uso devem ser

explorados durante o desenvolvimentopara validar o sistema. A cada novafuncionalidade implementada no sistemaos casos de uso podem ser usados para



validar se esta funcionalidade está deacordo com o especificado pelosusuários.

Como os casos de uso são criados apartir da visão do usuário. Eles podemser aplicados na fase final de testes de

ntegração do sistema. A partir de cadade uso é possível definir testes, por vezes chamados de casos de teste, que

são aplicados no sistema, quando esteestiver pronto. Os diagramas de casosde uso podem ser usados para oplanejamento do desenvolvimento do

sistema, uma vez que é possível extrair das funcionalidades contidas nos casosde uso uma medida da complexidade.

Apesar de grande flexibilidade, a



utilização dos casos de uso deve ser imitada, e pode ser mal utilizada se for

extrapolada a abrangência da sua

aplicação. É comum se tentar traduzir afuncionalidade expressa nos casos deuso diretamente para um sistema desoftware, deixando de lado os modelosorientados a objeto. Esta é umaabordagem exclusivamente funcional,uma vez que os diagramas de casos de

uso são análogos aos diagramas defluxos de dados (DFD) da abordagemfuncional. Agindo assim, abandona-se aorientação a objetos e volta-se ao

paradigma funcional.

O diagrama de casos de uso devesolar os elementos do sistema de



software dos elementos externos. Oselementos externos são chamados deatores, e interagem com os casos de us

no sistema. A figura abaixo mostra umexemplo de um diagrama de casos deuso.

Figura 28- Exemplo de Diagrama de

Casos de Uso No exemplo observa-se que um ator ator1) pode se comunicar com mais de

um caso de uso, isto é, pode utilizar o



sistema para mais de uma finalidadecasos de uso 1 e 2). Assim também, a

mesma finalidade (caso de uso 2) pode

ser compartilhada por mais de um ator atores 1 e 2).



3.3.2. Atores

Os atores representam os elementosexternos ao sistema que interagem comele. Estar fora do sistema é não poder ser alterado pelo desenvolvimento do

sistema. Isto quer dizer que odesenvolvedor não tem sobre o ator opoder de programar a sua ação, comoele tem sobre o computador nos casosde uso. Ao focar os atores, a modelagemprocura se concentrar em como osistema será utilizado, e afastar o

analista de como o sistema serácontruído. Ainda não deve haver nadescrição dos casos de usocompromisso assumido com a

construção. A importância dos atores, n



modelo de contexto, vem do princípiode que os sistemas computacionaisservem para atender as necessidades de

seus usuários. O mais importante nosprimeiros passos do desenvolvimento dum sistema é identificar quem são osatores e quais são as suas necessidades.

Um ator é um papel de alguém oualguma coisa no ambiente que se

relaciona com o sistema.Alternativamente, Jacobson (1992)define ator como representando tudoque precisa trocar informação com o

sistema, ou seja, qualquer coisa quenterage com o sistema. Assim, uma

mesma pessoa pode assumir mais de umpapel, e ser representada no sistema por



mais de um ator. O termo ator caracteriza bem a possibilidade domesmo usuário, em diferentes situações

assumir personalidades diferentes parao sistema, agindo como um ator em umapeça teatral. Em cada uma destassituações, deve-se procurar identificar as necessidades dos atores, que seornarão requisitos para o sistema, na

forma de casos de uso. A linha que

separa os atores dos casos de uso é afronteira do sistema.

Deve-se notar a diferença entre atores

e usuários. Os usuários do sistemas sãonstâncias dos atores. Um mesmo

usuário pode, em diferentes momentosdo sistema, instanciar diferentes atores,



ou seja um mesmo usuário pode assumirdiferentes papéis no sistema.

Representação

. Os atores são, normalmente,representados por uma figura humanaestilizada. A UML admite também o usode ícones e outras simbologias para

representar um ator, que podem ser representados também por um retângulocom a anotação <<ACTOR>>. Aanotação <<ACTOR>> , representa um

estereótipo da UML, e permiteransformar a simbologia escolhida em

um ator.



Figura 29 - Formasalternativas de representar um ator.

Os atores devem ser identificados com

um nome que traduz o papel deles nosistema. Não existem regras rígidas paradar nomes aos atores, mas uma boaprática é utilizar nomes substantivos,

com o significado ligado ao domínio doproblema estudado. Deve-se evitar dar nomes muito genéricos como: Usuário,Operador ou Sistema. O uso da palavr



"Usuário", como o nome de um ator,pode ser utilizada desde que, por exemplo, aquele ator represente todos o

usuários do sistema.

Os atores são encontrados entre osusuários prováveis do sistema. Usuários

que podem ser pessoas ou até mesmooutros sistemas computacionais. Umadas técnicas é cercar, imaginariamente,

o sistema e observar quem interage comele. Pode-se procurar a quem a soluçãodo problema interessa, e quem colaborapara se chegar a esta solução. Nestes

personagens encontram-se os atores. Écomum encontrar grupos depersonagens, que se comportam damesma forma frente ao sistema. Estes



grupos são representados com um únicoator do sistema. A mesma pessoa,usuária do sistema, pode pertencer a

mais de um grupo, e assim uma mesmapessoa pode assumir mais do que umpapel, e ser representada no modelo decontexto por mais do que um ator.

Em um processo é possível que osatores se relacionem entre si, trocando

nformações, mensagens ou realizandoalgumas operações entre si. O analistadeve observar se esta comunicação entratores se dá dentro ou fora do sistema,

para decidir se deve ou não representá-a. Quando a comunicação é feita dentro

do sistema ela é importante para odesenvolvedor porque deverão existir



comandos e interfaces no software parapermitir que os dois atores serelacionem. No caso da comunicação

fora do sistema ela não é representadapelos casos de uso e não é importantepara o desenvolvimento do software.

Um ator representado no sistema nãopode ser programado, ele fica fora doescopo do desenvolvimento do sistema,

e, provavelmente, não é alterado pelosistema. Observa-se, entretanto, que antrodução de um sistema denformações afeta muito além do que as

fronteiras definidas inicialmente,podendo ir para além dos usuários. Nonício do desenvolvimento de um

sistema um ator possui necessidades que



são expressas e consideradas comorequisitos do sistema de software.Quando o software é implementado, e a

necessidade iniciais são atendidas,surgem outras necessidades nosusuários, que foram provocadas pelantrodução do sistema, ou seja, o sistem

pode também alterar os atores. Esteefeito é, normalmente, desconsideradono desenvolvimento pela sua alta

complexidade e pela incapacidade deser modelado e tratado com precisão. Oanalista experiente pode tentar prever um sistema que se adapte à esta nova

realidade e incluir estes requisitos noproblema.



Exemplo

A figura abaixo mostra alternativas derepresentação de atores em umdeterminado sistema. Considerando quea melhor alternativa é aquela que

ncorpora uma quantidade maior denformação, temos que:



3.3.3. Caso de Uso

As necessidades dos atores sãorepresentadas nos casos de uso. Umcaso de uso é uma seqüência deransações ocorridas no sistema, que

refletem em algo de importância para oator que se comunica com este caso deuso. Os atores definem suasnecessidades na forma de objetivos aserem cumpridos pelo sistema, que sãocapturados pelos casos de uso.

O princípio, por trás deste diagrama, éque um sistema de software é criadopara atender os seus usuários,representados no diagrama pelos atores

Os atores demandam resultados do



sistema, que se organizam em objetivosrepresentados nos casos de uso. Umcaso de uso se traduzirá em uma série d

ações, que vão descrever como um ator poderá atingir o seu objetivo, assimcomo as alternativas e as exceções querão impedir a conclusão com sucesso

deste objetivo. Todos estes cenários denteração do ator com o sistema devem

estar inclusos na descrição dos caso de

uso.Utiliza-se um caso de uso quando se

deseja representar uma funcionalidade

de alto nível no sistema, ou pararepresentar um conjunto defuncionalidades esperadas por um ator.Para identificar os casos de uso



devemos consultar os atores, e observaras suas necessidades, agrupando-as eassociado-as aos atores. Um caso de uso

é composto por uma representaçãográfica e por um descrição textual, quesão descritas a seguir:

Representação Gráfica

Um caso de uso é representado,graficamente, por uma elipse em tornodo seu nome, como mostra a figura.Associado ao nome, um breve texto

descreve o objetivo que o caso de usoestá representando.



Figura 30 - Representação Gráfica dum Caso de Uso

O nome do caso de uso é, em geral,uma oração verbal curta que representa,no contexto do sistema, o objetivopretendido. Os atores formam o sujeito

da ação expressa pela oração. Destaforma, é conveniente utilizar verbos nopresente, no infinitivo ou no gerúndiopara identificar os casos de uso, como

mostram os exemplos a seguir:



Os diagramas de casos de uso podemser lidos colocando-se o ator comosujeito e os casos de uso como

predicado, na forma:

O Gerente (pode) aprovar créditoO Cliente (está) consultando

CatálogoO Comprador realiza a compra.



Figura 31 - Exemplos de Casos deUso

Descrição Textual

Associado a cada caso de uso umexto descreve os fluxos de eventos que

resultam no objetivo pretendido peloator. Todo caso de uso tem,

necessáriamente, um fluxo deatividades principal, que vai levar oator ao sucesso do seu objetivo. Aseqüência normal de atividades pode

apresentar caminhos alternativos aoluxo principal, assim como seqüências

de atividades que descrevem falhas qu

mpedem o ator de atingir o seu



objetivo. A figura mostra,esquematicamente, estes fluxos, quedevem ser descritos em um texto que

acompanha o caso de uso:

Figura 32 - Fluxos possíveis em umcaso de uso(a) principal, (b) alternativo e (c)

caminho com falha

A descrição dos casos de uso pode serescrita em uma linguagem informal, emum texto estruturado ou até mesmo com



um pseudocódigo. O importante é que adescrição de um caso de uso possa ser aprovada pelo cliente do sistema, e que

os projetistas possam entender oprocesso de negócio. Os casos de usopodem também ter pré e pós condições,que vão condicionar a seqüência deransações que devem ocorrer. As

precondições dizem que para o ator poder executar aquele objetivo são

necessárias algumas condiçõesanteriores, assim como a execução doobjetivo leva a uma condição posterior à execução (pós-condição).

Toma-se como exemplo o caso de usoonde um cliente consulta um catálogo deprodutos de uma suposta loja virtual.



Este caso de uso, chamado de ConsultarCatálogo pode ser descrito textualmentede forma não estruturada como:

Caso de Uso: Consultar Catálogo

Busca por um ou mais produtos emum catálogo de produtos. Os produtossão organizados por tipo e família. A

consulta pode ser feita selecionando-se



o tipo de produto e em seguidaescolhendo uma família daquele tipo.Os produtos podem ser ordenados por

reço ou por ordem alfabética donome. É possível procurar um produto

or parte do nome ou da descrição. Arocura fornece uma lista de produtos

onde o texto procurado foi encontradono nome ou na descrição. Se o usuárioda consulta já se identificou para o

sistema, a lista dos últimos 10 produtorocurados pode ser apresentada,acilitando a procura.

Este mesmo caso de uso também podeser descrito de forma estruturada, como

Nome: Consultar Catálogo



Objetivo principal : Permitir arocura de um ou mais produtos em um

catálogo de produtos organizado por

ipos e famílias de produtos.

Alternativas Alternativamente aprocura pode ser feita por uma palavraexistente no nome ou na descrição doproduto.

Exceções Se o catálogo não oferece oroduto procurado, oferecer uma listacom os dez produtos mais

rocurados.Se mais de 50 produtos

atendem o critério de procura, osrodutos são apresentados em grupos

de 50.



Précondições : O cliente deve estar cadastrado,

Pós-condições : Após a procura osrodutos encontrados passam a compo

a lista de produtos procurados, queodem seguir para o processo de

compra.

A descrição estruturada é mais formal

e por isso mais completa que umadescrição não estruturada e informal. Adescrição informal é suficiente namaioria dos sistemas, principalmente

para a validação do modelo decontexto por parte dos usuários. Noentanto, a descrição estruturada é maisadequada na aplicação dos Casos de



Uso em um método formal paradesenvolvimento de sistemas.

Colaboração entre os Casos de Uso

Os casos de uso podem colaborar comatores e com outros casos de uso. Estascolaborações são expressas no diagrampor meio de ligações entre os elementos

que colaboram. As ligações podem,opcionalmente, ter uma seta que não temvalor semântico, ela apenas orienta aeitura do diagrama. As colaborações

dos casos de uso são semprebidirecionais, o que quer dizer que podehaver troca de informação nos dois

sentidos da colaboração.



Os atores se comunicam, controlam erecebem informações dos casos de uso.Uma colaboração entre os casos de

uso e os atores indica que os objetivosdo ator são definidos pelos casos deuso. Deve-se verificar se todos osobjetivos do ator estão presentes e sãobem definidos.

Um caso de uso pode colaborar com

outros casos de uso para conseguir cumprir o seu objetivo principal. Issoquer dizer que um objetivo principalpode ser decomposto em objetivos

ntermediários de outros caso de uso.Esta decomposição fará com que oscasos de uso mantenham entre si umarelação de dependência, representada



pela seta tracejada. O caso de usodependente está na origem da seta, e ondependente no destino da seta.

Figura 33 - Colaboração entre osCasos de Uso



3.3.4.Considerações Gerais sobre

o Modelo de Contexto

Algumas considerações gerais são

mportantes na formação do diagrama decasos de uso, e podem auxiliar a criar um diagrama correto.

Independência entre Casos de Uso

Os casos de uso devem ser escolhidosde modo a serem independentes entre siapesar de poderem existir relações entreles. Isso se deve para evitar que hava

uma confusão entre as funcionalidades



especificadas. Erros na separação podealgumas vezes, levar à inconsistênciasentre os casos de uso. Um caso de uso

pode especificar um tipo deresponsabilidade que é negada por outro. O modelo de contexto não temmeios de evitar ou lidar com estasnconsistências, que serão tratadas por

outros modelos, posteriormente.

Granularidade dos Casos de Uso

Um dúvida frequente durante a

construção do modelo de contexto é ograu de detalhes que se deve adotar aose criar em caso de uso. Por definição,

os casos de uso reúnem um conjunto de



ransações que conduzem à um objetivodo ator. Assim, se por um lado, os casode uso devem ser mais complexos do

que uma simples transação; por outroado os casos de uso não devem

compreender um número muito grandede transações. Um número grande deobjetivos, poderiam ser decompostosem alguns casos de uso. A situaçãodesejada é uma situação intermediária.

Espera-se que os casos de uso escondauma complexidade razoável, que serãoexploradas, posteriormente, no modelosconceituais e detalhados (pelos

diagramas de seqüência e colaboração)Os fluxos de informação textual conduzo leitor do diagrama a uma estruturafuncional do sistema. Na análise



conceitual, os fluxos de eventos vãoconduzir o analista aos conceitosfundamentais do sistema, que serão

distribuídas entre as classes do sistema.ão se deve confundir os casos de uso

com as classes. Berard (1996) destacaeste e outros cuidados que se deve ter aaplicar os Casos de Uso para nãocomprometer a aplicação do paradigmade objetos no decorrer do projeto.

Evitar a decomposição de casos deuso

Outro erro comum, na aplicação doscasos de uso, é a tentação de se realizar

uma decomposição de objetivos dos



atores, como é comum na análiseestruturada. Criando-se casos de usontermediários como etapas de um

processo, transformando-se o diagramade casos de uso em um fluxograma deprocessos. Pode-se estabelecer umarelação direta entre um diagrama decontexto da análise estruturada ediagrama de casos de uso, mas não sedeve transformar um diagrama de casos

de uso em um fluxograma. Na decomposição funcional há uma

grande proximidade com as funções, na

abordagem de dados, a proximidade écom os dados, e na abordagem deobjetos a proximidade é com o objetos.Como os casos de uso tem uma natureza



funcional, a mudança para objetos,realizada nas fases seguintes da análise,pode provocar erros. Por exemplo,

alocar casos de uso a equipes diferentesde desenvolvedores, provoca umdesastre na modelagem orientada aobjetos, mesmo que desubsistemas diferentes, porqueprovavelmentem, haverá a criação deobjetos iguais nas duas equipes com

funcionalidades semelhantes e quedeveriam estar agrupadosBerard,1996).

Integrar o cliente na modelagem

O diagrama de casos de uso deve ser



construído em conjunto entre os usuárioe demais projetistas. A notação simplesfacilita o entendimento e estimula a

crítica ao modelo, permitindo validá-loá nas fases iniciais da análise. Como o

diagrama de casos de uso traduz umavisão de fora para dentro do sistema,descrevendo o que o sistema deve fazeré importante a aprovação do cliente eusuários para o sucesso do projeto.

Deve-se, entretanto, evitar o excessode formalismo na elaboraçãos dos casode uso. Desaconselha-se, por exemplo,

uso de recursos computacionais naelaboração dos casos de uso quando daapresentação dele para os seus usuáriosque pode afastá-los do processo de



desenvolvimento. O uso de umretroprojetor, quadro-branco, flip-chartpapel e lápis é encorajado ao se discutir

um modelo com os usuários. Estasferramentas são mais familiares eaproximam os usuários leigos emcomputação com o desenvolvimento dosistema. O computador ou sistemassofisticados de software podem ser considerados barreiras à participação

dos usuários nesta fase do projeto.A validação de um sistema pelo

cliente, nas fases iniciais so projeto,

garante que está se construindo osistema correto. Isto é, as reaisnecessidades dos usuários estão sendoconsideradas e atendidas. Para isso é



necessário revisar, iterativamente, omodelo de contexto inúmeras vezes comos usuários. Em alguns casos, pode ser

necessário criar um protótipo danterface, para apresentar ao usuário,

que assim pode se assegurar que osistema irá atendê-lo, pois visualiza alia operação do sistema. A identificaçãodos requisitos de interface podem ser extraídos facilmente do diagrama de

casos de uso, analisando as relaçõesentre um ator e os casos de uso comquem ele se comunica. É de se esperar que para cada caso de uso deva haver

uma interface para acionar o objetivo ereceber as respostas.



Comprometimento com aimplementação

O ocultamento de informaçãoInformation Hiding ) é o processo deornar certas partes do sistema de

software inacessíveis. Sugere-se que osdetalhes do sistema, as decisões deprojeto difíceis ou que provavelmentevão mudar, devam ser ocultadas do

sistema. Assim, o resto do sistema temacesso apenas as decisões bemdefinidas, e inalteradas. Com aespecificação descrita pelos casos deuso deve-se evitar expor detalhes emdemasia, ou impor decisões que serãoomadas no projeto ou na

mplementação. Deve-se procurar evitar



a tentação de especificar a estruturanterna ou caraterísticas demplementação que condicionem,

exageradamente, o componente,imitando-o quando da suamplementação.

Casos de Uso em Testes

Um caso de uso é descrito por cenáriode sucesso, alternativos e de fracasso deum objetivo do ator no sistema.Analisando um caso de uso é possível s

criar um conjunto de dados de entradaque simule cada um destes cenários.Assim, para cada caso de uso é possíve

se construir um caso de teste, que



garante que o sistema, ao implementar ocaso de uso, será completamenteestado. Essa é uma importante

característica de um projeto de softwarecom casos de uso, que irão orientar todoo desenvolvimento do softwareatendendo as necessidades dos usuáriosSe houver dificuldade em se estabalecerestes testes, deve-se suspeitar da clareze da precisão deste caso de uso, ou até

mesmo da sua real necessidade.

Cuidados nas descrições textuais

Probasco (2001) destaca o cuidadoque deve haver, por parte dos

desenvolvedores, na redação da



descrição dos casos de uso. Emespecial, ele destaca uma atenção maiorpara a palavra “deve”. Como os

requisitos dos casos de uso expressam avontade dos usuários, utilizar a palavra“deve” pode gerar obrigações que nãopodem ser cumpridas, ou limitar,exageradamente, a implementação dosistema. Como prática geral, não serecomenda o usar a palavra “deve”,

sugerindo substituí-la por “sugere-se”,“recomenda-se”, etc. O importante docaso de uso é que ele sirva como meiode comunicação entre o cliente e os

desenvolvedores.



3.4. Exemplo deAplicação: Sistema deVendas de Loja

Este exemplo retoma o sistema devendas da loja descrito no capítuloanterior, para introduzir aformalidade do modelo de contexto e

dos diagramas de casos de uso.



3.4.1. Descrição deSubsistemas

Em uma loja qualquer, o sistema devendas deve estar integrado a outrossistemas de informação internos,mportantes para o gerenciamento do

empreendimento. Pode-se representar cada sistema de informação como um

subsistema da loja, caracterizado por upacote, como exemplifica a figura. Nafigura mostra que o subsistema devendas é dependente do sistema de

cadastro do cliente e do sistema deestoque, que poderia ser o responsávelpor manter uma lista de produtos. Adependência entre estes subsistemas fica



clara em um diagrama de pacotes.

Figura 34 - Subsistemas relacionadosao sistema da loja

Neste exemplo, explora-se apenas uma

pequena parte do subsistema de vendas.



Da descrição do sistema, elaborada nocapítulo anterior, pode-se extrair que:

O caixa faz a venda em umterminal (POS)O caixa le o código do produtoO caixa identifica o cliente pelo

CGC O caixa verifica o parcelamento

Vemos que o ator do sistema é ocaixa, e que ele vem ao sistema com treobjetivos, identificados nos três casosde uso da figura abaixo, a saber:

dentificar produto, Identificar cliente eAutorizar o parcelamento.



Figura 35 - Diagrama de Casos deUso dos Processos de Venda



3.4.2. Descriçãodos Casos de Uso

Segue uma descrição textual dos casosde uso identificados acima.

Identificar Cliente

O caixa recebe o número do CGC docliente. Caso o cliente estiver presenteno cadastro da loja, verifica-se os dadodo cliente como nome e o seu crédito.

Um cliente especial pode ter o dobro docrédito do cliente comum.



Identificar Produto

O caixa deve ler o código no produto,em um leitor de código de barras, oudeve teclar o código. A loja éresponsável por manter uma lista de

seus produtos, com os dados de nome epreço, entre outras informações sobre oproduto. Com o código identificado, ocaixa recebe os dados do produto.

Autorizar parcelamento

O caixa de posse dos dados do produte de um cliente, pode verificar se ocliente pode fazer a compra parcelada.

A venda será realizada se a dívida do



cliente, na compra parcelada, for menordo que o crédito que o cliente possuicom a loja. O sistema de vendas deve

aprovar a venda ou não.

Este modelo poderia ser enviado parao cliente, irir analisar a especificação e

assegurar que o software, quandodesenvolvido corresponde às suasexpectativas. Esta é a finalidade do

modelo de contexto.



4. Modelo

Conceitual

Este capítulo apresenta uma técnicaara se desenvolver um modelo

conceitual do projeto de software. O

objetivo aqui é identificar os principaiconceitos presentes em um problema erepresentá-los em classes, dando os

rimeiros passos na direção daconstrução de um modelo orientado aobjetos do problema. Este objetivo éconseguido utilizando a técnica dos

cartões CRC. Originalmente criada



ara ensinar orientação a objetos, estaécnica é aplicada aqui como umaorma de transformar os

requisitos levantados no modelo decontexto nas classes do modeloconceitual.



4.1. Introdução aoModelo Conceitual

Este capítulo descreve o processo decriação de um modelo conceitual de um

sistema de software. Este modelo éobtido a partir dos requisitos levantadopelo modelo de contexto. O analistadeve se posicionar suficientementepróximo do sistema para extrair dosrequisitos do problema os conceitosprincipais, sobre os quais será

construída a solução. Esta aproximaçãogradativa do sistema, que estaabordagem de modelagem recomenda,evita a sobrecarga de complexidade no

modelo nas fases iniciais do processo



de desenvolvimento, facilita oentendimento do problema e auxilia nodesenvolvimento do sistema de

software.

Enquanto o modelo decontexto descreve, funcionalmente, o

sistema sob o ponto de vista do usuárioexterno, o modelo conceitual dá asprimeiras noções de como será o

nterior do sistema. No modeloconceitual são esboçadas as idéiasprincipais que compõem o núcleo dosistema, descrevendo-o de dentro pra

fora. A modelagem conceitual seencontra entre as práticas propostas porLarman (1997) em seu livro sobre aaplicação da UML. Neste trabalho, o



modelo conceitual é definido como arepresentação de conceitos ou objetosdo domínio do problema. A estratégia

recomendada é de se criar um rascunhodo diagrama de classes, onde a ênfaseestá em descobrir os requisitos maisevidentes, antes de lançar mão de umanvestigação aprofundada. Mais tarde

nos ciclos seguintes dodesenvolvimento, o modelo conceitual

poderá ser refinado, incrementalmente, estendido para considerar os demaisrequisitos.

O modelo conceitual está tambémpresente em métodos incrementais dedesenvolvimento de sistemas. Asprimeiras fases do processo criam uma



visão da arquitetura completa dosistema. Uma arquitetura que, nas fasesseguintes, orienta a produção de versõe

do sistema. Assim, cada versão chega,ncrementalmente, mais próxima da

visão da arquitetura completa.

O modelo conceitual captura osconceitos do sistema em um diagrama dclasses. O diagrama de classes é a

representação fundamental damodelagem orientada a objetos, e evolude uma visão conceitual para uma visãodetalhada, com o desenvolvimento do

sistema. No modelo conceitual declasses é possível descrever oselementos principais de um sistema,suas características individuais e como



eles se relacionam.

A identificação de classes e das suas

nter-relações é uma das etapas maiscomplexas da análise orientada aobjetos. Para sistematizar esta busca,apresenta-se a técnica dos cartões CRC

Esta técnica é um método eficaz para sefazer a transição do modelo decontexto para o modelo conceitual.

Proposta por Beck e Cunningham (Beck1989), o uso dos cartões CRC facilita aaplicação do paradigma de objetos naanálise de um problema de software, e

ncentiva o envolvimento de usuáriosnas fases iniciais da análise. No finaldeste capítulo, desenvolve-se o modeloconceitual do conhecido jogo da forca,



um dos casos estudados neste trabalho.Este exemplo é retomado no capítulo 6 eem o seu código construído na

inguagem Java no apêndice.



4.2. Diagrama deClasses

Para se construir algo seguro émportante se ter uma base sólida. Uma

afirmação verdadeira tanto para umaconstrução civil, como, por exemplo, naconstrução de um sistema de software.Para se obter um sistema de softwareconfiável é necessário criar,nicialmente, uma estrutura sólida e

estável. Sobre esta estrutura são

armazenadas as informações do sistemae são desenvolvidos os processosnecessários para a solução do problemaem questão. A estrutura de um sistema

de software é formada pelas classes do



sistema. Analogamente ao esqueleto dosanimais, as classes formam umaarmação que dá a forma ao sistema. As

qualidades de um sistema são garantidapor um conjunto de conceitosfundamentais, bem definidos, capturadonas classes e que acompanharão osistema da concepção à implementação.

Classes são matrizes de objetos, elas

dentificam grupos de elementos dosistema que compartilham as mesmaspropriedades. A diferença entre classese objetos já foi assunto do capítulo 2,

mas aqui esta diferença é revista à luzda análise de requisitos. Os objetos sãoos elementos concretos envolvidos nasransações dos sistemas, criados a parti



das definições abstratas das classes. Osobjetos são instâncias das classes.Freqüentemente, a descrição de um

sistema descreve um caso, uma situaçãoem particular onde o personagem é oobjeto. Na representação, usa-seescrever os nomes dos os objetos por etras minúsculas e das classes por etras maiúsculas.

As classes representam um conceitomportante para o problema em questãoEnquanto uma classe descreve umconceito abstrato do domínio do

problema, um objeto representa umelemento deste conceito, que é utilizadono sistema, de modo concreto. Ao criar um objeto, com base em uma classe, ele



assume valores para os atributos,definindo um estado e herda umcomportamento das classes que permite

alterar este estado. Os estados e oscomportamentos são compartilhados poodos os objetos da mesma classe, e sãodefinidos na fase de análise.

A UML incorporou a representação declasses utilizada na OMT de

Rumbaugh (Rumbaugh et al., 1994) compequenas alterações na notação. Asclasses são identificadas por retângulosdivididos horizontalmente em tres

porções, como mostra a figura. No terçosuperior encontra-se o nome da classe,no terço médio a lista de atributos e noerço inferior a lista de operações que



esta classe pode realizar. Apesar destaser a forma básica de representação,existem formas alternativas que variam

de acordo com o interesse derepresentação e a precisão desejadas.

Figura 36 - Representação típica deuma classe



A figura abaixo mostra algumasalternativas de representação da classeLoja do problema do capítulo 2. Na

figura a classe Loja possui desde umarepresentação simplificada até umarepresentação bem detalhada, onde osatributos e as operações são descritoscom grande precisão e adornados por símbolos que irão definir a suavisibilidade, valor inicial e tipologia.

Para efeito do modelo conceitual iremoadotar a representação (a ) ou (b),deixando a notação (c) para o modelodetalhado, que é o assunto do capítulo

seguinte.



(a) (b)(c)

Figura 37 - Formas alternativas de se

representar uma classeOs atributos das classes formam uma

estrutura que permite o armazenamento

de informação. Podemos ter objetosencapsulados nos atributos das classes,com a sua própria estrutura de atributose a sua própria capacidade de

armazenamento de informações.



As operações são as mensagens que aclasse pode receber, e que definem asfuncionalidades que aquela classe está

apta a realizar. Os objetos relacionadoscom a classe podem oferecer a elafuncionalidade adicional na forma demensagens que são trocadas. Uma classesolada é, essencialmente, um depósito

de informações nos seus atributos eoferece ao sistema um conjunto de

funcionalidades definidas pelas suasoperações. Para fazer uso destaspotencialidades as classes precisam serelacionar.

No exemplo da loja, do capítulo 2,foram identificados os conceitos deProduto, Cliente, ClienteVIP e Loja.



Cada um com suas propriedades como oome do Cliente, o Código do Produto,

etc. O trompete que possui o código 107

é um objeto da classe Produto. CharlieParker é o nome de um objeto da classeCliente, Charlie Mingus é o nome de

outro objeto da classe ClienteVIP.Como é um ClienteVIP possuirá umcomportamento de crédito diferente doCliente, que permite parcelar as

compras de maior valor. O exemplomostra que os conceitos, atributos ecomportamentos são definidosuntamente com as classes, mas só seornam reais quando as classes seornam objetos durante o processamento

do software. Vale observar ainda, que a

classe Loja, na figura possui na sua



definição uma lista de objetos da classeCliente (listaClientes) e uma lista deobjetos da classe Produto

(listaProduto). Este exemplo mostracomo os conceitos podem se relacionar para criar conceitos mais complexos.



4.2.1.Relacionamento entre as

classes

Sistemas orientados a objetos são

formados por conjuntos de classes. Umaclasse não pode atender isoladamenteodas as necessidades do problema, e

por isso ela se integra às outras, para

untas apresentarem uma solução aoproblema. Em conjunto, as classesrocam mensagens para realizar os

objetivos do sistema. O relacionamentoentre as classes serve de caminho paraesta troca de mensagens, permitindo queas classes se “conheçam”, e criando um

caminho que possibilita a comunicação.



As classes podem se relacionar demodos que variam de acordo com asafinidades existentes entre as classes.

Os relacionamentos podem ser fracos,ndicando que as classes não possuem

uma grande afinidade, ou fortesatestando uma grande interdependênciaentre elas. Seguindo esta escala,podemos classificar os relacionamentoscomo:

Dependência (mais fraco)AssociaçãoAgregação

Herança (mais forte)



4.2.2. Dependência

O relacionamento mais fraco é adependência. Representada por umaseta tracejada ligando as classes, adependência parte da classe dependente

e aponta para a classe independente. Nafigura abaixo, a classe A depende daclasse B, o que quer dizer que, dealguma forma, não especificada pelarelação, os atributos ou as operações daclasse A dependem da classe B. Adependência não indica como ocorre

esta dependência, mas serve parandicar que estas classes devemparticipar juntas do sistema.



Figura 38 - Exemplo de dependência:depende de B

No exemplo da loja do capítulo 2,podemos dizer que a classe Lojadepende das classes Produto e ClienteEsta dependência é representada pelassetas que ligam estas classes na figura

abaixo. A dependência pode evoluir, emuma fase posterior da modelagem, paraoutro tipo de relacionamento que definamelhor a afinidade entre as classes.



Figura 39 - Exemplo de dependênciaentre as classes.

A dependência é um relacionamentocomum entre os pacotes. Ela representao fato de que existe algum tipo derelacionamento entre as classes que

compõem os pacotes e,



conseqüentemente, os pacotes estãoambém relacionados. Como o

relacionamento entre os pacotes não est

claramente determinado porque dependedas classes que eles contém, usa-serepresentá-lo pela dependência.

Figura 40 - Exemplo entre

dependência entre os pacotes



4.2.3. Associação

As associações aparecem quando háum nível maiorde envolvimento, e maisbem definido do que na dependência,entre as classes. Na associação as

classes estão ligadas semanticamenteumas às outra. Ou seja, as classesmantém-se independentes, mas guardamuma algum tipo de significado na suarelação. Esta relação já permite a trocade mensagens entre as classes na ajudapara o cumprimento de suas

responsabilidades. Na figura abaixo aclasse R está associada à classe S. Aclasse R pode chamar as operações de Spor intemédio do objeto varS que é um



objeto da classe S, e que representa aassociação. A representação daassociação é uma linha que interliga as

classes. Esta linha pode possuir umaseta indicando a direção da associação.Outros adornos das associações serãovistos mais à frente no texto.

Figura 41 - Exemplo de associação

entre as classes

Deve-se observar que uma associaçãosignifica que existe um objeto do tipo da



classe associada na classe de origem.Assim o objeto varS, que é do tipo S,está presente na classe R através da

associação. Estando presente, R pode secomunicar com S através de varS.



4.2.4. Agregação

Alguns tipos de associação podemexigir um aumento no grau deenvolvimento entre as classes o que criaa agregação. A agregação é equivalente

à associação mas indica que as classespossuem uma dependência existencial,sto é, uma classe só existe em conjunto

com as suas agregadas. A classe todo écomposta pela(s) classe(s) parte. Nafigura abaixo a classe X é composta pelclasse Y, o que quer dizer que a classe

X possui um objeto da classe Y,dentificado por varY, que também é o

nome da relação. A agregação érepresentada por uma seta unindo as



classes com um losango indicando aclasse todo.

Figura 42 - Exemplo de agregação

No exemplo da loja apresentado nocapítulo 2 a classe POS possui umobjeto da classe Produto chamado deoProduto e um objeto da classe Cliente

chamado oCliente. Estes objetorepresentam o produto que será vendidoe o cliente interessado em comprá-lo. OPOS os utiliza para o processamento



das ações de venda. Estes objetosforam criados e transmitidos ao POSpela classe Loja, mas fazem parte da

classe POS e por isso são representadocomo uma agregação onde o todo é oPOS e as partes são oProduto e

oCliente. Supondo, por hipótese, que oPOS venha a ser desligado, os objetosda venda que não foi ainda concluídaserão perdidos. Assim também a lista de

clientes e a lista de produtos fazem partda Loja. Supondo que a loja sejavendida, o novo dono recebe também aista de clientes e a lista de produtos,

eles são indissociáveis. No exemplo, asistas de clientes e de produtos são

fortemente dependentes da Loja. Sendo

este o fator determinante na decisão na



modelagem deste relacionamento comouma agregação.

Figura 43 - Exemplo de Associaçãoentre Classes



Pode-se considerar a agregação comoum caso especial da associação, onde hum vínculo maior entre as classes. Este

vínculo pode crescer a ponto de umaclasse depender existencialmente daoutra. O que significa dizer que se aclasse todo deixar de existir, as classespartes deixam também de fazer sentidopara o sistema. Na associação, asclasses se mantem independentes, isto é

elas podem participar de outrasassociações no projeto onde não hajaesta depedência e podem ser nstanciadas isoladamente.



4.2.5. Herança

Um tipo de relacionamento importantepara o desenvolvimento de sistemasorientados a objeto é a herança. Oconceito de herança também foi

apresentado no capítulo 2 e secaracteriza por criar umahierarquia entre as classes do sistema.

esta hierarquia, algumas classes,chamadas de superclasses, servem dematriz para a criação de outras classes,as subclasses, que especializam as

superclasses originais.Constrói-se uma hierarquia de

generalização-especialização indo de

superclasses mais gerais para



subclasses mais específicas. Ao seespecificarem, as subclasses aproveitamudo o que já foi definido pelas

superclasses pela herança. Assubclasses herdam atributos, operaçõese relacionamentos da classe mãe, maspodem modificar o material herdado,sobrescrevendo os atributos e operaçõeou criando novos atributos ouoperações.

A herança é representada por umainha unindo as classes com um triângulondicando a superclasse. No exemplo da

oja do capítulo 2 a classe Cliente ésuperclasse para a classe ClienteVIP,como mostra a figura.



Figura 44- Classes Cliente e

ClienteVIP com operações e atributos

A classe ClienteVIP herda da classeCliente todos os atributos e todas as



operações como a setCGC, getNomeentre outras. Entretanto, a classeClienteVIP modifica a classe Cliente

alterando a operação getCredito.Conforme as regras no negócio o créditodo ClienteVIP possui o dobro do

crédito do Cliente. A figura mostra asclasse com as operações sobrescritas ea tabela mostra a diferença entre amplementação das duas operações.

A implementação das operaçõesgetCredito() apresentadas acima foramforam escritas na linguagem Java, e

retornam um valor inteiro referente aocrédito do cliente, armazenado noatributo credito. A referência àsuper.getCredito() na implementação da



classe ClienteVIP indica que será usada operação getCredito() dasuperclasse Cliente, que é multiplicado

por dois, como manda a regra denegócio.

Operação

getCredito doCliente

Operação getCredito

doClienteVIP

[4]

public intgetCredito()

{


{



return(credito);

}

return(2*super.getCredito())

}

A herança é uma forma eficiente dedistribuição de funcionalidades. Assubclasses dispõem de todas asfuncionalidades que as superclasses

oferecem. Assim a criação de ummodelo orientado a objetos é umprocesso de classificação, busca-secriar uma hierarquia de classes que

compartilhem as operações umas dasoutras.

No exemplo, é importante notar que



uma classe ClienteVIP é também umaclasse Cliente, e pode ser usada sempreque uma classe cliente puder ser

aplicada. Por exemplo, a lista declientes comporta as classes Cliente eClienteVIP. A definição das classes foi

feita quando do carregamento dasclasses ao iniciar o sistema.



4.3. A técnica doscartões CRC

Uma das maiores dificuldadesenfrentadas por quem está iniciando na

écnica da orientação a objetos éencontrar as classes. É desejado sempremanter uma boa correspondência entre omodelo conceitual e o domínio doproblema, e também uma grandeestabilidade dos conceitos expressospelas classes. No entanto, as classes são

conceitos abstratos e as vezes de difícilcompreensão por parte da equipe deprojeto, ainda mais por parte de clientesque por alguma razão devem estar

envolvidos nesta fase do projeto de



software. Pode-se partir do modelo decontexto, já validado, que delimita osistema sob o ponto de vista funcional,

para tentar extrair deste modelo osconceitos fundamentais do sistemacapturados pelas classes, mas o trabalhoainda assim não é dos mais simples.

A proposta da técnica dos cartõesCRC é tornar o conceito abstrato das

classes em algo concreto e manipulávelpelos analistas, tornar a identificaçãodas classes um processo interativo coma participação efetiva dos usuários. A

déia, proposta por Beck e Cunnigham1989), utiliza cartões de papel, muito

utilizados em bibliotecas, pararepresentar as classes e organizar um



rabalho em equipe para identificar edescrever as classes de um sistema.

A modelagem CRC é uma técnicamuito efetiva para identificar e validaros requisitos dos usuários. Ele pode ir de mão em mão como os use case e os

rotótipos, e conduz diretamente aomodelo de classes. O objetivo dodesenvolvimento de aplicações é

resolver problemas de negócio, e nãosatizfazer a curiosidade intelectual dosdesenvolvedores que só querem brincacom novos brinquedos. Trabalhe com

os seus usuários, e não contra elesScott Ambler, 1998)



Figura 45- Exemplo de Cartão CRC



4.3.1. Histórico docartão CRC

Os cartões CRC foram introduzidospor Kent Beck e Ward Cunningham em

1989 na OOPSLA

[5]

. A técnica atraiu aatenção da comunidade por ser umaécnica de fácil aplicação para um

problema difícil, que é o de descobrir e

definir classes. No livro Rebecca WirfsBrock (1991) detalhou o processo doscartões que se tornou conhecido como aécnica de projeto “por

responsabilidades”. Nancy Wilkinson1995) publicou sobre suas experiência

com CRC na AT&T. Bellin (1997)

oferece uma visão abrangente da técnica



e da sua aplicação. Mais recentementeKent Beck (1999) refere-se novamente àecnica dos cartões CRC nas fases de

modelagem da aplicação do seu métodoXP (eXtreme Programming ) dedesenvolvimento rápido.

A palavra CRC[6] é uma abreviaçãopara :Classe, Responsabilidade eColaboração, conceitos básicos da

modelagem orientada a objetos. Oscartões de CRC são cartões de índicemuito utilizados em arquivos ebibliotecas, que são utilizados pararegistrar as classes sugeridas, as coisasque elas fazem, e as relações com asoutras classes. Enquanto se escreve o

nome da classe, pode-se pensar no que



aquela classe deve saber de si mesmaresponsabilidade de conhecimento) e o

que ela deve saber fazer

responsabilidade de comportamento),pode-se ainda ver como a classe que seestá definindo se relaciona com asoutras classes no sistema. Pode-se ver como a idéia de encapsulamento epolimorfismo são reforçadas, ao semover uma responsabilidade de uma

classe para outra e criar umacolaboração.

Os cartões foram criados para dar uma

resposta à necessidade de documentar adecisões do projeto colaborativo.Projetar com cartões tende a progredir amodelagem do conhecido em direção ao



desconhecido, em oposição àabordagem top-down de decomposiçãousada na análise funcional. Os cartões

de CRC representam expícitamentemúltiplos objetos ao mesmo tempo.Entretanto, ao contrário de simplesmentacompanhar os detalhes da colaboraçãona forma de envio de mensagens, oscartões CRC colocam o projetista nofoco da motivação para colaboração

representando, potenciamente, muitasmensagens com frases em linguagemnatural.(Beck e Cunningham, 1989)

A natureza visual dos cartões de CRCé um importante catalisador para asolução do problema. Ao mover umcartão sobre a mesa pode-se obter nova



déias da equipe de projeto. Talvez maimportante que as tarefas básicas, os

cartões ajudam na solução dos

problemas porque favorecem o trabalhoem equipe.



4.3.2. Vantagensdo trabalho em equipe

Necessitamos de uma ferramenta quenos ajude a resolver problemas. Umresolvedor de problemas trabalha comalternativas, se uma delas é escolhida éporque um número maior de associaçõeógicas levaram a esta escolha. Quando

um grupo de pessoas estão tentandoresolver um problema, eles estãoengajados em um processo que leva auma associação lógica. As ferramentas

que suportam e facilitam este tipo desolução de problemas são valiosas. Aferramenta é projetada para ser umcatalizador de novas idéias, a equipe



deve ser ao mesmo tempo paciente eaberta a novas idéias. Se a técnica for usada somente como um meio para

anotar as idéias velhas, a chance de umnsight, de uma nova idéia está

drasticamente reduzida. Quanto mais seentende como trabalhar em equipe, maischance de se ter de um sucesso nasolução.

Estudos mostram que um grupo terámais chance de sucesso na solução deum problema se este grupo for treinadona lógica de solução do problema antes

de ser apresentado ao problema. Aspessoas que estão concientes sobre a suestratégia de solução de problemas vãomelhores do que aquelas que dependem



de uma resposta insconsciente ou dasorte. Isso significa que o grande poder do uso dos cartões CRC está na equipe

de desenvolvedores que não somentesabe o que eles deve fazer, mas tambemsabem como resolver problemascomplexos. Por isso, recomenda-se umaabordagem de aplicação da técnica doscartões CRC que envolvem duasestatégias para facilitar a solução de

problemas: brainstorm e interpretação.role play).



4.3.3. Objetivosdos cartões CRC

A técnica dos cartões CRC tem comoprincipal objetivo o de facilitar orabalho de indentificação das classesde um sistema e das suas inter relaçõesprincipais. Ao mesmo tempo, a técnicaserve como meio para o aprendizado da

prática da modelagem orientada aobjetos e para o ensino dos conceitosenvolvidos. Sendo uma técnica de fácilutilização, ela incentiva o envolvimento

dos usuários no processo de análise eprojeto dos sistemas.

Os fundamentos da técnica dos cartões



CRC são os mesmos fundamentos daorientação a objetos, e serão revisadosaqui. Considera-se que os sistemas

sejam formados por objetos,categorizados em classes. As classesencapsulam atributos e operações quecaracterizam responsabilidades que osobjetos devem executar para o sistema.A análise orientada a objetos devedentificar estas classes e distribuir

entre elas as responsabilidadesdentificadas no levantamento derequisitos do sistema. Para cumprir ntegralmente as suas responsabilidades

as classes podem contar com a ajuda deoutras classes.

A técnica dos cartões CRC procura



responder às perguntas:

Quais são os componentes

(Classes) do sistema ?O que cada um deles devefazer (Responsabilidades) ?Como eles trabalham em

conjunto (Colaboração) ?

As respostas à estas perguntas sãoregistradas em um cartão como nafigura:



Figura 46 - Estrutura de um cartão

CRC Uma classe de um sistema orientado a

objetos cumpre parte das

responsabilidades do sistema, e confiaem outras classes para ajudá-la acompletar sua missão no sistema. Cadaclasse é representada por uma cartão



CRC, com o nome da classe ocupando ainha de topo do cartão. Parte-se de

requisitos do sistema, previamente

evantados, que são transformados emresponsabilidades nas classes. Asresponsabilidades são listadas àesquerda do cartão, e eventuaiscolaborações de outras classes paraaquela responsabilidade à direita.

Ao mesmo tempo que é um modoeficaz para se anotar informação sobreclasses, os cartões CRC criam ummotivo para as pessoas envolvidas com

o problema se agruparem para trocar déias. É uma técnica infomal que reduz

o conflito e amplia a socialização nodesenvolvimento de software. Um dos



elementos fundamentais para o sucessode projeto de software é o trabalho emequipe e o aprendizado ativo. Ao

contrário de ler um relatório de outrapessoa, uma equipe de CRC está semprefazendo algo que contribui para omodelo do sistema, isto é, eles estãosempre aprendendo alguma coisa.Bellin, 1997)



4.3.4. Organizaçãopara aplicação da técnica

Baseado em Bellin (1997) propõe-seuma organização para aplicação daécnica, apresentada aqui para ser aplicada após a modelagem de contextoem um processo de desenvolvimento deum sistema. O método é organizado nas

seguintes etapas:1. Formação da equipe de trabalho,

2. Uso de brainstorm paradescrição dos requisitos do sistema,

3. Identificar classes candidatas,



4. Analisar os requisitos

a. Identificar e Distribuir as

responsabilidades,

b. Caracterizar oscolaboradores, e

c. Simular a dinâmica docenário, validando o modelo.

5. Tradução dos cartões em modeloconceitual de classes



Figura 47 - Esquema da aplicação daécnica de CRC



4.3.5. Formação daequipe de trabalho

Uma das principais vantagens do usodos cartões CRC é a integração dosusuários no processo de modelagem dosoftware. Para explorarmos estapossibilidade é necessário criar umaequipe de trabalho composta de

analistas e usuários. Uma boa proporçãoé a de um analista ou desenvolvedor para cada usuário especialistas noproblema em estudo. É importante

manter pequena a equipe pequena, entre5 a 6 pessoas, o que leva a se compor aequipe com 2 a 3 analistas e 2 a 3usuários. Um analista deve fazer o pape



de facilitador e atuar como coordenadordos trabalhos, cuidar da agenda e danfra-estrutura para apoiar a reunião de

rabalho.

Entre os analistas deve haver pelomenos um especialista em modelagem

orientada a objetos, que deve orientar oquestionamentos e tomar as decisõesrelativas à representação das classes.

Alguem deve, durante a reunião, assumio papel de secretário da reunião e fazer os registros necessários.

O quadro abaixo pode ajudar naformação das equipes de modelagem.



Reunião CRCProjeto:_______________ Local:_________________

Data:____/ ____/ _____

Usuário1

U2

Especialista do Problema

Especialista em Objetos

CoordenaçãoFacilitador

Secretário

AgendaMaterial de Apoio

Coffe break

Outros

As reuniões devem ter uma agenda

definida com antecedência, e devem ser



precedidas sempre com um breverevisão da figura do cartão e da técnicaque se está aplicando, esta introdução

visa garantir que todos tenham umentendimento, ao menos superficial,sobre o método. Os cartões devem ser sempre escritos utilizando aerminologia do usuário. Para explicar ermos técnicos e pouco comuns pode-s

criar um glossário de termos que será

útil para os desenvolvedores terem umamelhor compreensão do significado doscartões.

Durante as reuniões deve-se manter baixo o nível tecnológico, isto é, deve-se evitar o uso de computadores eprogramas de modelagem. Com eles



corre-se o risco de aumentar a distânciaentre os usuários, que não temfamiliaridade com estes meios, e os

analistas. Entretanto, o uso de protótipoe rascunhos de telas e relatórios podemajudar a mostrar para os usuários aspossibilidades de implementação doscartões. Na maioria dos casos uma únicreunião não será suficiente, o que dá aoportunidade para a preparação do

material nos espaços de tempo entre osencontros. Se não houverem reuniõesprodutivas o desenvolvimento podeornar-se demasiadamente lento.

Portanto, para ter uma reunião maisdinâmica e produtiva:

Organize os cartões e os protótipos



entre uma reunião e outra,Inicie a reunião revisando o que foobtido na reunião anterior,

Encerre a reunião resumindo o quefoi discutido até aquele ponto,Ao final, agende uma nova reuniãose necessário.Divulgue os resultados da reuniãoo mais rápido possível.



4.3.6. Brainstormpara especificação do

sistema

O brainstorm é uma estratégia

utilizada para levantar os requisitos deprojeto em um trabaho em equipe, queem sido usada em várias equipes derabalho, desde equipes de publicidade

até grupos de teatro. Quando uma equipede analistas se propõe a trabalhar em umsistema, a troca de idéias de um modorápido e desinibido, como deve ser nobrainstorm, pode levar a um resultadomelhor do que o trabalho individual.Bellin; Simone, 1997)



O modelo de contexto oferece umadescrição dos objetivos dos casos deuso para dar a partida para a modelagem

conceitual. Mesmo quando não existematerial para dar início à modelagempode-se utilizar do brainstorm com aequipe de projeto para detalhar adescrição funcional do sistema. Obrainstorm é uma técnica útil até mesmopara a elaboração do próprio modelo de

contexto.Uma reunião para modelagem do

sistema se inicia com uma descrição

deste sistema. Esta descrição podepartir da leitura do modelo de contexto,ou na inexistência deste, do materialdisponível sobre o problema. Na



reunião de trabalho a participação deodos deve ser estimulada. O objetivo

desta etapa do trabalho é levantar as

funcionalidades que o sistema devepossuir para atender os seus usuários. Aexperiência dos especialistas émportante pois é deles o conhecimento

das necessidades reais a serematendidas. É importante um papel dequestionamento, por parte dos analistas,

para obter um modelo completo epreciso. A palavra, em uma reunião deanálise, deve ser dada a todos. Pode-seregistrar tudo em um gravador, mas

como a transcrição deste material édifícil, é preferível registrar a reunião,diretamente, em papel.



No decorrer do brainstorm se contróiuma descrição do sistema na forma deuma lista organizada de requisitos. O

produto final da etapa do brainstorm éesta descrição refinada pela análise,discussão e ponderação da equipe deprojeto. O papel do facilitador e dosecretário são essenciais na elaboraçãoda lista de requisitos, quando alguns dorequisitos listados podem ser retirados,

assim como novos requisitos podem serncluídos.



4.3.7. Identificar aclasses candidatas

De posse da lista de requisitos obtidaspelo brainstorm, e da descrição doscasos de uso do modelo de contexto épossível iniciar a procura pelas classesAs classes definem um nível deabstração do problema. Como regra

geral, as classes aparecem comosujeitos nas ações listadas nosrequisitos. Analisando, por exemplo, osrequisitos abaixo:

O cliente pede empréstimo;



O pedido possui um prazo previstoara entrega.

identificam-se : cliente e pedido comoconceitos importantes e candidatos à se

ornarem um cartão e portanto umaclasse.

Essa não é a única fonte de classes. Asclasses podem estar nos documentos erelatórios do sistema, nos papéis dospersonagens envolvidos nas ações,

assim como em qualquer outro elementomportante que guarde algumanformação, ou que tenha alguma ação

no problema estudado.



Uma grande barreira na modelagem é endência em se manter preso aos

mesmos modos de ver o mundo. O

analista habituado a uma abordagemfuncional ou de dados tem a tendência acontinuar pensando em termos de bancode dados e funções, e será mais difícilver as classes, e se utilizar dasvantagens da orientação a objetos.Analisar um conjunto qualquer de letras

para identificar as palavras que podemser formadas, é mais fácil, as vezes,criar uma palavra nova, se as letras nãoformarem uma palavra evidente. Pode-

se ficar olhando as letras e não ver aspalavras. Assim, para ter sucesso noencontrar e dar nomes às classes, usandos cartões CRC, deve-se treinar o olhar



Deve-se ter um cuidado especial aodar nomes para as classes. Os nomesdevem ser significativos e bem

específicos, extraídos do contexto doproblema. Uma boa prática é evitar nomes genéricos demais como: sistema,usuário, controlador e operador. Amenos não ser, é claro, que estes nomesenham um significado próprio no

domínio do problema estudado. O nome

da classe e de um objeto criam umvocabulário para se discutir o projeto.Beck e Cunnigham observam que oprojeto de objetos tem mais em comum

com uma linguagem de projeto do quecom a programação procedural. Émperativo que se encontre um conjunto

significativo de palavras para descrever



o objeto, um conjunto que sejaconsistente e representativo do ambientede projeto. (Beck, 89)

Os exemplos abaixo mostram comocriar palavras mais representativasunindo expressões dos diversos

domínios de projeto,

Ambulatório, Enfermaria, ProntuárioMédico PassagemAérea, Balcão,

Bagagem, Avião FichaDePresença,

RelogioDePonto

Nem sempre identificar objetos ésimples e intuitivo. Particularmente em

grandes aplicações classes mais



genéricas podem gerar classes maisespecíficas cuja seleção adequada é umdos segredos do sucesso da boa

modelagem. O uso de técnias como oCRC podem ajudar a testar e revisar diferentes diagramas de classe duranteas fases de projeto. Nenhuma técnica,entretanto, substitui a investigação, asentrevistas e a experiência em campo.



4.3.8. Analisar osresquisitos

Identificado um conjunto de classescandidatas, passa-se a avaliar oscenários descritos nos requisitos. Cadacenário representa umaresponsabilidade que o sistema deveassumir, que devem ser distribuídas

entre as classes, na forma de atributos eoperações. No cumprimento de umafunção uma classe pode chamar outraspara ajudá-la, caracterizando assim um

colaboração entre elas.

A dinâmica desta técnica é a seguinte:escolher um cenário, imaginar e simular



a lógica do processo, distribuir asresponsabilidades determinando ocartão que deve cumprir esta

responsabilidade, atualizar o cartãosempre que necessário, colaborar comoutras classes se for preciso.



4.3.9. Distribuir asresponsabilidade

A responsabilidade de uma classe éuma função que o sistema exige que aclasse cumpra. Tais funções sãodecorrentes dos objetivos listados pelosusuários (atores), nos requisitos domodelo de contexto.A responsabilidade

é algo que uma classe sabe ou faz. O qua classe sabe está expresso nos seusatributos, e o que a classe sabe fazer sãofunções que a classe oferece ao sistema

Responsabilidades expressão açõesque identificam problemas a seremresolvidos. As soluções existirão no



nterior da implementação destas ações.Uma responsabilidade serve para levar à discussão das potenciais soluções.

Quanto mais se puder exprimir comessas frases, mais poderoso e consisoserá o projeto. Aqui também encontrar as palavras certas é um valioso uso deempo no projeto (Beck, 1989). Em

geral, as responsabilidades sãoexpressas por uma série de frases

verbais curtas, cada uma contendo umverbo de ação e algum objeto, comomostam os exemplos abaixo:

Fazer Pedidos Definir o preçoConsultarViagensCalcular salario



Se um requisito pedir por umaresponsabilidade ainda não coberta por nenhuma das classes, pode-se adicionar

a responsabilidade em uma das classesexistentes ou, excepcionalmente, criar uma nova classe para receber estaresponsabilidade. Anota-se aresponsabilidade em uma linha docartão, como já mostrado nas figuras. Onúmero limitado de linhas do cartão é

proposital, porque se uma das classes sorma muito complexa, durante esteprocesso, copia-se a informação destecartão em um outro cartão procurando

meios mais concisos de representar oque o objeto deve fazer. Se ainda assima classe continuar complexa, identifica-se uma nova classe para assumir as



responsabilidades, se não existir pode-se criar uma nova classe.



4.3.10. Caracterizaros colaboradores

Uma classe é incapaz de cumprir sozinha todas as responsabilidades deum sistema. No cumprimento de umaresponsabilidade que lhe foi atribuída,ela pode solicitar a colaboração deoutras classes. Isso quer dizer que em

algum ponto do cumprimento da suafunção, a classe invoca uma outraresponsabilidade da classecolaboradora. Este fato é indicado no

cartão se escrevendo o nome da outraclasse ao lado da responsabilidade.

A existência da colaboração é própria



da natureza dos objetos, e do fato quenenhum objeto é uma ilha isolada, masfaz parte de um sistema. Os objetos se

relacionam uns aos outros e criam asredes de colaboração. Colaboradoressão os objetos para os quais se enviamensagens para satisfazer umadeterminada responsabilidade. Umobjeto pode colaborar com váriosoutros, e não possuir nenhum

colaborador. Assim como alguns objetopodem exigir muitos colaboradores enão colaborar com nenhum outro objeto

Supondo que exista uma classe Pedidoque armazenda os dados de um pedidode compras, em resposta a um requisitodo tipo:



... o preço do pedido deve ser estimado com base na lista de produtos..

Representa-se na modelagem de umcenário foi atribuída a esta classe aresponsabilidade EstimarPreco daclasse pedido, que calcula o preçoestimado do pedido com base no preçode cada produto, individualmente. Para

sso, a classe Pedido pede acolaboração da classe Produto, quepossui a responsabilidadeCalcularPreco, que calcula o preço do

produto com base na quantidade a ser adquirida e no preço unitário, tambémpresente na classe Produto. Estas

relações são representadas nos cartões



CRC como mostra a figura:

Figura 48 - Exemplo de colaboraçãoentre cartões CRC



Ao final da análise dos cenários, tem-

se cartões ricos em responsabilidades ecolaborações. Cada cartão representaum elemento importante do sistema e aunião destes cartões representa,

conceitualmente, o sistema a ser constuído. Pode-se ainda, validar osistema simulando a dinâmica de cada

cenário, para saber se a distribuição defuncionalidades e as colaborações sãoadequadas e suficientes.



4.3.11. Simular adinâmica do cenário

Na simulação do sistema, cadaparticipante da reunião, desenvolvedor ou cliente, assume o papel de algunscartões enquanto se executa o cenário.Semelhantemente a um teatro, osprojetistas assumem o papel das classes

e respondem aos estímulos externoscomo aquela classe responderia.

Uma boa estatégia para dar início à

simulação é arranjar os cartõesadequadamente sobre a mesa. Esta visãoespacial dos cartões é muito valiosa,pois ela ajuda a identificar um projeto



ainda incompleto ou ainda poucoentendido. A relação espacial permitedestacar famílias de classes, e grupos d

classes que devem atuar em conjunto, ouaté mesmo a necessidade de umacolaboração maior entre duas ou maisclasses.

A possibilidade que os cartões CRCoferecem de manipular as classes, antes

abstratas, e agora concretizadas noscartões, é muito importante para oanalista e, especialmente, para osusuários. Pode-se olhar os cartões

envolvidos em um cenário e tentar ver oque eles tem em comum. Pode-se tentar rearranjar estruturas atuais em uma novaestrutura. Os cartões CRC não irão faze



este trabalho para o analista, mas aofocar as classes, usando a linguagem daclasses eles podem ajudar a descobrir o

que é crítico para o sucesso de umsistema orientado a objetos.

Beck e Cunningham (1989) reforçam

ainda a importância em não se criar objetos para atender necessidadesfuturas do sistema, mas somente para

atender as necessidades do presente,expressas nos requisitos dos cenários.sto garante que o projeto contém apena

a quantidade de informação que o

projetista apreendeu, e evita umacomplexidade prematura. Pode-seorganizar o trabalho em equipe paraevitar que isto ocorra. Seleciona-se um



projetista para sugerir novos cenáriosdestinados, especificamente, a localizarfalhas, fraquezas e omissões do sistema

proposto.



4.3.12. Traduzindoos cartões em classes UML

Ao final da aplicação da técnica CRCo analista tem nas mãos um conjunto decartões que representa conceitualmenteo sistema. O destino dos cartõesdepende do método adotado. Dandoseqüência à abordagem de modelagem

proposta aqui, os cartões devem ser raduzidos em classes na notação daUML. O diagrama de classes, ao finaldesta tradução é o modelo conceitual do

sistema. Este processo é uma traduçãoporque apenas a linguagem está sendoalterada, não é acrescida nenhuma novanformação na representação do novo



modelo.

A tradução segue as seguintes regras:

1. Para cada cartão cria-se umaclasse,

2. O nome do cartão é o nomeda classe,

3. As classes podem ter

superclasses que são representadasno modelo.

4. Asresponsabilidades atribuídas acada cartão são traduzidas ematributos ou operações:



a. Asresponsabilidades que estãoassociadas ao armazenamento

de uma informação da classesão traduzidas em atributos, e

b. As

responsabilidades que estãoassociadas a ações que aclasse deve executar para o

sistema, são traduzidas emoperações.

5. Havendo colaborações entre

duas classes é uma indicação que pode haver algum tipo derelacionamento entre as classes. Otipo de relacionamento irá

depender, a critério do projetista,



da forma como serãoimplementadas as colaborações.

·



4.3.13. Vantagens datécnica dos cartões CRC

Uma das maiores vantagens daaplicação da técnica dos cartõesCRC em projetos de software é que comum pequeno investimento emreinamento, tem-se os especilistas deuma área fazendo a análise e

descrevendo o software e usandoefetivamente o paradigma de objetos.Esta descrição não é meramente umrelato mas sim um modelo

conceitual consistente do sistema.

Uns poucos minutos de introdução ésuficiente para preparar a audiência



ara uma apresentação baseada emcartões. Os cartões podem ser feitosantecipadamente ou escritos na hora.

sta última forma permite que acomplexidade do projeto seja reveladaaos poucos. Os cartões estão sendousados como meio para contar ahistória do processamento. Os cartões

ermitem contar esta história sem orecurso da linguagem de programação

sua sintaxe ou idioma.(Beck,89)Resumindo, a técnica dos cartões

CRC:

É um método eficiente paralocalizar objetos,Favorecem ao entendimento do

método orientado a objetos,



É uma ferramenta de análise e projeto usada nas fases iniciais,Que pode ser apresentada a

usuários,Incentiva a integração com osusuários e especialistas na análise,É simples e direta e não assusta osusuáriosÉ barato e portável,Pode ir de mão em mão como um

protótipo eLeva diretamente a um diagramaconceitual de classes.



4.4. Estudo deCaso: Jogo da Forca

Para exemplificar a aplicação daécnica dos cartões CRC desenvolve-se

aqui o modelo conceitual do jogo daforca. Este jogo tem a vantagem se ser bem conhecido por todos, o que permiteque qualquer um possa ser consideradoum especialista do assunto, propor eanalisar as suas funcionalidades.

Segue uma breve descrição de um jogoda forca computadorizado, que servecomo um exemplo do que o analistareceberia como uma primeira tentativa

do cliente em descrever seu negócio:



No jogo da forca em computador, oogador é desafiado a descobrir as letra

que formam uma palavra secreta,

escolhida automaticamente pelocomputador. A cada letra errada,sugerida pelo jogador, ele perde umaparte do corpo: cabeça, tronco emembros, desenhada no boneco naforca. Ao se desenhar todas as partesdeste boneco, o jogador perde o jogo

enforcado. Por outro lado, ao acertar odas as letras e descobrir a palavrasecreta, o jogador vence o jogo. Desejase desenvolver o modelo

conceitual orientado a objetos desteogo para se construir um programa de

computador que seja executado nanternet. A figura abaixo ilustra esta



descrição:

Figura 49 - Esquema típico do jogoda forca.

O desenvolvimento do modelo



conceitual do jogo da forca é divididona fase de brainstorm, na seleção declasses, e distribuição de

responsabilidades entre o conjunto decartões. O modelo conceitual do jogo daforca, representado pelo diagrama declasses, é obtido traduzindo-se oscartões em classes na notação da UML.



4.4.1. Modelo deContexto

O modelo de contexto objetivaorganizar em um modelo a descriçãonformal apresentada anteriormente.este exemplo, apenas o jogador é um

ator, que possui como grande objetivo ode jogar a forca. O jogo da forca é

representado por um sistema, quenterage com este ator, como mostra afigura:



Figura 50 - Representação do sistemade forca com uso de um pacote

Diagrama de Casos de Uso

O modelo de contexto do jogo daforca é representado pelo diagrama de

casos de uso e pela descrição textual decada caso de uso. Para aumentar odetalhamento do modelo, divide-se o

objetio de jogar a forca contra o



computador em dois objetivos nosistema: iniciar um novo jogo e chutar etras para adivinhar a palavra secreta.

Optou-se por representar a lista depalavras como um ator, porque ela podeser considerada como um elementomutável, externo ao sistema. Esta

situação é representada pelo diagrama:



Figura 51 - Diagrama de Casos deUsodo Jogo da Forca

Ator: Jogadorrepresenta os jogadores (usuários) dosistema de jogo da forca.

Ator: Lista de Palavrasrepresenta a lista de palavrasarmazenadas para alimentar o jogo. Éum ator passivo, imutável, que sófornece informações.

Casos de Uso: Novo JogoObjetivo principal

Um novo jogo da forca em



computador,exige que se selecioneuma palavra secreta escolhidaautomaticamente de uma lista de

palavras já existente.Cenário de exceçãoA lista de palavras não existe ou nãopode ser encontrada, impedindo acontinuidade do jogo.

Caso de Uso: Chutar LetrasObjetivo principal:O jogador chuta letras para tentar acertar a palavra secreta.

Cenário alternativo 1A cada letra errada, ele perde umaparte do corpo do boneco. Aocompletar todas as partes do corpo do



boneco o jogador perde.Cenário alternativo 2A cada letra certa a palavra vai se

desenhando na tela. Ao descobrir todas as letras e descobrir a palavrasecreta, o jogador vence o jogo.




O desenvolvimento do modeloconceitual do jogo da forca segue aproposta dos cartões CRC se divide nafase de brainstorm, na seleção declasses, e distribuição deresponsabilidades entre o conjunto de

cartões CRC. Como resultado daaplicação desta técnica, tem-se ummodelo conceitual do jogo,representado pelo diagrama de classes,

que é obtido da tradução dos cartões emclasses representadas pela UML.



Brainstorm

A obtenção de uma listagem dasfuncionalidades previstas para o jogo daforca vem de um estudo das diversasações executadas durante uma partida.

Pode-se considerar que o jogo da forcaé uma disputa entre um jogador e umapalavra selecionada pelo seu oponente,neste caso, o computador. Na lista de

funcionalidades abaixo o computador érepresentado pela classe Forca. Asações que se seguem reproduzem umogo típico, entre a forca e o jogador.

O jogo da forca possui umalista de palavras secretas

armazenda,



O jogador inicia um novo jogo, A forca escolhe uma palavra

da lista, Uma Forca vazia édesenhada, O jogador chuta uma letrada palavra, O jogador deve saber asletras que já foram chutadas

Se a palavra possuir a letraestiver a letra é desenhada, Se a palavra não possuir aletra, uma parte do boneco é

desenhada, Se a letra é a crescentada nalista de letras erradas se nãoestiver na palavra,



Quando a palavra estiver completa o jogador ganhou, Quando o boneco estiver

completo o computador ganhou

Candidatos a classes

Uma leitura atenta das funcionalidadesacima mostra que as ações são

comandadas pelos seguintes elementos:ForcaJogador

PalavraBoneco

E que por isso são candidatos a

classes deste sistema. Estas escolhas se



confirmarão com a distribuição dasresponsabilidades, realizada a seguir.

Distribuição das Responsabildiades

Cria-se um cartão para cada classe epassa-se a analisar as funcionalidadesdentificadas, uma a uma:

O jogo da forca possui umalista de palavras secretasarmazenda,

Esta funcionalidade identifica que oogo da forca possui, internamente, umaista de palavras que usa para desafiar oogador. Escolhe-se a classe Palavra



para ter como responsabilidade guardaresta lista de palavras:

O jogador inicia um novo jogo, A Forca escolhe uma palavrda lista

Uma Forca vazia édesenhada

A responsabilidade de iniciar um novoogo, que é solicitada pelo jogador

humano, é atribuída à Forca, que faz anterface com o usuário e controla o

nício do jogo. Iniciado o jogo, a forcaseleciona, automaticamente, uma palavrda lista, e desenha a forca vazia e onúmero de letras da palavra onde o jogo

será desenvolvido. A palavra é



desenhada com espaços indicando asetras. Para desenhar a palavra e o

boneco a Forca usa métodos

apropriados das classes Palavra eBoneco. Este métodos são dependentesda tecnologia empregada para anterface.

O jogador chuta uma letra da palavra

A classe Forca faz a interface com ousuário recebendo a letra sugerida pelousuário que irá processá-la. A classe

ogador tem a responsabilidade deavaliar a letra chutada e para isso usa aclasse Palavra para ajudá-la, já que só aclasse Palavra conhece os detalhes da



palavra escolhida.

Figura 52 - Exemplo do início dadefinição do cartão Forca

A figura acima mostra o cartão daForca até este momento do estudo. A

seguir dá-se prosseguimento ao



processo de distribuição dasresponsabilidades:

O jogador deve saber asletras que já foram chutadas

A responsabilidade de chutar uma letr

é atribuída ao Jogador, que tambémguarda as letras já chutadas.

Se a palavra possuir a letraestiver a letra é desenhada

Aqui temos duas responsabilidades: a

de verificar se a letra está na palavra e desenhar a letra, que podem ser atribuídas à palavra, já que esta possuiconhecimento das suas próprias letras.



Se a palavra não possuir aletra, uma parte do boneco édesenhada

Nesta responsabilidade vemos quequando a palavra verifica que a letranão está na palavra ela precisa da ajuda

do boneco, porque será desenhada umaparte do boneco. Assim atribui-se umacolaboração do boneco na palavra e a

responsabilidade de desenhar uma partepara o boneco. As partes do bonecodevem ser guardadas na própria classeboneco, que deve sabe qual a parte

Cabeça, tronco ou membros que irádesenhar em seguida)



Se a letra é a crescentada nalista de letras erradas se nãoestiver na palavra

A lista de palavras erradas é mantidapelo Jogador

Quando a palavra estiver completa o jogador ganhouQuando o boneco estiver

completo o computador



ganhou

Aqui vemos que a classe palavra deve

er uma responsabilidade para saber seela está completa, assim como o bonecoque deve saber se ele está completo.Associadas à estas

responsabilidades temos afuncionalidade do jogador em ganhar ouperder, respectivamente. Representam-

se as responsabilidades de ganhar eperder no cartão da classe Jogador, coma ajuda das classes Palavra e Boneco.



4.4.3. Cartões CRC

Abaixo estão os cartões CRCresultantes da distribuição deresponsabilidades. Optou-se por mantero nome das responsabilidades próximo

da descrição da funcionalidadeevantada na fase de brainstorm.

Posteriormente, o nome dasresponsabilidades serão traduzidos emnomes de operações e atributos dasclasses e podem se alterar.



4.4.4. Tradução doCartões em Classes

Para construir o modelo conceitual,utilizando a notação da UML, deve-seraduzir cada cartão em uma classe,

onde o nome do cartão será o nome daclasse. Assim, para o cartão Bonecocria-se a classe Boneco, como mostrado

na figura abaixo. Asresponsabilidades descritas no cartãosão traduzidas em atributos e operação.Observa-se que a responsabilidade que

corresponde a guardar as partes doboneco é um atributo (um dado)armazenado pela classe, assim cria-se oatributo parte na classe Boneco. As



outras duas responsabilidadescorrespondem a ações que a classeboneco tem que executar: Verificar se o

boneco está completo e Desenhar umaparte do boneco. Para estas duasresponsabilidades criam-se asoperações na classe Boneco:bonecoCompleto e desenha,respectivamente. A figura abaixocompara o cartão da classe Boneco com

a classe representada na UML.



Analogamente, são traduzidas asclasses Forca, Jogador e Palavra. Nestasão identificadas as

responsabilidades que se transformamem atributos e as que se tornamoperações. Ao dar os nomes para asoperações e atributos procura-se seguir as restrições das linguagens deprogramação evitando acentuação naspalavras, caracteres especiais e espaço

em branco na formação dos nomes. Aabela que se segue mostra acorrespondência entre aresponsabilidade descrita no cartão e os

atributos e operações nas classes:



O diagrama de classes deve refletir a



comunicação entre os objetos. Deve-seobservar que de posse do diagrama declasses e da especificação das classes,

descrita no verso dos cartões, é possívese construir o sistema. Como este é umsistema simples, o modelo conceitual équase auto-suficiente. No entanto oprogramador deverá ainda tomar umasérie de decisões de projeto na fase demplementação. O programador deve

decidir sobre uma série de objetosauxiliares, em como será implementadaa interface e como serão implementadasas comunicações entre as classes. O

modelo detalhado, estudado no próximocapítulo, será utilizado para definir maiprecisamente os detalhes damplementação dos sistemas. No



capítulo 6 retoma-se o jogo da forca, láse desenvolve o modelo detalhado queconduz à implementação.



Figura 53 – Diagrama de ClassesConceitual do Jogo da Forca



5. O Modelo

Detalhado

Este capítulo descreve técnicas paraconstrução dos modelos orientados aobjetos. Nele são descritos, em

detalhe,os seguintes diagramas daUML: classes, seqüência, colaboraçãoestados, atividades, componentes edistribuição. Estes diagramas sãoapresentados como formas dedescrever os detalhes da estrutura, dadinâmica interna e da construção de

um sistema em componentes de



software.



5.1. Introdução aosmodelos detalhados daUML

O desenvolvimento de sistemas desoftware é apoiado em visões queevoluem com o entendimento doproblema e com a aproximação da fase

de construção. Este capítulo leva omodelo do sistema ao seu nível maisalto de detalhes. Apresenta-se aquicomo criar, a partir do modelo decontexto e do modelo conceitual dasclasses, uma visão mais rica em detalhee integrada do sistema de software com

os diagramas da UML.



A OMG[7]

(2001) define a UML como“Uma linguagem padronizada paraespecificar, visualizar, construir edocumentar todos os artefatos de umsistema de software.” É uma propostapara unificar, em torno de uma notação

padronizada, as diversas representaçõesgráficas dos sistemas de software. Aampla aceitação da UML pelacomunidade de desenvolvedores, e pela

própria indústria de software, é umaprova da sua força e uma avaliação dasua importância.Segue um brevehistórico da evolução da notação, que éútil para compreeender o seu estágioatual de evolução.



5.1.1. Histórico daUML

Atualmente, qualquer projeto desoftware que decida pela orientação aobjetos como paradigma dedesenvolvimento, deverá ser representado pela UML assimencontrará apoio em um grande número

de ferramentas CASE disponíveis nomercado. A adoção de uma notaçãopadronizada permite, entre outrasvantagens, a separação entre a análise, o

design e a construção. O contingente depessoal técnico treinado é cada dia mainumeroso, e a capacidade de seespecificar, detalhar, medir, construir e



gerenciar um projeto de software por meio dos diagramas e modelos da UMLé cada vez maior.

Mas nem sempre foi assim, nos anos80, apesar da tecnologia a orientação aobjetos já ser bem conhecida, uma

diversidade de metodologias e notaçõeprocuravam representar os sistemas desoftware orientados a objetos de

diferentes formas. Ao se iniciar um novoprojeto de software era precisoselecionar um método e, quase semprereinar uma equipe para utilizar aquela

notação e poder desenvolver osmodelos. A falta de um padrão criavaum problema adicional para a difusão decnologia de orientação a objetos.



Dentre as muitas metodologiasexistentes, datacaram-se o OOSE deJacobson (1992), o OMT de

Rumbaugh (1994) e o método deBooch (1994).

Em 1993, Booch já estudava uma

aproximação com o trabalho deRumbaugh e juntos, na empresaRational, iniciam o esforço de

unificação das duas metodologias. Nofinal de 1995, introduziram o conceitodo UM -Unified Method - que se tornouem seguida, após a entrada de

Jacobson na equipe, na UML - Unified odeling Language - com a separação

entre a linguagem de modelagem e oprocesso de desenvolvimento. Os



esforços de Booch, Rumbaugh, eJacobson resultaram, em 1996, naemissão da versão UML 0.9 quando os

autores convidaram a comunidade emgeral para opinar. A lista de tecnologiade objetos patrocinada pela Rational, aOTUG – Object Technology User´sGroup - foi um ambiente de aprendizadocolaborativo e um grande motivador daampla adoção atual da UML. Os

subsídios da discussão pública pelanternet criaram as revisões UML 1.0, ea 1.1 que, finalmente, foi submetida eaprovada pela OMG em 1997. A UML

orna-se assim a linguagem oficial paramodelar sistemas orientados a objetos, epassa a ser gerenciada pela OMG, que ancorporou na sua sistemática de



padronização e revisões.

A UML é essencialmente uma

inguagem de modelagem, definida por uma meta linguagem, isto é, a partir daUML podem ser geradas outrasinguages coerentes com o objetivo

original de descrever um sistemaorientado a objetos. A notação da UMLé padronizada, e deve ser assim para

poder descrever com precisão cadaparte do software, de forma única e deum modo onde qualquer um, queconheça a UML, possa ler o mesmo

software. Por outro lado, o software éuma tecnologia em evolução, umanotação que resistisse à esta evolução,estaria fadada ao insucesso. A



dificuldade em conciliar uma notaçãoprecisa, rigorosa e padronizada comuma notação que possa evoluir com a

ecnologia foram os maiores desafiosenfrentados pela equipe dedesenvolvimento desta linguagem.

A UML é o resultado de um processode convergência dos principais métodospara desenvolvimento de sistemas

orientados a objeto existentes naprimeira metade da década de 90. Cadamétodo deu a sua contribuição para aformação da UML, sendo que o

resultado é mais preciso e maishomogêneo que as linguagens anterioresEla consegue descrever os sistemas deforma mais abrangente, levando a



modelagem mais próxima damplementação. Possui elementos de

expansão que permitem acomodar novo

sistemas, assim como novos elementosna modelagem.

Os objetivos inicias da UML, descrito

pela OMG (2001), são:

Fornecer aosdesenvolvedores umalinguagem de modelagemvisual, pronta para o uso nodesenvolvimento e

comunicação de modelosricos em significados.Oferecer mecanismos deextensibilidade e

especialização para ampliar



os conceitos principais. Dar suporte à especificaçõesde projeto independentes da

linguagens de programação edo processo dedesenvolvimento.

Prover uma base formal parao entendimento de umalinguagem de modelagem

Encorajar o crescimento do

mercado de ferramentas de software orientadas a objeto Dar suporte aos conceitos dedesenvolvimento de alto níve

como componentes,colaboração, frameworks e

padrões. Integrar as boas práticas de



projeto.

A UML especifica uma linguagem de

modelagem que conseguiu o consenso dcomunidade de especialistas emorientação a objetos nos conceitos chavda modelagem. Com a UML se é capaz

de atender os mais variados problemasde modelagem atuais, de uma formadireta e econômica. Alguns problemas

futuros esperados, especialmente osrelacionados com a tecnologia decomponentes, computação distribuída,rameworks e executabilidade já são

abordados pela notação. Com a UML, épossível a troca de modelos entre umavariedade de ferramentas, além dacriação de repositórios para



armazenagem e troca de modelos.

A notação da UML é uma notação

gráfica, onde a descrição de umsoftware é feita com símbolos gráficospadronizados que se relacionamformando diagramas. Cada diagrama

apresenta uma visão parcial do sistemade software, e a união dos diagramasdeve representar um único sistema de

software. Os diagramas são descritospor nomes e termos padronizados, quecompõem um glossário próprio deermos que também faz parte da UML.



5.1.2. Osdiagramas da UML

Os modelos detalhados descrevemmais precisamente os fenômenosobservados no problema, assim comopemitem, encaminhar o sistema à suamplementação em uma linguagem de

programação. Algumas metodologias

preferem distinguir os modelosdesenvolvidos nas diversas fases, comomodelo de análise, modelo de projeto,modelo de implementação e assim por

diante. Aqui eles serão chamadosapenas de modelos detalhados,ndependentemente da sua finalidade.



O diagrama de classes, desenvolvidocomo modelo conceitual do sistema, énsuficiente para descrever todos os

detalhes do projeto. Os cartões CRCmostram que para se ter um sistema émportante definir como as classes irão

colaborar. Entretanto, a colaboração,ainda é pouco explorada neste modelo, precisa ser detalhada para considerar outros fenômenos presentes no sistema,

descrever mais precisamente a troca demensagens entre as classes, assim comopara acrescentar elementos importantesda implementação.

O diagrama de classes traduz umavisão estática, sem movimento,equivalente à uma foto do sistema, e por



sso não permite avaliar caractersísticasdinâmicas do comportamento interno eexterno da classe. Assim, é necessário

desenvolver outras visões da dinâmicado problema, para descrevê-lo comprecisão. As visões dinâmicas eestáticas do problema devem se integrare se complementar, para representar umsistema passível de ser contruído.

O modelo detalhado de objetos,descrito neste capítulo, é formado pelareunião destes diversos diagramas, quepermitem observar o problema sob

ângulos particulares, e que exploramcaracterísticas importantes do problemaestudado. As visões utilizadas nomodelo detalhado de objetos, são



istadas a seguir e podem ser organizadas como mostra a figura:

Figura 54 - Exemplo de navegaçãoentre os diagramas da UML



A visão da estrutura de um modelodetalhado é dado pelo diagrama de

classes. As classes, identificadas nomodelo conceitual, formam a base sobrea qual são erguidos os componentes dosistema. As classes mostram apenas umavisão estática do sistema. A visãodinâmica complementar é oferecida porum conjunto de diagramas de

nteração entre as classes e pelo



diagrama de estados. A interação entreas classes de um sistema é mostradapelos diagramas de seqüência e

diagrama de colaboração, querepresentam as mensagens trocadas entras classes. Os diagramas de estadomostram o ciclo de vida de uma classe,representando a sua dinâmica interna.Para serem construídas, as classespodem ser agrupadas em componentes

de software que são então distribuídospelos servidores. Estas situações sãodescritas pelos diagramas decomponentes e de distribuição.

O modelo de contexto define ocomportamento externo do sistema, queé distribuído, na modelagem conceitual,



para as classes do sistema. Estas classeparticipam de processos que podem ser modelados pelos diagramas de

seqüência, atividades ou decolaboração. Internamente, as classesem seus ciclos de vida modelados pelodiagrama de estados. Assim, ocomportamento interno do sistemamplementado nas classes por suas

operações, forma a base das mensagens

rocadas entre as classes, assim comomplementam as transições de estado emuma classe. A coerência entre as classee suas operações garantem a coerência

do modelo e do sistema como um todo.



Figura 55 - O analista e o modeloconceitual

Nos modelos de contexto e no modeloconceitual o analista se coloca em umaposição de alguma distância comrelação ao sistema, para não perder avisão do todo. Já nos modelos

detalhados, o analista deve se aproxima



muito mais do sistema e das suas partespara ver todos os detalhes. Estesdetalhes são separados em

características estruturais, que sãorepresentadas nos diagramas de classescaracterísticas dinâmicas que podem serepresentadas nos diagramas denteração e de estado, ou características

de implementação que são representadanos diagramas de componentes ou de

distribuição.



5.2. Diagrama declasses

O diagrama de classes, já introduzidono modelo conceitual, deve agora ser

detalhado para poder descrever comprecisão o sistema a ser construído. Ossistemas orientados a objetosorganizam-se ao redor de classes deobjetos, que representam tanto oselementos do domínio do problema,ncorporados ao modelo, como os

elementos propostos para amplementação da solução. O diagramade classes representa a planta baixa dosistema, estabelecendo uma relação

entre os elementos do problema e o



código que os implementa. Paramplementar um diagrama de classes é

necessário que a linguagem de

programação dê pleno suporte àorientação a objetos, como a linguagemde programação Java, que será utilizadacomo exemplo neste estudo.

As classes formam uma unidade queencapsula atributos e operações. Uma

classe define um conceito importantepara o problema e pode se relacionar com as outras. Mas são os objetos,nstâncias das classes, que interagem

nos programas, disparam mensagens,podem até ser transmitidos em umamensagem pela rede ou mesmoarmazendos em bancos de dados. A



dentificação das classes do sistema, suconstituição e relacionamentos é aessência da modelagem orientada a

objetos, e já foi desenvolvida, emgrande parte, com a modelagemconceitual no capítulo anterior. Estecapítulo detalha o diagrama de classes eodos as suas nuanças e o relaciona comos diagramas dinâmicos e demplementação, criando uma visão

detalhada do sistema de software.Uma classe é representada por um

retângulo dividido em 3 partes onde se

representa o nome, seus atributos e suasoperações. Estas partes sãoapresentadas nos terços do retângulocom maior ou menor quantidade de



detalhes, em função do grau deabstração desejado ou da fase dedetalhamento do modelo, como mostram

os exemplos da figura:

Figura 56 - Exemplos derepresentação de classes



5.2.1. Nomes

Dar nomes aos componentes de ummodelo, como já foi dito, é umasatividades mais importantes damodelagem. Em um diagrama de classes

devem ser escolhidos nomes para asclasses, atributos, operações e tambémpara as relações. A escolha de um nomeadequado pode facilitar muito oentendimento do problema, enquantouma escolha incorreta de um nome podeornar o modelo incompreensível. Os

nomes devem ter significado para odomínio do problema em questão,descrevendo elementos importantes dosistema e aproximando o modelo do

problema real.



As classes devem ser nomeadas comexpressões substantivas breves,niciadas por uma letra maiúscula para

que representem um nome próprio dovocabulário do problema em estudo. Onome da classe deve ser único noâmbito do subsistema que a contém. Onome da classe deve ser escolhido demodo a ter um significado relacionadocom a sua responsabilidade do sistema.

Assim, Funcionario, Livro,CartaoDePonto e ProntuarioMedico são

nomes adequados para classes.[8]

Os atributos são nomeados da mesmaforma que as classes. Com a diferençaque os atributos são iniciados por letras

minúsculas e representam propriedades



das classes. São bons nomes para asclasses outros substantivos associadosàs classes, frases adjetivas curtas ou

adjetivos substantivados que podemqualificar as classes, por exemplo: cor,nome, baixo, tamanho, tempoDeEspera,dataDeAniversario, menorIndice emaiorValor.

As operações indicam ações que a

classe pode executar. As operaçõesdevem ser nomeadas com nomesrelativos às responsabilidades que aclasse assume para o sistema. Verbos ou

frases verbais curtas são bons exemplosde operações. As operações assim comoos atributos são iniciadas por letrasminúsculas, como por exemplo:



calcularValor, fazerPedido, vender,nvestir e comprar . Analogamente aos

atributos, a classe ou o objeto que é

criado a partir dela, será o sujeito dasoperações

Com exceção da herança, todos osrelacionamentos entre as classes de umsistema podem ser nomeados. Osdetalhes da representação de cada tipo

de relacionamento são apresentadosuntamente com os adornos disponíveispara um relacionamento.



5.2.2. Visibilidade

Uma das características das classes é capacidade de envolver em uma cápsulaatributos e operações e poder, a seucritério, ocultar estas informações de

outras classes. Para controlar quaisatributos e operações de uma classepodem ser vistos fora dela deve-seestabecer a visibilidade de cada umdestes elementos. No diagrama declasses a visibilidade que pode ser:pública, privada ou protegida, é

ndicada por um símbolo na frente donome do atributo ou da operação, comomostra a tabela.

Como uma boa prática de projeto, uma



classe só deve oferecer ao sistema suasoperações públicas. Assim, oas outrasclasses só podem invocar as mensagens

relacionadas às operações públicas eapenas estas operações podem ser herdadas. As operações privadas e osatributos servem para atender asnecessidades internas da classe, sãovisíveis por toda a classe mas não sãovisíveis externamente.



Esta boa prática de projeto evita queoutras classes tenha acesso direto, edescontrolado, aos valores dos atributo

da classe. Se uma classe ofereceatributos públicos ela permite que seuestado seja alterado sem que ela possaomar uma ação a esse respeito. Dando

acesso aos atributos unicamente por ntermédio de operações de acesso, a

classe pode controlar o que ocorre

quando um atributo seu se modificaalterando, por exemplo, o seu estado.

Para dar acesso aos atributos privados

são criadas as chamadas de operaçõesde acesso. Os nomes destas operaçõesde acesso devem ser padronizados parafacilitar a sua construção por



ferramentas automatizadas, e para dar um acesso padronizado por outrasclasses. A tabela abaixo exemplifica as

operações padrão de acesso em umaclasse de Produto mostrada na figura:

Figura 57 - Exemplo de operações deacesso



A classe Produto, do exemplo, possuios atributos privados: nome do tipoexto (String), qtd do tipo inteiro (int) e

outro chamado disponível do tipoboolean (falso ou verdadeiro). A tabeladescreve algumas operações

Como o atributo disponível é um

atributo booleano usa-se a operação



sDisponível no lugar do getDisponívelcomo forma padronizada de acesso.Supondo que a disponibilidade do

produto depende da quantidade doproduto, podemos definir o valor doatributo se ele está disponível ou nãocom base na quantidade atribuída aoProduto. Assim o pseudocódigo dométodo setQtd pode ser:

metodo setQtd( pQtd:int)qtd <- pQtdse (qtd > 0)entao disponivel <-

verdadeito

senao disponivel <- falsofim do se

fim do setQtd

Assim, se os atributos qdt ou



disponível forem públicos, é possívelmodificar os seus valores direta endependentemente, e ter-se a

quantidade zero (qtd=0) e valor disponível ainda verdadeirodiponivel="true"), criando uma

condição inconsistente para o produto.O parâmetro disponível é alteradoalterando-se a quantidade, por estarazão, não faz sentido ter-se a operação

setDisponivel. Confirma-se assim a boaprática de adotar usar métodos deacesso públicos e atributos privados.Uma exceção a esta regra são as

constantes globais, que por seremconstantes serão lidas e não podem ser modificadas, não necessitando de ummétodo de acesso. Outra operação muito



útil é a operação que gera umaseqüência de caracteres para testar aclasse e apresentado o seu conteúdo

mpresso, por exemplo. Cria-se assim aoperação toString() que retorna um textoque descreve o objeto.



5.2.3.Instanciamento de Classes

em Objetos

Uma classe pode ser instanciada em

um objeto, como mostra a figura. Comos objetos pode-se construir umdiagrama de objetos, relacionando osobjetos como se relacionam as classes

que os formam.



Figura 58 - Exemplo de um objeto

Para instanciar o produto lampada, poexemplo, deve-se criar um objeto combase na classe EquipEletrico, que éraduzido em código por métodos

chamados de construtores:

lampada= new EquipEletrico(110,



5.00)

Neste exemplo, escrito em Java, o

método EquipEletrico(tensao, valor) éum método constutor da classeEquipEletrico, e é um executado emassociação ao comando new para criar

objeto livro com base na classe.



5.2.4. Classesconcretas, abstratas e

interfaces

As classes são instanciadas em

objetos, dos quais se pode invocar asoperações públicas na forma demensagens. No entanto, nem todas asclasses permitem a sua instanciação

direta em objetos, as classes quepermitem a sua instanciação em objetossão chamadas classes concretas. Emmuitos casos, pode ser necessária acriação de classes que apenasdescrevem conceitos abstratos e que nãosão transformados em objetos

diretamente, as chamadas de classes



abstratas. Estas classes devem ser herdadas por outras classes concretas,que irão implementar os conceitos

abstratos criando uma classe concretaque pode ser instanciada.

As classes abstratas são muito úteisnas primeiras etapas da modelagem, nafase da modelagem conceitual e nacriação de famílias de classes

reutilizáveis. As classes abstratas nãopodem ser instanciadas porque alguns dseus métodos são abstratos, isto é, existainda algo na classe abstrata que não fo

definido. Um método abstrato é ummétodo do qual se conhece apenas a suachamada, a sua assinatura, e que aindanão foi construído. Isto é, uma classe



abstrata tem pelo menos um dos métododa classe apenas declarado, e ainda nãoexiste sua implementação concreta para

ele. Nas primeiras fases da modelagemde um sistema é possível que algunsmétodos de uma classe ainda não tenhamsido completamente definidos o que acaracterizaria como abstrata.

A assinatura de uma operação ou

método é o nome da operação e seuconjunto de parâmetros. Um métodoabstrato não possui o corpo do métodoonde se encontra o algoritmo que o

mplementa. Uma classe abstrata podepossuir métodos concretos, mas deve tepelo menos um método abstrato. Parauma classe abstrada se tornar concreta



ela deve ser herdada por outra que irásobrescrever os métodos abstratos commétodos concretos.

A UML representa uma classeabstrata com linhas pontilhadas. Noexemplo a seguir, tem-se a classe

abstrata PessoaJuridica representando oconceito de pessoa jurídica, que émplementado pelas classes concretas

de empresa cliente (EmpresaCliente) ede empresa fornecedoraEmpresaFornecedora). O método

criarEmpresa é um método abstrato de

deve ser implementado pelas classesfilhas para que estas sejam concretas.



Figura 59 - Exemplo de classeabstrata

Um tipo de classe abstrata muito útil

na modelagem é a interface. Umanterface é uma classe formada apenas

por métodos abstratos. Ela serve para se

definir uma forma de comunicação entre



as classes de um modelo, porquedescreve apenas um conjunto demensagens que as classes que a

mplementam devem obedecer. Eladefine um padrão de comunicação, e seposiciona entre classes, por isso échamada de interface.

No exemplo abaixo temos a definiçãode uma Obra em uma biblioteca, que é a

definição abstrata de um conceito queserve para se comunicar com o sistemada biblioteca. A herança de umanterface é chamada de implementação

porque a classe concreta devemmplementar todos os métodos da classe

de interface. Esta herança é representadambém por uma linha pontilhada porqu



não é uma herança verdadeira, uma vezque não há métodos concretos paraserem herdados. A “herança” em uma

nterface é uma implementação. O usode interfaces é bastante difundido nacriação de classes reutilizáveis e nodesenvolvimento de componentes desoftware portáveis.

Figura 60 - Exemplo de Interface emplementação



5.2.5. Adorno dosrelacionamentos

Os relacionamentos podem receber elementos gráficos para descrever, commaior precisão, a ligação existente entreduas classes. A base para orelacionamento entre duas classes é aassociação que representa uma união

conceitual entre as duas classes. Naassociação pode-se incluir uma setapara aumentar a navegabilidade daassociação, um losango para indicar

uma agregação e uma multiplicidade nasextremidades.

Uma seta na associação mostra a



navegação do relacionamento, ou seja, adireção do relacionamento identificandoquem é a classe dependente (origem da

seta) e quem é a classe independenteponta da seta). Um losango em uma da

extremidades da seta transforma umarelação em uma composição, istop é,ransforma a associação em um

relacionamento de agragação todo-parteonde o losando identifica a classe que é

o todo. Uma associação pode ter umnome indicando o tipo derelacionamento que existe entre asclasses. O nome mostra qual é o

conceito que une as classes. Estesadornos podem ser observados noexemplo abaixo, onde uma empresapossui uma série de produtos que são as



suas vendas.

Figura 61 - Exemplo de adornos emrelacionamento

O adorno mais importante em umrelacionamento é a multiplicidade da

relação. Ela descreve quantos objetosparticipam desta relação e é indicadapor um símbolo nas extremidades darelação. O exemplo da figura mostra que

uma empresa realiza vendas de muitos*) produtos, nesta relação a navegaçãondica que é a empresa quem vende os

produtos. A tabela abaixo mostra os



símbolos utilizados na representação.

Em um sistema esta relação vai indicaque cada um dos objetos que foremnstanciados a partir da classe Empresa

poderão ter um vínculo com vários

objetos da classe Produto. O nome destevínculo é vendas. Na fase demplementação este relacionamento

pode, por exemplo, ser traduzido em um

vetor de produtos criado na classe



Empresa. A composição indica ainda aexistência dos produtos destas vendaspartes) está condicionada à existência

da classe Empresa, o todo na relação.

Os vínculos entre as classe formam oscaminhos pelos quais são enviadas as

mensagens que criam a dinâmica de umsistema orientado a objetos. Supondo-se, no exemplo, que os objetos da classe

Produto tenham um método públicogetPreco(), que informa o preço de cadaproduto, é possivel aos objetos daclasse Empresa perguntar o preço de um

produto do vetor de vendas com amensagem:



vendas[i].getPreco();

que informaria o preço do produto dendice i do vetor. A modelagem daroca de mensagens entre os objetos é

modelado pelos diagramas de interaçãoque são estudados a seguir.



5.3. Diagramas deInteração

As mensagens formam a base dadinâmica de um sistema orientado a

objetos. A partir da modelagemconceitual procurou-se identificar erepresentar as responsabilidades dasclasses na forma de mensagens que aclasse seria capaz de responder. Osdiagramas de interação objetivamdescrever, de maneira mais detalhada, a

roca de mensagens que ocorre entre osobjetos de um sistema.

Para poder compreender claramente o

conceito de mensagens é importante



rever alguns termos que serão utilizadosamplamente nesta seção e nas seguintes.Um sistema é constituído por um

conjunto de classes, que dividem entresi uma série de funcionalidadesmplementadas em métodos e atributos.

A integração destas funcionalidadesgarante o cumprimento da totalidade dosobjetivos previstos para o sistemaorientado a objetos que foram

evantados das descrições dos casos deuso no modelo de contexto. No modelode contexto obseva-se também que sãoos atores a real origem das mensagens,

uma vez que as classes respondem aestímulos vindos dos objetivos dosatores. Na modelagem conceitual ficouclaro que uma classe isoalada é incapaz



de atender à totalidade defuncionalidades existentes em um sisteme para isso depende das funcionalidades

das outras classes do sistema. Parautilizar uma funcionalidade do objeto deuma classe envia-se uma mensagem paraele, que é implementada em umaoperação pública do objeto de destino.Assim, a operação de um sistemaorientado a objetos se traduz em uma

ntensa troca de mensagens entre osobjetos, estimulados por eventosexternos vindos dos atores do sistema.

Os objetos que participam da interaçãoformam um contexto, que é a reuniãodos objetos e dos vínculos que unem osparticipantes da interação. A figura, qu



representa uma interação, esquematizaos conceitos de vínculo, mensagem econtexto e suas relações :

Figura 62 - Componentes de uma

nteração

A colaboração entre objetos, paraatingir um determinado objetivo, é

realizada pela requisição de um serviço



que um objeto necessita de outro objetoque está capacitado a prestar esteserviço. Uma mensagem geralmente é

niciada por um ator em um objteo. Esteestímulo pode dar origem à outramensagem, e a esta por sua vez a outra,seqüencialmente, até que o objetivonicial seja cumprido. A modelagem

dinâmica das interações entre as classesé feita na UML por um conjunto de dois

diagramas chamados de diagramas denteração:

Diagramas de Seqüência

Diagrama de Colaboração

O diagrama de seqüência descreve aorganização das mensagens trocadas

entre objetos no tempo em um cenário d



uso do sistema. É sabido que acolaboração entre os objetos se dá entreobjetos que se relacionam, e

principalmente, por meio destesrelacionamentos. O diagrama deseqüência não mostra esterelacionamento. Para descrever a trocade mensagens que ocorre nosrelacionamentos entre os objetos usa-seo diagrama de colaboração. Na

modelagem das interações o olhar domodelador deve estar suficientementedistante das classes para não perceber os detalhes dos objetos, mas próximo o

bastante para perceber as mensagensentre eles. O colaboração e a seqüênciade mensagens representam a mesmanformação sobre o sistema, sendo



possível traçar um diagrama a partir dooutro.



5.3.1. Mensagens

As mensagens são instâncias docomportamento dinâmico externadopelos objetos. Elas surgem, quasenaturalmente, ao se analisar um caso de

uso ou, ao se projetar a distribuição deresponsabilidades de um problema entreos objetos de um sistema. Quando umobjeto, o emissor, envia uma mensagempara outro objeto, o destinatário, eleestá solicitando que o destinatárioexecute uma operação da sua coleção.

Estabelece-se, a priori, que o objetoque recebe a mensagem é capaz deatender esta solicitação, devendopossuir uma operação pública preparad

para isto.



São igualmente consideradas comomensagens os estímulos externosrecebidos pelo sistema. Um usuário, ao

solicitar uma ação de um sistema, nadamais está fazendo do que emitir umamensagem a um objeto deste sistema.Uma mensagem tem a mesma estruturade uma operação e é, essencialmente,uma instância desta operação. Como asoperações, uma mensagem possui um

nome, parâmetros e um valor de retornoO retorno é a resposta da mensagem eestá implícito na maioria das mensagensSe um objeto faz uma pergunta é porque

provavelmente, espera uma resposta. Noentanto, podem existir mensagensassínronas, que não aguardam aresposta, e mensagens como a emissão



de sinais, que não tem um retornomplícito. A tabela mostra os diversosipos de mensagens:



5.3.2. Diagrama deSeqüência

Os diagramas de seqüência descrevemo comportamento dos objetos dosistema, que se relacionam pela troca demensagens em interaçõesseqüencializadas no tempo. Cadadiagrama mostra um cenário, isto é, um

conjunto de mensagens, ordenadas noempo, com um determinado objetivo.Assim, para a elaborar um diagrama deseqüência é importante que os objetivos

do sistema já tenham sido levantadospela modelagem de contexto, e que seencontrem descritos nos cenários doscasos de uso.



Por exemplo, o caso de uso Emitir fatura, abaixo, pode ser um objetivo dogerente de contas de uma empresa, ao

automatizar o seu sistema de vendas:

Figura 63 - Exemplo de um Caso deUso

A descrição do caso de uso Emitir

Fatura, neste sistema poderia ser:

A fatura é emitida com a soma dosreços dos itens do pedido e

endereçada ao cliente.



Na visão de uma troca de mensagensentre os objetos: fatura, pedido, item ecliente, a descrição deste caso de uso

fica:

A pedido do Gerente de Contas, aatura inicia a sua emissãoerguntando ao pedido quais são ostens e segue enviando uma mensagem

aos itens da fatura, perguntando qual o

seu preço unitário, uma informaçãoque é própria de cada item. A seguir, aatura pergunta ao cliente qual o seu

endereço e, finalmente, retorna ao

erente para a aprovação.

Este processo é representado pelodiagrama de seqüência abaixo



Figura 64 - Exemplo de Diagrama de

Seqüência

Enquanto o diagrama de casos de usomostra a visão funcional, o de classesapresenta uma visão estática da estruturdas operações, já o diagrama deseqüência oferece uma visão dinâmica,

onde a presença da variável tempo pode



ser facilmente observada. O tempo corrde cima para baixo no diagrama deseqüência, o que quer dizer que os

eventos inferiores ocorrem após oseventos superiores no diagrama. Asinhas verticais representam os objetos

as horizontais as mensagens trocadasentre eles. O diagrama de seqüência é odiagrama ideal para especificações desistemas de tempo real, pois o tempo

aparece de forma explícita e asmensagens podem ter tempos entervalos bem definidos.

Algumas recomendações são úteis parse elaborar um diagrama de seqüênciamais claro e preciso. É comum, por exemplo, que ao lado das mensagens se



enha uma descrição textual do processocom notas explicativas. É tambémcomum que um ator inicie o diagrama,

porque como o diagrama se propõe adescrever a seqüência de mensagens queva a um objetivo, é de se esperar que

primeira mensagem seja aquela quesolicita este objetivo ao sistema,normalmente, partindo de um ator.

Não é sempre necessário representar no diagrama de seqüência a resposta àsmensagens, porque elas existemmplicitamente. Entretanto, muitas vezes

rata-se de mensagens assíncronas e oretorno só virá após outras mensagenserem sido executadas. Dai, é importantedentificar quando isso ocorre usando,



explicitamente, a mensagem de retorno.As mensagens de retorno sãorepresentadas no diagrama com setas

racejadas, ao contrário das outrasmensagens que são linhas contínuas.

Uma outra caracaterística do diagrama

de seqüência é a capacidade derepresentar a linha da vida dos objetosque mantem o foco da ação a cada

momento. Esta anotação é feita tornandoa linha vertical que representa objetomais espessa, quando este está em focono processamento. O foco ocorre entre o

recebimento de uma mensagem e orespectivo retorno. Fora de foco oobjeto poderia estar fora da memória doprocessador, porque não participa,



naquele momento do processamento.

A figura que se segue mostra um

diagrama com o foco de controle dosobjetos para exemplificar este recurso.O gerente solicita a emissão de umafatura que mantém-se em foco enquanto

solicita aos pedido a lista de Itens epara cada item da lista o seu preco, efinalmente o endereço ao cliente da

fatura. Terminada esta tarefa a faturaretorna ao gerente que a aprova.



Figura 65 - Exemplo do diagrama deseqüência do sistema da loja



5.3.3. Diagrama deColaboração

Analogamente aos diagramas deseqüência, os diagramas de colaboraçãorepresentam as interações entre objetosna forma de troca de mensagens. Adiferença entre os dois diagramas é queo diagrama de seqüência não mostra a

estrutura de vínculos entre os objetosque dão apoio à comunicação, enquantoo diagrama de colaboração mostra osvínculos entre as classes, pelos quais

fluem as mensagens. Outra diferençaestá no fato que no diagrama decolaboração o eixo dos tempos não éapresentado explicitamente. Estas



pequenas diferenças não impedem quese faça uma transformação direta dodiagrama de seqüência no diagrama de

colaboração. A figura abaixo mostra odiagrama de colaboração referente aoprocesso de emissão de fatura, descritono item anterior.

Os nomes das mensagens, assim comono diagrama de seqüência devem ser

bem escolhidos para refletir asoperações presentes na classe dedestino. Uma seta (à) associada àmensagem facilita a leitura e indica a

sua direção. As mensagens, no diagramade colaboração, podem ser numeradas, que dá ao diagrama uma orden naseqüência das mensagens no tempo,



refletindo a ordenação apresentada nodiagrama de seqüência. O diagrama decolaboração pode ser utilizado como

uma opção ao diagrama de seqüência.

Figura 66 - Exemplo de diagrama decolaboração



A existência de um vínculo entre osobjetos do diagrama decolaboração indica uma possibilidade

de um relacionamento, mas,necessariamente, não o representa. Osvínculos servem de meio para que asmensagens fluam e para anavegabilidade no diagrama. Havendoum vínculo as classes podem colaborar,porque há um caminho por onde a

mensagem pode ser enviada.Os vínculoentre os objetos podem ser dos tipos:



Concluindo, os diagramas denteração representam a visão da

dinâmica presente entre as classes de u

sistema. Eles se caracterizam por descrever uma troca intensa demensagens, seqüencializadas no tempo,relativas a um objetivo do sistema.Enquanto no diagrama de seqüência oeixo dos tempos está presente, não estárepresentada a estrutura das classes. Já

no diagrama de colaboração encontra-sea estrutura, mas não se encontra o eixodos tempos. Ao final da elaboração dosdiagramas de interação, tem-se

representada nas mensagens, asoperações necessárias às classes paracumprir todos as responsabilidades dosistema. As operações são descobertas



porque as mensagens são instâncias dasoperações.

Tendo modelado todos os cenáriosprevistos no modelo de contexto paraum sistema, as classes devem ter recebido todos as operações necessária

para responder às mensagens trocadasno desenvolvimento dos cenários. Restaagora verificar se internamente as

classes possuem a dinâmica e coerêncianecessária, papel este desempenhadopelo diagrama de estados.



5.4. Diagrama deEstados

A descrição da dinâmica interna deuma classe é feita pelo diagrama de

estados, ele reflete o ciclo de vida dosobjetos da classe, desde o momento emque este objeto é criado até o seuérmino quando ele não é mais utilizado

pelo sistema, passando por todas assituações em que o objeto poderia seencontrar. Cada classe do sistema é

modelada por uma máquina de estadosfinita, onde o olhar do modelador devese posicionar bem próximo aosmecanismos internos da classe, dentro

até dos limites da própria classe. A



proximidade deve ser o suficiente parapoder observar, isoladamente, cadadetalhe interno dos estados e das suas

ransições.

O diagrama de estados representa adinâmica interna de uma classe como

sendo formada por estados e eventos.Estados caracterizam condições,situações, onde o objeto daquela classe

pode ser encontrado. Eventos são açõeque provocam a mudança nestascondições. O estado é uma atividade daclasse de caráter lento (estado de ação)

e às vezes até estático (estado deespera). Por ter este caráter lento, podeser interrompido por um evento. Oevento, por sua vez, retrata uma



atividade rápida e que não pode ser nterrompida, uma vez iniciado iráevar, necessáriamente, ao novo estado.

Sempre ocorre um evento entre doisestados, assim como um estado possuipelo menos um evento associado.

Figura 67 - Estrutura de umaransição de estados



5.4.1. Evento

Um evento na dinâmica de uma classeestá associado às mensagens que aclasse recebe, e consequentemente, àssuas operações internas. São as

operações das classes que permitem amudança das suas característicasnternas, ou seja, são as operações que

provocam as alterações no estado.

A simbologia adotada pela UML paradar nome a um evento é:

evento[condição]/ação



onde :

A condição de disparo é uma

expressão booleana que quandoverdadeira permite o disparo do eventoA expressão é avaliada apenas naocorrência do evento e permite que um



mesmo evento provoque diferentesmudanças de estado, conforme asdiferentes condições de disparo a ele

associadas. No exemplo que se segueanalisa-se o evento retirarMaterial daclasse itemEstoque, que simula umpossível sistema para controle deestoque de materiais.



Figura 68 - Diagrama de Classes do xemplo

Supondo que o itemEstoque esteja nasua condição de estoqueNormal, isto é,a quantidade de itens (qtd) está acima destoque mínimo (estoqueMinimo), a

ocorrência do evento retirarMaterialpode provocar a mudança para acondição estoque baixo, se qtd, variáve

que controla a quantidade de material,ficar inferior ao estoqueMínimo. Casocontrário o itemEstoque ainda é mantidono estado de estoqueNormal.

Pode-se associar ações com o disparode eventos, estas ações são mensagensenviadas pela classe onde ocorre o

evento para outras classes que irão



provocar novas mudanças de estados.Esta reação em cadeia que ocorre nasclasses é a operação típica de um

sistema orientado a objetos. Noexemplo, na ocorrência da mudança deestado de estoqueNormal para oestoqueBaixo é diparada uma ação, naforma da mensagem emitir para o objetocomprador da classe Compras, passandcomo parâmetro a variável

qtdReposicao, que indica a quantidadeque deve ser reposta sempre que oestoque fica abaixo do mínimo. A figuramostra o diagrama de estado que

descreve estes processos:



Figura 69 - Exemplo de um diagrama

de estado



5.4.2. Estados

Um estado é uma situação em que umobjeto pode se encontrar no decorrer daseu ciclo de vida. Esta situação pode secaracterizada por um conjunto de

valores dos atributos, isto é, analisandoos valores dos atributos deve ser possível dizer qual é o estado da classeExistem diferentes tipos de estado, quepossuem diferentes representaçõessegundo a UML. A tabela abaixo mostraestas representações que são descritas a

seguir:



O estado inicial e estadofinal representam a situação da classeantes do início e após o término do seuciclo de vida. O evento que parte de umestado inicial é um evento de criação

Construtor ) de uma classe, assim como



o evento que leva a um estado final é umevento de extinção da classeDestrutor).

O estado de espera e o estado deação são estados em que a classe podemse encontrar e diferem pela ação que aclasses pode estar executando nesta.

O estado de decisão é um estado que

utilizado para definir uma transição combase em uma condição. A diferençaentre um estado de decisão e umacondição de disparo associada a um

evento é, que no estado de decisão, acondição é avaliada antes da ocorrênciade um evento, e se executa uma transiçãem decorrência apenas desta decisão.



a condição de disparo a condição éavaliada apenas quando da ocorrênciado evento, e apenas condiciona uma

ransição, não provoca a transição.

O estado de sincronismo permite aparalelização ou o sincronismo deeventos. É um estado auxiliar naconstrução de diagramas de estadoporque permite que um mesmo evento

seja paralelizado em outros eventos, qusob novas condições de disparo, podeprovocar outras mudanças de estado eações. De outro lado o estado de

sincronismo pode sincronizar dois oumais eventos. Os eventos chegam aoestado de sincronismo de formaassíncrona, e provocam um outro evento



agora síncrono. No exemplo que sesegue , o eventoSaída só ocorre quandoocorrerem os eventos eventoA e

eventoB:

Figura 70 - Exemplo de estados desincronismo



5.4.3. Superestados

Os superestados representam oagrupamento de estados e eventosassociados a eles. O agrupamento, alémde facilitar o entendimento do diagrama

dentifica grupos de eventos quepossuem um comportamento em comum.Um evento que parte ou age sobre umsuperestado, representa um evento queparte ou chega a cada um dos estados doseu interior em particular.

A integração de superestados, estadosde sicronismo e decisão permite acriação de transições complexas epermite representar um sem número de

máquinas de estado. Um superestado



facilita o entendimento do diagrama deestados porque permite estruturar odiagrama em diagramas menores.

Figura 71 - Exemplo de superestado



5.4.4. Eventos eoperações, estados e

atributos

Enquanto os eventos estão associados

às operações que uma classe podeexecutar, os estados estão associadosaos valores que os atributos assumem.Um estado de uma classe pode ser

preservado, e até armazenado, peladefinição, e armazenamento, dos valoredos atributos, assim como a mudança deum valor em um atributo pode provocar a mudança de um estado da classe.

É comum, em muitos casos, definir um

atributo chamado estado, com a



responsabilidade de indicar o estadoatual da classe. Esta prática deveassegurar, entretanto, que a mudança do

valor deste atributo acompanhafielmente a mudança de estados daclasse. A inobservância desteacompanhamento pode provocar situações incoerente, onde o atributoestado indica um estado e a classe estáefetivamente em outro, com

conseqüências imprevisíveis para aoperação do sistema. Uma outrapossibilidade de implementação é criar uma operação getEstado, que devolve o

estado da classe consultando uma sériede outras operações e atributos.

Os eventos, internamente às classes,



assim como as mensagens, externamenteàs classes, são considerados instânciasdas operações, isto é, uma operação

pode ser utilizada em diversos eventos emensagens, simplesmente alterando osparêmetros ou a condição de disparo.Co já foi visto anteriormente, uma boaprática de projeto é evitar que as classealterem diretamente atributos de outrasclasses. Esta providência evita que a

classe perca o controle do seu estado.Fazendo com que toda mudança deatributo seja feita por uma operação épossível se controlar os estados, as

mensagens que devem ser enviadas e ospróprios atributos.



5.4.5. Diagrama deestado de uma interface

Uma aplicação importante dosdiagramas de estado pode ser encontrada na descrição da operação

das GUI[9]

interfaces gráficas dosprogramas. Uma interface gráfica é, emgeral uma classe da camada de

apresentação do sistema que devereceber os eventos do usuário externo.Em princípio, o usuário é livre paranteragir com a interface acionando

qualquer tipo de evento, a qualquer nstante. Esta liberdade pode, se não for

devidamente controlada, gerar situações

perigosas para a integridade de uma



aplicação. Operações delicadas como ade excluir um dado, criar um registro ouransmitir uma informação, devem ser

cercadas de condições que asrestringam. Criar um diagrama deestados da interface ajuda a definir oseventos e estados possíveis na interfacee limita as condições de risco.

O exemplo que se segue é uma

nterface simples, que permite a ediçãodo campos Parâmetro e Valor. Anterface tem, em resumo dois estados: o

estado onde se edita os campos, e um

estado onde estes campos são gravadosO diagrama de estado da interfacemostra as possíveis transições de estadopresentes nesta interface: a limpeza, a



gravação e a saída da interface. Oseventos gravar, limpar e sair estãoassociados aos botões da interface, e

aos eventos que o usuário provoca aoclicá-los.



Figura 72 - Modelagem dos estados dainterface

(a) exemplo da interface e (b) diagramde estados correspondente



Analisando este diagrama pode-sencorporar restrições como a de impedi

a gravação se os campos não forem

preenchidos, alterando o evento gravar com uma condição de disparo expressapelo pseudocódigo

gravar[(parametro<>nulo) e(valor<>nulo)]

que limita a gravação quando um doscampos estiver nulo.



5.5. Diagrama deAtividades

A dinâmica de um sistema pode ser representada internamente à uma classe

pelo diagrama de estados, eexternamente, entre as classes pelodiagrama de seqüência. A UML ofereceainda, no diagrama de atividades, umaoutra alternativa que combina asmensagens externas e internas àsclasses. O diagrama de atividades

mostra uma seqüência de estados eevento, muito semelhante à de umfluxograma, e se aplica na descrição deum processo que transcende a uma

classe, e envolvendo estados de outras



classes.

O diagrama de atividades é uma

alternativa para representar um processodescrito por um caso de uso. Para isso odiagrama de atividades dispõe dosmesmos elementos dos diagramas de

estado: eventos e estados, mas que nãose restringem a um único objeto.

Como exemplo de uso do diagrama deatividades pode-se desenvolver odiagrama de atividades da operação devendas do sistema da loja, apresentado

no capítulo 2. Neste exemplo o caixadeve entrar com o código do produto , oCGC do cliente e o número de parcelaspara verificar se a venda está aprovada

ou não. O diagrama de atividades abaix



mostra a seqüência de comandos queexecutam estas operações:

Figura 73 - Exemplo de um diagrama



de atividades



5.5.1. Trilhas deResponsabilidades

O diagrama de atividades pode ser organizado para agrupar os estadosrelativos a um objeto em uma mesmavertical. Assim, cria-se para cada objetas chamadas raias de responsabilidadeswimlanes). A idéia é agupar os

estados relativos aos objeto de umaclasse em verticais. Desta forma odiagrama de atividades permite mostrara responsabilidade de objeto e criar um

relação entre o diagrama de atividadescom o diagrama de classes.

É interessante observar que associand



os estados de um objeto em uma verticaos eventos que partem desta verticalpara outra vertica são equivalentes às

mensagens em um diagrama deseqüência.

Em nosso exemplo, pode-se agrupar o

estados mostrados na execução daoperação de verificação de vendas noobjetos do POS, Loja, cliente e produto

Deve-se observar, comparando apróxima figura com a figura anterior,que os estados são os mesmos, mas aorganização permite identificar,

claramente, a responsabilidade de cadaobjeto no processo.



Figura 74 - Exemplo das atiividadescom as trilhas de responsabilidade



5.6. Diagramas deImplementação

Os diagramas demplementação ajudam os analistas no

projeto da implementação do sistema.esta fase são definidos os componente

de software e a sua distribuição entre osprocessadores e servidores. Para aelaboração dos diagramas demplementação, o projetista deve se

posicionar a uma distância tal do

sistema, de modo a deixar de lado osdetalhes construtivos da classes eobservar apenas o conjunto docomponente e os servidores.



Figura 75 - O analista vê asclasses e componentes de longe

A representação da implementação naUML é realizada com dois diagramas:

Diagramas de ComponentesDiagramas de Distribuição

que serão detalhados a seguir.



5.6.1. Diagrama deComponentes

Componentes são unidades quearmazenam software. A idéia é agrupar em uma unidade uma parcela do códigodo software para facilitar a integraçãopara formação do sistema. Oscomponentes podem ser associados aos

arquivos onde os códigos podem residirOs códigos fonte ou códigos executáveipodem ser agrupados em componentes.O critério para criação de um

componente pode ser as necessidades dinguagem de programação, ou o

compilador, mas também pode-se criar componentes de software para atender



os requisitos de distribuição do projetoe de reutilização.

Um dos critérios usado para projetar um componente é otimizar aperformance do sistema . O componentede software é a unidade que é utilizada

para se distribuir o processamento dosistema. O uso de diferentesprocessadores pode aumentar a

performance total, uma vez que épossível utilizar, mais adequadamente, opoder de processamento distribuído emuma rede de computadores. O projeto de

distribuição das classes emcomponentes objetiva transferir para oscomponentes as relações presentes nasclasse de modo a balancear a



comunicação presente nas classes eransferida para os componentes. Um

balanceamento adequado das

comunicações entre os componetespromove o balanceamento dacomunicação entre os processadores narede, e com isso é possível maximizar odesempenho total do sistema.

Outro critério para se projetar os

componentes é a reutilização. Oscomponentes são unidades que podemser armazenadas e reaproveitadas emvários projetos. Este reaproveitamento

pode ser maximizado no projeto decomponentes, isolando os elementos deum componente de modo a que sejamantido o encapsulamento e uma



nterface pública padronizada. Osistema é integrado pela união decomponentes nos processadores.

Um componente é representado, naUML, pelo símbolo apresentado nafigura. A figura representa o

encapulamento pelo retângulo com umanterface pública, identificad pelos

símbolos na borda do retângulo:

Figura 76 - Notação de um

componente



Um componente é formado por umconjunto de classes relacionadas. Antensão é isolar o grupo de classes que

possam ser reutilizadas. Assim, ocomponente se comporta como no casodo encapsulamento de um objeto. Ocomponente depende das classes que oforma. Esta dependência pode ser mostrada em um diagrama. A notaçãondica a composição de um componente

em dependência das classes que ocompõe, como mostra a figura:



Figura 77 - Um componente e asclasses que o compõe

Definidos os componentes, pode-secriar um diagrama decomponentes descrevendo como eles

dependem entre si. A dependência



ambém é a principal relação entre oscomponentes, como mostrado a seguir:

Figura 78 - Exemplo de um Diagramade Componentes

O diagrama de componentes representa configuração do software, isto é, comoas diversas partes do sistema serelaciona. Cada parte, identificada por



um componente, é ligada às demaisformando o sistema. Com o diagrama decomponentes o integrador é capaz de

criar uma versão do sistema desoftware. Para concluir a implementaçãé necessário ainda a distribuição doscomponentes pelos servidores, que é oassunto dos diagramas de distribuição,apresentados a seguir:



5.6.2. Diagramasde Distribuição

Os diagramas de distribuiçãodescrevem a configuração do hardware,e a integração dele com o sofware. Osequipamentos são representados por nósque podem estar associados tanto aosprocessadores como aos servidores

reais ou virtuais disponíveis para aaplicação. Os nós se relacionam entre sformando uma rede de processamento ddados. As ligações entre os nós

representam as associações físicas eógicas existentes entre os equipamentos

e servidores.



A UML representa de um nó é arepresentação de um cubo, quecaracteriza um equipamento

processador, e seu tipo.

Figura 79 - Exemplo da Notação deum nó

Os nós recebem os componentes desoftware, em um diagrama que descrevea configuração do sistema, mostrando adependência do com aos componetes



que a ele são destinados.

Figura 80 - Composição de umservidor com seus componentes

O diagramas de distribuiçãorepresentam a ponte que liga o softwaree o hardware que irá processá-lo.

Assim, deve-se decidir quais os



processadores serão utilizados, e comodistribuir os componentes de softwareentre eles. Os relacionamentos presente

em um diagrama de distribuição formaas redes de processamento de dados.

Figura 81 - Exemplo de um Diagrama



de Distribuição



5.7. Integraçãoentre os Diagramas

Os diagramas da UML não existemsoladamente, eles fornecem visões

complementares de um mesmo sistema epor este motivo devem ser coerentesentre si. Os diagramas dos modelosorientados a objetos são baseados nosmesmos princípios fundamentais, ouseja: classes, heranças, mensagens,estados e eventos. Estes fundamentos

garantem que os diagramas se integremcompletamente, mostrando uma visãoprópria do mesmo sistema.

A base que define a estrutura do



sistema são as classes, que formam abase para todo o modelo. Amplementação do sistema em código

executável, parte da criação das classesA partir delas são criados os objetosque participam dos diagramas deseqüências e colaboração. Os diagramade estado e atividades partem dosestados das mesmas classes, queformam, também, as bases para criar os

componentes nos diagramas demplementação.

Na estrutura das classes são as

mensagens, implementadas nasoperações, que permitem a integraçãoentre as diversas visões dos diagramas.Como as mensagens são baseadas nas



operações das classes, elas permitemque se integre o diagrama de classescom os diagramas de interação. Como

são as operações que controlam osatributos e permitem às classes alterar os seus estados, temos a integração entro diagrama de classes e o diagrama deestados também através das operações.

Para exemplificar a integração que as

mensagens proporcionam entre osdiagramas, apresenta-se a seguir antegração que existe entre os diagramas

de classes e os diagramas de seqüência

e a integração entre o diagrama deestado e as operações de uma classe.



5.7.1. Integraçãoentre os diagramas de

classes e seqüência

Os diagramas de seqüência mostram

uma troca de mensagens entre objetos deuma classe. Cada mensagem se refere aum serviço que a classe do objeto dedestino pode oferecer. Assim, para

poder oferecer este serviço deve existiruma operação na classe do objeto dedestino para implementar estamensagem, como mostra o exemplo dafigura:



Figura 82 - Relação entre mensagense operações nas classes

Na integração entre osdiagramas deve-se garantir que asmensagens presentes nos diagrams deseqüência, correspondam às operações

nas classes de destino. No exemploexiste uma mensagem sendo trocadaentre as classes de origem e destino, oque indica que existe uma operação



correspondente na classe de destino.

Em um processo de desenvolvimento

pode-se detalhar os processos descritosnos casos de uso em diagramas deseqüência. Neste processo a modelagemda interação serve para complementar a

distribuição de responsabilidade entreas classes, porque toda vez que sedetermina uma mensagem para uma

classe, se está distribuindo as operaçõepelas classes. A criação dos diagramasde seqüência serve para povoar asclasses do sistema de operações.



5.7.2. Integraçãoentre os diagramas de

classes e estados

O diagrama de estados representa a

dinâmica interna de uma classe. Eleexpõe como a classe reage aos estímuloexternos que recebe. Estes estímulos,eventos no diagramas de estados, devem

ser operações internas da classe que sãoacionadas pelas classes externas. Podemser operações públicas ou privadas. Asoperações públicas permitem queeventos externos estimulem as classes.As operações privadas podem ser utilizadas para implementar eventos

nternos, estados de ação, condições e



outras situções onde é necessário ocultado mundo exterior uma operação. Oexemplo do item de estoque,

apresentado no item 5.4.1, é um bomexemplo desta integração.



6. Estudo de

Casos Este capítulo reapresenta os

exemplos desenvolvidos nos capítulosanteriores aplicando, de modo prático,os conceitos da modelagem orientada aobjetos. Objetiva-se a revisão dos

diagramas e modelos propostosaplicados em exemplos simples que sãoevados à implementação em protótipo

executáveis.



6.1. Introdução

Este livro propõe um conjunto demodelos que descrevem sistemasorientados a objeto. Em conjunto com antrodução de cada modelo foram

apresentados diversos estudos de casosque serviram de exemplo para aaplicação prática das técnicas e das

notações propostas no texto. Estecapítulo retoma cada um destesexemplos, apresentando os modelosdetalhados que levam estes exemplos à

sua implementação na linguagem Java dprogramação. As implementações desteexemplos foram desenvolvidas com umafinalidade didática e não o



desenvolvimento comercial dossistemas, ou mesmo resolver ntegralmente os problemas propostos.

Para tornar os sistemas mais simples,não se pretende apresentar a integraçãocom bancos de dados, nem interfacesgráficas sofisticadas que seriamexigências naturais em sistemas desteipo.

Os sistemas desenvolvidos são:

Os diagramas da UML apresentadosneste livro foram obtidos com a ajuda d

uma ferramenta CASE, e os códigos dos



programas foram escritos na linguagemJava com uma IDE apropriada. Osexemplos desenvolvidos para este livro

encontram-se disponíveis para seremexecutados on-line, pela internet comodescreve o apêndice, onde também seencontram os códigos destas aplicações



6.1.1. Estrutura decamadas dos sistema

Os sistemas computacionais podem sedivididos em 3 camadas: apresentação,negócio e persistência. Em geral, amodelagem conceitual indica a vocaçãoda classe. Usando a notação da UML ,podemos organizar as camadas em

pacotes de classes:



Figura 83 - Estrutura de camadas deum sistema,

(a) notação da UML para ascamadas de um sistema

A implementação de um modeloorientados a objetos depende de umaestratégia para definir as camadas deapresentação e camada de persistência.

A camada de negócios está, em geral,descrita pelo modelo. Mas as camadasde apresentação e de persistênciaprecisam ser projetadas. A UML pode



ser utilzada para definir algunselementos presentes na interface, comoos exemplos desenvolvidos aqui

puderam mostrar. Entretanto, a UMLsozinha não é suficiente para modelar um sistema completamente, outrosdiagramas podem ser utilizados paradescrever as interfaces e o modelo dedados (Ambler, 2001).



6.2. Estudo de Caso:Sistema de Vendas deLoja

Os capítulos 2 e 3 apresentam oexemplo de um sistema de apoio àsvendas de uma loja. Este sistemanforma ao caixa se um produto pode se

vendido à crédito para um cliente, emfunção do preço do produto e do créditodo cliente, obedecendo as regras denegócio da loja. Este exemplo hipotéticoé usado para mostrar os fundamentos daorientação a objetos, como acomunicação entre classes por meio de

roca de mensagens e o polimorfismo.



o capítulo 2 são desenvolvidas asregras de negócio e modelado o sistemasem o formalismo da UML, que é

ntroduzido no capítulo 3 juntamentecom o diagrama de casos de uso e omodelo de contexto. Neste capítulo sãoapresentados os modelos conceitual edetalhado da implementação destesistema.




O modelo conceitual do sistema devendas da loja resulta da análise doscasos de uso e dos processos alidescritos. Desta análise identificam-seos principais personagens do sistema,mostrados na figura abaixo, que é uma

representação formal das classes e dosseus relacionamentos:

As classes identificadas no sistema de

vendas da loja são:

que representa a interface



POS entre o usuário (Caixa) e osistema, é tipicamente umaclasse de apresentação

Produtorepresentam os produtos

comercializados pela loja,uma classe de negócio

Cliente representam os clientescadastrados pela loja, umaclasse de negócio

Lojarepresenta a loja, com um

lista de produtos e clientes,uma classe de negocio



BDLoja

auxilia loja para armazenara lista de clientes e produtos, exemplo de umaclasse de persistência.

No POS o caixa pode se comunicar

com a loja que identifica para o caixa oProduto que o cliente deseja comprar.Com base no preço do produto e nocrédito do cliente, o sistema pode

autorizar a venda parcelada. A lojapossui as informações de crédito e dopreço armazenadas em um banco de

dados, representado pela classe



BDLoja, que é acionada pela LOJA aoser criada construindo a lista deprodutos (listaP) e a lista de clientes

listaC).



Figura 84 - Modelo conceitual do



sistema da loja



6.2.2. ModeloDetalhado

O modelo detalhado do sistema devendas da loja é conseguido pela análisdetalhada da dinâmica dos processosque estão envolvidos nas vendas. Aanálise se realiza com os diagramas denteração, que permitem distribuir, ou

verificar a distribuição, dasfuncionalidades do sistema pelasclasses. Terminada a modelagem, asclasses possuem todas as operações

necessárias para atender os objetivos dosistema.



Diagramas de Interação

A partir do modelo conceitual épossível simular os processosdinâmicos envolvidos no sistema, paradistribuir as operações pelas classes. O

diagrama de seqüência descreve a sériede mensagens que são trocadas entre osobjetos do sistema em um determinadocenário. Seguem-se os cenários de

nicialização da Loja e de autorizaçãodas vendas.:



Figura 85 - Seqüência de autorizaçãode vendas da loja

O cenário de inicialização da Loja édescrito no diagrama de seqüência dafigura acima. Nele, a classe POS,representando o caixa da loja, cria uma



nstância da Loja, buscando na classeBDLoja, que representa o banco dedados as informações da loja para criar

a lista de clientes e a lista de produtos.Estas listas são criadas a partir dosdados de clientes e produtosarmazenados na classe BDLoja, e dasrespostas aos métodos getListaC egetListaP desta mesma classe. Ao finaldeste cenário, a loja está pronta para

niciar as operações de vendasolicitadas pela rede de POS.

O cenário mais importante no sistema

da loja é o cenário de vendas, queenvolve os casos de uso: Identificar Cliente, Identificar Produto e Autorizar o Parcelamento. Estes casos de uso



podem ser representados por um únicodiagrama de seqüência que mostra aautorização do parcelamento de uma

venda. Nele, o caixa solicita à Loja,pelo POS, os dados do cliente,nformando o número do seu CGC. Aoja busca este nome na lista de clientes

e retorna ao POS. De posse do cliente, oPOS recupera o nome do cliente e exibena interface. O POS solicita agora os

dados do produto para a loja, com baseno código deste produto, por meio damensagem getProduto(codigo) emitidado POS para aLoja. A loja busca na list

de clientes e retorna ao POS, querecupera a descrição do produto.dentificado o cliente e o produto, o

POS informa o número de parcelas



desejadas e pergunta para o produto se avenda está aprovada. O Produto faz asconsiderações com base nas regras de

negócio da loja, envolvendo o créditodo cliente e o preço do produto, paraaprovar, ou não, a venda.



Figura 86 - Diagrama de Seqüênciada autorização da venda

Diagrama de Classes Detalhado

O diagrama de classes, no modelodetalhado, integra os diagramas denteração dos processos e serve de base

para a construção do software. As

classes podem ser traduzidas,diretamente no código correspondente,adotando uma linguagem deprogramação orientada a objetos. A

montagem do diagrama de classes, alémda distribuição das funcionalidades,estabelece o relacionamento existente

entre as classes. O relacionamento



segue, aproximadamente, o que foiproposto pelo modelo conceitual, mascom alterações que permitam a

mplementação.

Neste ponto do detalhamento sãonseridas operações de acesso para

odos os atributos privados da classe.Usando-se o prefixo get seguido donome do atributo para as operações de

recuperação dos dados , e o prefixo setpara as operações de atribuição.

A Loja é composta de uma lista de

objetos da classe Cliente chamadaistaC e de uma lista de objetos daclasse produto chamada listaP. Tambémcompõe a classe Loja a classe BDLoja

que é uma classe auxiliar, criada para



recuperar os dados destas listasarquivados de um modo persistente, acada execução do sistema. A Loja, como

mostra a figura, usa uma composiçãopara representar a associação com asistas e com a classe auxiliar, para

representar uma forte dependência entreestas classes.

Analisando as regras do negócio

estabelecidas pela Loja no caso de usodentificar Cliente, criou-se uma novaclasse chamada ClienteVIP. Nodiagrama de classes esta relação é

representada por uma herança da classeClienteVIP da classe mãe Cliente. Aclasse filha possui uma condição decrédito diferenciada, implementada na



operação getCredito, que retorna odobro do crédito atribuído para estaclasse. A operação getCredito da classe

Cliente é sobreposta pela classeClienteVIP em um exemplo depolimorfismo.

Figura 87 - Diagrama de classes de



negócio do sistema

Projeto da Interface

As classes de negócio são projetadaspela análise do processo de negócio, eos diagramas da UML servem bem paraeste fim. No entanto, as classes deapresentação necessitam de um projeto

diferenciado. Neste tipo de classe acaracterística mais importante é manter o controle do processo de comunicaçãoentre o usuário e o sistema. A classe de

apresentação deve apresentar asnformações que o usuário precisa e os

meios para ele agir sobre o sistema. No

exemplo da loja, o usuário precisa



nformar o código do produto e o CGCdo cliente para recuperar da loja ocadastro do produto e do cliente. Para

conseguir a aprovação da venda, depoisde identificado o produto e o cliente, ousuário precisa informar o número deparcelas.

A interface, descrita a seguir,apresenta os campos de texto para a

entrada do código, do CGC e do númerode parcelas e os botões (PRODUTO,CLIENTE e PARCELAS) para que ousuário possa acionar o sistema e

processar os dados de entrada. Para queo usuário verifique que a operação foium sucesso, ele dispõe de campos desaída com a descrição do produto, nome



do cliente e, finalmente, se a venda foiaprovada ou não.

Figura 88 - Interface POS do sistemade vendas da loja

Adicionalmente, foi inserido um boãoLimpar para limpar os campos de dadosde entrada e facilitar uma nova entrada.



Figura 89 - Diagrama de Estado da

nterface POS Uma forma de modelar o controle da

comunicação é representar os possíveis

eventos que ocorrem na interface namáquina de estado de um diagrama deeventos. Cada estado do diagramarepresenta uma situação em qua a classe

se encontra, e cada evento representa



uma ação, promovida pelo usuário, paramudar o estado. A figura do diagrama destado da interface POS mostra que ela

é criada em um estado de espera dosdados permanente. O usuário poderealizar 3 eventos neste estado,correspondente aos 3 botões disponíveina interface. Cada botão depende queuma informação seja fornecida, paraprovocar a mudança de estado, que

passa para um estado de ação onde aclasse de negócio é chamada e voltapara o estado de espera.

Comparando-se o diagrama deestados acima, como a interfaceproposta é possível analisar se anterface serve bem à finalidade



desejada de acionar o sistema, aomesmo tempo que se analisa as suaprecisão por meio do diagrama.

Figura 90 - Diagrama de classes



detalhado do sistema da loja

A interface POS pode ser incluída no

modelo de classes, agregando à ela,além da classe Loja, um objeto da classProduto: oProduto e um objeto da classeCliente: oCliente que representam,

respectivamente, o produto e o clientepresentes na transação de venda. Antegração da classe POS com as classe

de negócio permite a criação de umdiagrama de classe completo do sistemarepresentado na figura.

Expansão do sistema

Para demonstrar a vantagens de



manutenção e expansão dos sistemasorientados a objeto, pode-se propor umaexpansão no sistema da loja,

mplantando uma nova regra de negócioao sistema. Pode-se partir de umanecessidade do departamento demarketing desta loja, que decidiucolocar um produto em oferta. A regrapara esta situação é a seguinte:

Colocar um produto, da lista derodutos da loja, em oferta quer dizer que ele pode ser vendido em até 3

arcela fixas, independentemente do

crédito do seu comprador.

Analisando o modelo de objeto dosistema, observa-se que esta regra irá

mplicar que a verificação da



aprovação do parcelamento da vendaserá diferente se o produto for umproduto normal ou for uma oferta. Assim

pode-se criar uma nova classe deprodutos, que herda as características dclasse produto e é chamada de Oferta,como mostra o diagrama



Figura 91 - Detalhe do diagrama daclasse Oferta

Na classe Oferta a aprovação da vendé reformulada para acomodar esta novaregra. Na classe Oferta também são



criadas uma operação construtor Oferta() e uma operação de saídaoString() reformulada.

A nova operação de aprovaçãosAprovado() possui os mesmos

parâmetros de entrada da operação

anterior, de modo que ela substituintegralmente a operação anterior

quando a classe é uma Oferta. Assim,

quando se chama a operação deaprovação em um objeto da classeOferta a sua forma alterada é acionada.

A nova operação, descrita a seguir,mostra que caso o número de parcelasde venda (n) for maior do que 3, em umproduto em oferta, a regra que está

valendo é a de um produto comum e



para isso se aciona o métodosuper.isAprovado da classemãe (super). No caso de um produto em

oferta, se com um número de parcelasn) for menor ou igual a 3, a operação

aprova a venda. Assim a nova operaçãode aprovação de venda, escrita nainguagem Java, fica:

public boolean isAprovado(intn, Cliente c){

int preco =super.getPreco();

int divida = preco -(preco/n);

if (n<=3) {return (true);} else {

return(super.isAprovado(n,c));

}



}

Para testar esta nova regra do sistema,vamos colocar o produto 104 em oferta:

104 Piano de Cauda R$ 5.000,00

Isto é feito alterando a criação deste

produto na classe de acesso ao banco dedados: BDLoja, como a Oferta á tambéum Produto, devido à herança, ela podeser armazenada na lista de Produtos



listaP), pelo comando:

listaP[4] = new Oferta(104,"Pianode Cauda",5000);

se o produto não esivesse em oferta, ocliente de código 5000, que possui umcrédito de R$ 300,00 não poderiaadquirí-lo em 3 parcelas, porque o saldda compra certamente seria superior aoseu crédito:

5000 Miles Davis R$ 300,00



Mas com a oferta o sistema de vendas

autoriza o parcelamento, como mostra anterface com o exemplo desta operação

Figura 92 - Exemplo da interface dosistema com venda de oferta



6.3. Estudo de Caso:Jogo da Forca

Este sistema descreve uma aplicaçãocompleta, com uma interface gráfica,

apoiada nas classes de negóciodentificadas na modelagem conceitual

desenvolvida no item 4.4. Utiliza-se estexemplo para demonstrar a importânciada separação das camadas de negócio,de apresentação e da camada depersistência em um projeto de software

e as possibilidades da modelagemnestes casos. O sistema é detalhado emduas implementações, umamplementação básica, onde é gerada

uma aplicação local para testes das



classes de negócio, e umamplementação “web” onde a aplicação

é expandida para operar no ambiente da

nternet .

No exemplo desenvolvido no capítulo4, foram identificadas as classes de

negócio:



6.3.1. ModeloDetalhado da

Implementação Básica

Para detalhar a implementação básica

do jogo da forca, a qual será usada paraestar as classes de negócio antes de semplementar o jogo em rede, é

necessário fazer o design da interface

desta implementação com o usuário. Namplementação básica do jogo da forca

não se utiliza recursos gráficos. Oboneco é representado por uma figurasimples desenhada com caracteres emuma matriz de 3 x 3 como mostra oesquema abaixo:



Também nesta implementação, as

etras da palavra secreta que ainda nãoforam identificadas são marcadas comraços do tipo : “_”. Por exemplo, se a

palavra secreta escolhida foi namorado

e já foram arriscadas as letras “a”,”m” “r”, a palavra descoberta fica sendoapresentada ao jogador como : _ a m _ a _ _ , onde as letras ainda nãodescobertas são substituídas pelo traço.

Diagramas de Seqüência



Os diagramas de seqüência são úteisna definição detalhada das classes e nadefinição de como se realiza a

comunicação entre elas. Tomando oscasos de uso: Novo Jogo e Chutar Letrapode-se analisar a seqüência de eventosque é executada nos cenários principaisdestes casos de uso, identificando asoperações necessárias para se completacada processo, e que deve estar

presentes nas classes.



Figura 93 - Diagrama de Seqüênciado caso de uso: Novo Jogo

A cada vez que o usuário solicita àForca que crie um novo jogo, elaconstrói uma instância das classesPalavra e Boneco para iniciar o jogo.

As operações Jogador(), Palavra() eBoneco() são os chamados métodoscontrutores, que instanciam as classes n

criação dos objetos. Solicita então que aclasse Palavra escolha uma palavrasecreta, que ela vai buscar na lista depalavras. A Forca então cria uma

nstância do Jogador e prepara anterface do jogo, desenhando o boneco

e a palavra secreta com traços, para oogador tentar descobrir as letras.



Figura 94 - Diagrama de Seqüênciado Caso de Uso: Chutar Letras

O usuário do jogo sugere uma letra queé capturada pela Forca e passada para aclasse Jogador, por meio da mensagem

chutaLetra() enviada pela Forca. O



ogador então acrescenta a letra na listade letras já chutadasaddLetrasChutadas). O Jogador,

pergunta para a classe Palavra se a letraestá na palavra (letraNaPalavra). APalavra é incumbida de verificar de aetra está na palavra e, se estiver,

acrescenta a letra nas posições corretasda palavra secreta. Caso a letra nãoesteja na palavra, a classe Palavra

solicita ao objeto boneco que acrescentmais uma parte ao desenho (addParte). Émportante verificar, ao se construir um

diagrama de seqüência que todas as

mensagens trocadas entre as classesenham uma operação correspondente na

o objeto de destino.



A Forca ao final de cada letrachutada, deve desenhar as letraschutadas (getLetrasChutadas) a palavra

palavra.desenha) e o bonecoboneco.desenha), para apresentar ao

usuário que irá continuar o jogo. Antesporém, a Forca pergunta para o jogador se ele perdeu, e o jogador pergunta paraa palavra se ela está completaisCompleta). Neste momento, a Forca

pergunta para o jogador se ele ganhou, eele pergunta para a palavra se ela estácompleta (isCompleta), finalizando oprocesso, que é repetido a cada letra

chutada.

Diagrama de Classes Detalhado



O jogo da forca pode ser consideradoum pacote, onde se encontram as classesde negócio, e que é utilizada pelo

usuário externo para jogar com ocomputador. Este sistema é representadopela figura abaixo:

Figura 95 - Representação do jogocomo um sistema

Os diagramas de seqüência ajudam a



completar o diagrama de classes com asoperações e as suas assinaturas,garantindo que as classes tenham todas

as operações necessárias para executar os processos do sistema, definidos noscenários dos casos de uso. O resultado,na implementação básica do Jogo daForca é mostrado no diagrama declasses detalhado a seguir.

O diagrama de classes detalhado servepara iniciar o desenvolvimento dosistema, porque cada classe seráraduzida em um programa Java. Deve-

se detalhar cada operação e atributodefinindo o seu tipo, valor inicial, tipode retorno e parâmetros dos atributos.

Deve haver uma relação biunívoca



entre o código e o diagrama. Isto quer dizer que o diagrama e o código, nonível das definições das classes, se

equivalem. Chama-se de engenharia deprodução a geração de código, eminguagem de programação, a partir do

diagrama. Chama-se de engenhariareversa a produção do diagrama a partirdo código em linguagem deprogramação. Estas conversões são

facilitadas pelo uso de uma ferramentaCASE para automação do projeto desoftware.



Figura 96 - Diagrama de classes damplementação Básica

Código Java da classe Boneco



Para exemplificar a equivalência entreo código e o modelo, pode-se analisar ocódigo de uma das classes do diagrama

de classes. Este é o código, nainguagem Java, que é equivalente à

classe Boneco:

public class Boneco

{

private int parte = 0;

private char[][] Dforca;

private void limpaForca () {



}

public void addParte () {

}

public String desenha () {

}

public boolean isCompleto () {

}

public Boneco () {

}

}



A modelagem dinâmica ajuda oprojetista a definir como devem ser construídos os métodos, e a detalhar a

roca de mensagem entre as classes. Osdiagramas de estado exibem as relaçõesentre as mensagens que a classe recebe emite, e os seus processos internos.Mostra-se o ciclo de vida das classes dsistema, que se integram para formar ociclo de vida do sistema como um todo.

Diagramas de Estado do Jogador

O jogador possui 3 estados bemdefinidos: ChutandoLetras, Ganhou ouPerdeu. O jogador é criado no estado

ChutandoLetras. O evento que altera os



estados é o evento chutaLetra, querecebe uma letra entrada pelo usuáriopara teste. Quando ocorre o evento

chutaLetra, o jogador continua no estadoChutandoletras, mas manda umamensagem para ele mesmo adicionar esta letra na lista de letrass chutadasaddLetraChutada). Se a palavra estive

completa o jogador ganhou, se o bonecoestiver completo ele perdeu, estas

situações são estados verificados comos métodos ganhar() e perder(),respectivamente;



Figura 97 - Diagrama de estados daclasse Jogador

Ao enviar a a mensagem perguntandose a letra está na palavra, o jogador fazcom que a palavra tome uma decisão: sea letraNaPalavra for verdadeira elansere a letra na palavra secreta. Se aetraNaPalavra for falsa ele manda o

boneco acrescentar uma parte.



possível se detalhar um estado, ematividades ainda mais internas. Por exemplo, o estado de chutandoLetras é

um estado de ação e pode ser expandidoem um outro diagrama de estados, comomostra a figura que se segue:

Figura 98 - Diagrama do superestado

Chutando Letras



Neste diagrama observa-se que aentrada do evento chutaLetra aciona aação interna de adicionar letras na

operação addLetrasChutadas e com basna definição se a letra está na palavra,obtida pela mensagem letraNaPalavraenviada para a classe palavra, toma-se adecisão de adicionar uma parte aoboneco, enviando a mensagem addParteao boneco, ou não. Terminadas estas

ações internas, a classe Jogador permanece esperando um novo eventochutaLetra, e pode enviar os sinais deganhar ou perder. Este diagrama de

estado é equivalente ao código javareproduzido a seguir:



public char chutaLetra (char letra,

Palavra palavra,

Boneco boneco){

addLetrasChutadas(letra);

if (!palavra.letraNaPalavra(letra))

boneco.addParte();

}

return(letra);

}

Diagrama de Estado da classe



Boneco

A classe Boneco possui 3 estados bemdefinidos: um estado inicial, onde nadado boneco foi desenhado na forca, umestado onde as partes do boneco estão

sendo desenhadas uma a uma, efinalmente outro estado, quando oboneco está completo, e o Jogador perdeu o jogo. O atributo que controla

este estado é o número de partes doBoneco que já foram desenhadas,representado pela variável parte. Oevento que coloca o Boneco no estadonicial é o evento de construir o objeto

ou o evento limpaForca. A troca deestados é feita pelo método addParte,

que adiciona uma parte do boneco cada



vez que é acionada. Estando o Bonecocom mais de 6 partes ele é consideradocompleto, o diagrama abaixo mostra

estas transições em um diagrama deestado:



Figura 99 - Diagrama de estados daclasse Boneco.

Detalhamento da classe Forca

A classe forca implementa o métodoprincipal (main) acionado quando daexecução do programa. Ao ser nicializada a Forca ela envia uma

mensagem para a classe palavraescolher uma palavra secreta. A partir dai, entra em um ciclo que terminaquando o jogador ganhar ou perder. A

cada volta do ciclo executa o desenhodo boneco e da palavra secreta,mostrando ao jogador o que já foi

descoberto, assim como as letras que já



foram testadas. Cada letra chutada épassada para a classe Jogador que iráprocessá-la, verificando se o jogador

ganhou ou perdeu, retornando ao iníciodo ciclo. Este processo pode ser representado pelo diagrama deatividades que se segue:



Figura 100 - Diagramas de atividadedo programa Forca



o extrato de programa Java abaixoapresenta uma possível tradução destediagrama, onde se utiliza a classe

JOptionPane do pacote javax.swing parmplementar a interface com o usuário,

que é toda na forma de um texto.

public static void main(String arg[]){

char letra;

String tela="";

palavra.escolheSecreta();

do {



//

// constroi o desenho da forca e da

palava

tela = boneco.desenha()+"n"

+palavra.desenha()+"n"

+jogador.getLetrasChutadas()

//

// captura uma letra entrada pelousuario

letra=JOptionPane.showInputDialog(tela).to

0];



//

// Envia mensagem ao jogador para

entrar com letra no jogo

jogador.chutaLetra(letra, palavra,boneco);

}while(!jogador.ganhar(palavra)||jogador.perde

if (jogador.ganhar(palavra))

{tela = tela + "n Parabens!ganhou!"; };

if (jogador.perder(boneco))



{tela = tela + "n Que pena,perdeu!";};

JOptionPane.showMessageDialog(null,t

"Jogo da

Forca",JOptionPane.INFORMATION_

System.exit(0);

}

Executando-se o comando paraexecutar o sistema:



C:Java Forca

Obtém-se uma interface para o jogo,

com um pedido para chutar uma letra, demodo semelhante à interface mostradana figura:



Figura 101 - Interface para jogar aorca



6.3.2. ModeloDetalhado da

Implementação WEB

Os modelos orientados a objeto tem

como uma das grandes vantagens acaracterísticas de reusabilidade e afacilidade de expansão e manutenção.Este exemplo demonstra a reusabilidade

do código orientado a objeto, criandouma versão para a internet do jogo daforca reaproveitando grande parte docódigo da versão básica. A nova versãoweb do jogo inclui duas novidades:

1. Um interface gráfica baseada na

ecnologia de Java Applet, e



2. Uma classe que permite ler asistas de palavra pela internet .

Estas modificações servem paraavaliar a facilidade em se dar manutenção em sistemas desenvolvidossob a orientação a objetos, e a grande

reutilização resultante doencapsulamento das classes. O novosistema chama-se de forcaWEBDB,

como mostra o diagrama abaixo, onde sobserva a dependência de um sistema eoutro.



Figura 102 - Diagrama do sistemaorcaWEBDB e suas dependências

Para criar uma versão gráfica da forca

é necessário criar uma nova classeForca, agora chamada deForcaWEBDB, que implementa umApplet para ser processada pelanternet .

Implementar um acesso remoto à



lista de palavras

A primeira modificação namplementação básica para levar o jogo

para a internet é alterar a classePalavra. Optou-se por criar uma nova

classe, chamada de PalavraDB paramplementar a camada depersistência da classe Palavra, onde osufixo DB lembra DataBase. Como foi

visto é comum isolar em camadas asfunções de persistência, que são maissujeitas a alterações.

A idéia é re-escrever o método daclasse Palavra que faz acesso à lista depalavras. O método que escolhe a

palavra secreta lê a lista de palavras de



um arquivo texto e seleciona,aleatoriamente, uma palavra. Esta leituré feita pela classe PalavraDB que

recebe como parâmetro de entrada oendereço de localização do arquivo nanternet . Este endereço é parâmetro de

entrada da Applet, o que permite que oogo possa receber diferentes listas de

palavras, implementando diferentesníveis de dificuldade, ou jogos

emáticos como palavras ligadas aanimais, países, plantas, etc...

O diagrama abaixo mostra a

dependência que foi então criada entre aclasse Palavra e a classe PalavraDB,mplementada na operação

escolheSecreta().



Figura 103 - Exemplo demplementação da camada deersistência



Criar uma interface gráfica

O que muda na classe que representa oboneco na implementação básica, para oboneco da implementação para interneté apenas a sua aprentação gráfica, as

propriedades de gerenciar o número departes desenhadas, e verificar se estácompleto deve ser o mesmo. Todocódigo desenvolvido para a

mplementação básica deve ser reutilizado na nova implementação.



Figura 104 - Criação de uma classe

de Boneco para web

Assim, para reutilizar o códigoexistente pode-se utilizar da capacitade



de herança das classes e criar uma novaclasse, chamada de BonecoWeb, que éfilha da classe Boneco. Esta nova classe

á substituir a classe boneco namplementação da forcaWEBDB,

sobrescrevendo o método desenha() quedesenha o boneco na forca.

Exemplo da interface resultante

A nova implementação da classe Forcutiliza as mesmas classes Jogador eBoneco da implementação anterior,

acrescida das classes BonecoWEB ePalavraDB, com uma pequena alteraçãona classe Palavra. O resultado final é

um novo diagrama de classes,



esquematizado a seguir, que implementao novo Jogo da Forca com uma novanterface.

Nesta nova implementação as classeForcaWEBDB e BonecoWEB formam acamada de apresentação, a camada de

negócios continua formada pelas classeJogador, Palavra e Boneco, e a camadade persistência é implementada pela

classe PalavraDB:



Figura 105 – Classes damplementação web e divisão de

camadas Nesta nova implementação é possível

se representar com um diagrama de

componentes a versão final do jogo, que



para ser jogado na internet requer queum servidor receba uma página noformato html (index.html) com o código

da Applet (ForcaWEBDB.class) e que éransferida para o processador docliente pela internet . Os componentesque implementam o jogo sãorepresentados no diagrama abaixo:



Figura 106 - Diagrama decomponentes do jogo da forca



No diagrama de componentes estãorelacionados os arquivos que fazemparte do jogo e suas dependências. Os

arquivos possuem extensões quecaracterizam os tipos de componentes.

este diagrama identificamos a páginahtml, as classes java e o arquivo textoda lista de palavras.

Estes componentes são recebidos por

um servidor web (webserver ) quepermite que clientes remotos, munidosde um navegador (browser ) possamexecutá-los e jogar a forca. Esta

distribuição de componentes é mostradano diagrama de distribuição abaixo:



Figura 107 - Diagrama dedistribuição do jogo da forca

O servidor web, em nosso caso, foimplementado no endereço do em um

website que se encontra descrito noapêndice. Neste endereço tem-se acess



à página index.html que implementa, anterface abaixo:

Figura 108 - Exemplo de interface

ara o Jogo da Forca na web



6.4. Estudo de Caso:Modelo de um item deestoque

No item 5.4 foi apresentado umexemplo de aplicação do diagrama deestado na gestão de um item de estoque.Este exemplo é desenvolvido aqui nos

seus modelos de contexto, conceitual edetalhado, para também exemplificar uma aplicação da modelagem orientadaa objetos.



6.4.1. Modelo deContexto

O sistema em estudo representa umsistema de controle de estoque, comumem almoxerifados de empresas de médioe grande porte. Tais sistemas controlama quantidade de material em estoquecom base nos parâmetros de uso e

reposição destes materiais. O número dalgoritmos e de técnicas para segerenciar estoque é grande e não fazparte do escopo deste trabalho analisá-

os. Como exemplo, toma-se uma regrasimples, que é descrita em um modelode objetos e implementada um umprogama de computador, no sistema



temDeEstoque.



Figura 109 - Sistema ItemDeEstoquee Diagrama de Casos de Uso

O diagrama descreve as funções doAlmoxerife, responsável pelo

gerenciamento dos itens de estoque e decompras responsável pela aquisição dotens no mercado, para repor o estoque.

Resumidamente, temos os casos de uso:Retrira Itens do Estoque e Repoe Itensdo Estoque, considerados em nossoexemplo como objetivos do ator

Almorexife no sistema detemDeEstoque.:

Retira Itens do Estoque



O Almoxerife atende requisições deretirada de material do estoque. Se aretirada deixar o estoque abaixo do

estoque mínimo, o almoxerife cancela apróximas retiradas e envia umamensagem para o setor de compras pararepor o material. Após a reposição domaterial, as retiradas podem ser realizadas novamente.

Repõe Itens do Estoque

O Almorexerife recebe o material do

setor de compras e aumenta a quantidadde itens no estoque. Toda a reposição éfeita na quantidade de reposição, que é

definida para cada item.




Conceitualmente, existem 3 classesmportantes neste sistema:

O diagrama de classes a seguir,representa conceitualmente o sistematemDeEstoque proposto. Nele a classe

temEstoque possui os seguintes



atributos e operações:



Figura 110 - Diagrama de classes do

modelo conceitual



6.4.3. ModeloDetalhado

Para levar este modelo conceitual auma implementação deve-se detalhar osprocessos internos da classetemEstoque e os eventos de retirar e

repor material. Para isso lança-se mãodo diagrama de estados desta classe.

A classe itemEstoque possui doisestados claramente definidos, um estadode estoque normal e outro estado quando

o estoque está baixo. O estado édefinido comparando a quantidadearmazenada com um valor do estoquemínimo. Se a quantidade for menor que



o estoque mínimo o estoque está baixo.Estuda-se agora o que os eventos deretirarMaterial e reporMaterial

produzem quando a classe está em cadaum destes estados.

Figura 111 - Diagrams de estados daclasse itemEstoque



A mudança do estoque normal para oestoque baixo ocorre quando há umevento de retirada do estoque e a

quantidade final é inferior ao estoquemínimo, neste caso, o comprador deveser acionado para comprar o item. Nãosão autorizadas retiradas quando oestoque está baixo, e uma mensagem éenviada ao comprador. A reposição domaterial coloca o estoque novamente em

uma condição normal. É importanteobservar que a quantidade de reposiçãodeve ser superior ao estoque mínimo,para garantir que a reposição irá sempre

voltar o estoque ao normal.

Analisando diagrama acima é possívelescrever um código para os eventos



retirarMaterial e reporMaterial. Cadaevento será uma operação na classetemEstoque, e será capaz de atender as

diferentes mudanças de estado que cadaevento produz no diagrama. Os eventosproduzem diferentes mudanças de estadoem função do estado original e dascondições de disparo, que serão ascondicionantes (if) no código daoperação.

No exemplo, existem 3 eventosenvolvidos com a retirada de materialque podem ser transcritos no código,

como mostra a operação retirarMaterialda classe ItemEstoque, reproduzidaabaixo. A operação isBaixo()caracateriza o estado da classe quando o



evento ocorre, e divide o processamentoem dois eventos: um quando o estado ébaixo (isbaixo==true) e outro quando

não está baixo o estoque. No caso doestoque não ser baixo há ainda duasopções, que são observadas no diagramcomo condições de disparo ereproduzidas no código: se a quantidadeexistente é maior que a quantidaderetirada (qtd>n) e se após a retirada o

estoque ficou baixoqtd<estoqueMinimo):

public boolean retirarMaterial(int n)

{



boolean ok="false;"

if (isBaixo())

{

comprador.setMensagens("EstoqueBaixo");

} else

{

if (qtd>=n) {

qtd = qtd - n;

ok = true;



}

if (qtd<estoqueMinimo) {

comprador.comprar(this);

}

}

return(ok);

}

de modo análogo pode-se traduzir oevento reporMaterial, que só éprocessado quando o estado original for



de estoque baixo, caso contrário retornafalso na operação reporMaterial:

public boolean reporMaterial (int n)

{

boolean ok = false;

if (isBaixo())

{

qtd = qtd + getQtdReposicao();

comprador.setMensagens("material



reposto");

ok = true;

}

return(ok);

}

Estas operações resumem o ciclo devida da classe ItemEstoque, quenecessita ainda das operações deacesso para proteger os atributos. Oresultado final está na classe mostradaabaixo, que pode ser utilizada em

aplicações típicas de gerenciamento de



estoques:

Figura 112 - Diagrama de classes do

sistema itemDeEstoque

Para verificar a operação correta destaestrutura foi desenvolvido uma



aplicação que executa o“gerenciamento” de um item de estoquepara teste. A classe Almoxerife, que é o

cliente da classe ItemEstoque, émplementada com um interface que

permite:

Retirar uma quantidade dematerial (botão: Retirar)Repor o estoque do item

(botão: Repor)Acompanhar a situação daquantidade e do estado doitem. (Área de texto e

mensagens)Verificar as mensagens de

são enviadas para o setor decompras. (Caixa de texto com



a mensagem do comprador)

A figura abaixo mostra esta interface,

que está genrenciando um item com osseguintes atributos:

codigo = 101010

descrição = Tonner de copiadora

qtd = 100

estoqueMínimo = 50

qtdReposicao = 70



Figura 113 - Interface de teste dotemDeEsqtoque

Ao se retirar uma quantidade maior 55) que leva ao estoque mínimo temos

que o estoque passa a ser baixo e o

comprador recebe a mensagem de



comprar uma quantidade de 70 pararepor o estoque, como mostra a figura.

Figura 114 - Exemplo dacomunicação ItemEstoque/Compras

Pressionando-se o botão re repor o



estoque é acrescido de 70 unidades e senormaliza.



7. Conclusões

O livro desenvolve técnicas para

representar problemas de software por ntermédio de modelos orientados aobjeto, seguindo a notação da UML. Aabordadem proposta permite um

aumento gradual no nível de detalhes darepresentação. Este aumento é causa econseqüência do entendimento doproblema que aumenta com a análise econstrução do software. O objetivo finado modelo de software é a apreensão dacomplexidade do problema para que

seja possível a construção de uma



solução. Este caminho vai depender deuma representação completa, precisa,coerente e com um nível de detalhes

suficientemente grande, que possibilite asua tradução em códigos, a seremntegrados nos sistemas de software.

Nos capítulos anteriores foiaprosentada a modelagem orientada aobjetos em 3 tipos de modelos: o

modelo de contexto, o modeloconceitual e o modelo detalhado. Cadamodelo possui uma escala e um ponto dvista próprio, e se utiliza de um conjunto

de técnicas e de diagramas da UML parrepresentá-lo. A tabela abaixo resumeesta combinação:



O desenvolvimento do trabalho mostra

que não apenas as classes sãomportantes em um sistema orientado aobjetos, e destaca o importante papeldesempenhado pelas mensagens para

descrever a dinâmica do sistema. Demodo muito parecido com uma conversaentre as classes, o processamento de umsistema orientado a objetos é um



suceder de eventos organizados paraatender os objetivos do sistema.

O leitor não encontrará claramente noivro a organização de um método paradesenvolvimento de software, porquenão é esta a sua finalidade. Mas há sim,

na forma de apresentação dos assuntos,um caminho natural que pode ser seguido para o entendimento de um

problema, e que pode ser percorridopelo analista como um método. Osmelhores exemplos deste caminhonatural são os estudos de caso, que se

utilizam da mesma seqüência de passospara desenvolver um sistema.

Cada problema exigirá, no entanto,

mais de um modelo do que de outro. A



finalidade para qual se está modelandocondiciona a importância que se devedar aos modelos. Um analista de

negócio, por exemplo, que estáenvolvido nas primeiras etapas daconcepção de um sistema, irá dedicar mais tempo aos modelos de contexto, ealvez um pouco menos ao modelo

conceitual e não produzirá nenhummodelo detalhado. O engenheiro de

software que procura garantir umaperformance adequada para um sistema,rá se dedidar, exclusivamente, aos

modelos detalhados e aos diagramas de

mplementação. O programador responsável pelos códigos poderáreceber um modelo de contexto e ummodelo conceitual já prontos e deverá,



por sua vez, produzir muitos modelosdetalhados para poder criar oscomponentes do sistema.

As técnicas de modelagem orientada aobjetos não terminam aqui. É umadisciplina viva da engenharia de

software e passa, constantemente, por atualizações, correções e extensões paradiversas áreas de aplicação. A OMG é

foro adequado para propor mudanças ediscutir as evoluções da UML.Recomenda-se a visita freqüente no seuwebsite para se manter atualizado com a

UML

Apenas a atualização teórica não ébastante, a prática da modelagem é

necessária para a apreensão dos



conceitos. Assim como ao aprender umaíngua estrangeira é preciso falar, ao

aprender uma linguagem de modelagem

é preciso modelar. Somente a práticapode dar ao modelista ahabilidade necessária para obter aqualidade e precisão na representação.

este trabalho ao apresentar cadamodelo pode-se observar como épossível aplicar os recursos de

representação em exemplos práticos,irados de casos simples, propostos eestudados ao longo de todo texto. Cabeagora ao leitor, aceitar o desafio de

aplicar estas técnicas, e os diagramas daUML, para representar os seus própriossistemas de software, e comprovar asqualidades da modelagem orientada a



objetos.



7.1. ReferênciasBibliograficas

AMBLER, SCOTT; CRC Modeling:Bridging the Communication Gap

Between Developers and Users.ovember 29, 1998.

AMBLER, SCOTT; Be RealisticAbout the UML. 2001./ da internet /

Beck, K. e; Cunningham, W. A

aboratory for teaching object-orientedhinking. OOPSLA´89 ConferenceProceedings, 1989.

Beck, Kent Extreme Programming



explained: embrace change. AddisonWesley Longman, 1999.

Bellin, D.; Simone, S. The CRC CardBook. Addison-Wesley Pub Co; ISBN:0201895358; Series on Object-OrientedSoftware Engineering. 1997.

BERARD, E. V. Be Careful with “UseCases”, 1996. /da internet :http://www.toa.com/pub/use_cases.htm

BOOCH, G. Object-Oriented Analysisand Design with Application.

Benjamin/Cummings, 1994.ECK, DAVID. The Most Complex

Machine: A Survey of Computers and

Computing. A K Peters Ltd; ISBN:

http://www.toa.com/pub/use_cases.htm



1568810547; 1995.

FOWLER, M.; SCOTT, K.

UML Destiled. Object TechnologySeries. Addison-Wesley, ISBN0201325632; 1997

HARMON, P.; WATSON, M.Understanding UML The Developer'sGuide. San Francisco, MorganKaufmann, 1997.

JACOBSON, I.; RUMBAUGH, J.;BOOCH, G; The Unified Modeling

Language Users Guide. Addison-WesleyPub Co; . Object Technology Series;SBN: 0201571684; 1998.

JACOBSON, IVAR et al. Object-



Oriented Software Engineering: A UseCase Driven Approach. Addison-Wesley Pub Co; ISBN: 0201544350;

1992

Larman, Craig. Applying UML andpatterns: an introdution to object-

oriented analysis and design. PrenticeHall PTR, 1997.

OMG, Ed. OMG Unified ModelingLanguage Specification. Version1.4,September, Object Management Group.2001./ da internet em

http://www.omg.org/

ORFALI, R.; HARKEY, D.Client/Server Programming with

Java and CORBA. 2nd Ed. John Wiley



& Sons Ed. 1998.

PARNAS, D.L.; On the Criteria to be

used in decomposing System intoModules. Communications of the ACM,Vol.5, No.12, December 1972, pp 10531058

Pfleeger, Shari Lawrence. AlbertEinstein and Empirical SoftwareEngineering. IEEE Computer. V.32 n.10Oct. 1999

PRESSMAN, R. S. Engenharia de

Software. 3a Ed. São Paulo: Makron.1995.

Probasco, Leslee. Dear Dr. Use Case:

What About "Shall" Wording in a Use



Case?. Rational Software Canada, 2001da internet :

http://www.therationaledge.com /

RUMBAUGH, et al. Modelagem eProjetos Baseados em Objetos. Rio deJaneiro: Campus, 1994.

SEBESTA, ROBERT W. Concepts of Programming Languages. 3rd ed. NewYork: Addison-Wesley, 1996.

Wilkinson, Nancy. Using CRC Cards.SIGS Books & Multimedia, ISBN:

0133746798, 1995.Wirfs-Brock, Rebecca. Designing

Object-Oriented Software Prentice Hall

PTR; ISBN: 0136298257; 1991.

http://www.therationaledge.com/



7.2. Endereços daInternet

Seguem-se alguns endereços nanternet onde se pode encontrar

nformações sobre orientação a objetos:

www.omg.org

website da Object Managment Groupentidade que reúne empresas enteressados na normatização da

ecnologia e das aplicações orientadas aobjeto. Lá se encontra a documentaçãooficial da UML em www.omg.org/uml/as últimas versões, o estado das

discussões das novas versões,

http://www.omg.org/

http://www.omg.org/uml/

http://www.omg.org/



referências, e outras normas comoCORBA e XML.

www.cetus-links.org

website que organiza até a data queescrevia este, mais de 18000 links para

websites sobre orientação a objetos. Éuma referência obrigatória na busca dequalquer assunto ligados à tecnologia deobjetos, UML, componentes, engenhariade software e seus mais diversospadrões e tópicos relacionados. Owebsite é bem cuidado e os links são

freqüentemente atualizados. Emwww.cetus-inks.org/oo_ooa_ood_tools.html pode

ser encontrada uma lista das ferramenta

CASE disponíveis, com vários

http://www.cetus-links.org/oo_ooa_ood_tools.html

http://www.cetus-links.org/



programas em demonstração que podemser copiados para avaliação.

www.c2.com

website da empresa de WardCunningham onde se pode encontrar

alguns artigos importantes sobreObjetos, inclusive o artigo original dentrodução aos cartões CRC.

Curiosamente, pode-se encontrar emhttp://c2.com/doc/crc/draw.html amagem dos primeiros cartões que

Cunningham e Beck utilizaram para

apresentar a sua técnica.

www.mundooo.com.br

website brasileiro com um portal bem

http://www.mundooo.com.br/

http://c2.com/doc/crc/draw.html

http://www.c2.com/



atualizado e organizado sobreorientação a objetos, possui diversosartigos e notícias de diversas origens,

organizadas por assunto. Possui um bommaterial também sobre Java. Dispõe deum fórum muito útil para discussão deassuntos relacionados a objetos, e queraduz bem a simplicidade e praticidade

da técnica.

www.od.com.br website de um dos mais importantes

eventos sobre orientação a objetos que

ocorre no Brasil. Trata do estado da artda tecnologia e de importantesaplicações das técnicas em empresasnacionais.

http://www.od.com.br/



www.objetos6000.com.br

website de outro importante evento

patrocinado pela SUCESU-SPwww.sucesusp.com.br ) e que reúne 3ecnologias ligadas à orientação a

objetos: UML, CORBA e Java.

www.rational.com

website da empresa Rational, ondeoriginalmente foi criada a UML e hoje éuma empresa que desenvolve soluçõespara apoio ao desenvolvimento de

software usando extensamente a UML,como na ferramenta CASE RationalRose.

www.microgold.com

http://www.microgold.com/

http://www.rational.com/

http://www.sucesusp.com.br/

http://www.objetos6000.com.br/



website da empresa Microgold queproduz o software deCASE WithCLASS que utilizei para

produzir os modelos apresentados nesteivro.

www.uml.com.br ou

www.umlbrasil.com.br

um dos portais nacionais sobre aUML com link para outros portais,artigos, tutoriais e outras informaçõessobre UML e orientação a objetos.

http://java.sun.com .website oficial da linguagem Java, no

domínio da empresa Sun, onde todas as

nformações sobre a linguagem, os

http://java.sun.com/

http://www.umlbrasil.com.br/

http://www.uml.com.br/



compliladores e máquina virtual podemser encontrados. Pode-se encontrar ambém tutoriais e exemplos de sistema

desenvolvidos nesta linguagem.

www.voxxel.com.br/deboni

Meu website pessoal que mantenhodentro do portal da empresa VoxxelConsultoria de Sistemas. Nele mantenhoalguns artigos sobre o UML, Objetos,Java, novidades e materialcomplementar a este livro.

http://www.voxxel.com.br/deboni



Glossário

A

Abstração

(abstraction) Ascaracterísticas essenuma entidade que a

distinguem de outra eUma abstração definlimites da entidade rà perspectiva do esp

(action) Uma mensag

enviada quando da



Ação ocorrência do evento permite a integraçãodiagrama de estado e

diagramas de interaç

Adorno

(adornment ) Elemen

gráficos que aumenta precisão da descriçãdiagrama.

Agregação

(aggregation) Formespecial de associaçespecifica uma relaçtodo-parte entre o ag(todo) e seus compon(parte).



Análise

(analisys) fase dodesenvolvimento do onde se identifica os

objetivos e se procurentender o problemaresolvido.

Analista de

sistemas

( system analiyst ) profissional respons

realizar a análise desistema.

Arquitetura

(architecture) organ proposta para resolv problema, inclui a

configuração de soft



hardware, e como elorganizam.

Assinatura

( signature) conjuntocomposto do nome, ode retorno e dos parâ

da operação de uma não inclui a suaimplementação.

Associação

(association) tipo derelacionamento entre

onde há um certo nívenvolvimento entre eclasse se mantémindependente, mas gu

algum tipo de signifi



ligação.

Ator

(actor ) representa oselementos externos asistema, que interageele Como um usuário

desempenha um papesistema, estando forasistema, e não podem

alterados pelo desendo sistema.

Atributo

(atribute) parte da eque permite o armazde informação em umclasse, possui um tip

nome.



B

Booleano

(boolean) Tipo deenumeração que assu

valores de falso ouverdadeiro.

Brainstorm

(brainstorm) estratéutilizada para levantrequisitos de um proj

uma reunião de traba

C



Camada

(layer ) conjunto de cque compartilham o

nível de abstração oufinalidade, um layer representado por um

Cardinalidade(cardinality) númeroelementos de um con

Cartões CRC

(CRC cards) Técnic proposta por Beck e

Cunnigham (1989), qutiliza cartões de paprepresentar as classeorganizar um trabalh



equipe que identificadescreve conceitualclasses de um sistem

CASE

Engenharia deSoftware Apoiada poComputador, do inglComputer-Aided Sof

Engineering . Corres programas de compu

que dão suporte às ade engenharia desoftware, principalmatividades de model

(Use Case) seqüêncitransações ocorridas



Caso de Uso sistema, que refletemde importância paraque se comunica com

Cenário

( scenary) instância dcaso de uso, pode se

otimista, alternativoexceção.

Ciclo de

desenvolvimento

(development cicle)atividades que gera usoftware a partir dosrequisitos de um pro

Possui 4 atividades principais: análise, dconstrução de compointegração.



Ciclo de teste

(test cicle) série deatividades que verifisoftware fornecido pde desenvolvimento acordo com os requi

projeto.

Ciclo de vida

(life cicle) série de

atividades entre a crdestruição de uma clsoftware ou de outrocomponente de um si

ou até mesmo do prósistema.



Classe

(class) molde para ade objetos, identificaconjunto de objetos q

compartilha a mesmaestrutura de dados emesmas operações. É para a contrução de usoftware orientado a

Classe abstrata

(abstract class) apen

descreve conceitos ae que não serãotransformados em obdiretamente. Uma clabstrata possui pelouma operação abstradefinida apenas pela

assinatura.



Classe concreta.

(concrete class) clas

permite a sua instancem objetos, não possnenhuma operação ab

Classificação

(classification) procidentificação das claum sistema em uma

hierarquia de tipos.

Cliente

(client ) 1.contratantedesenvolvimento dosoftware, interessadoresultado que o softw

dar ao seu negócio. 2



ou componente de soque solicita um servioutra classe ou comp

Código(code) programa decomputador escrito e

linguagem de progra

Códigoexecutável

(executable code) pr

de computador em lide máquina, executávum processador.

( source code) progracomputador em uma

linguagem de progra



Código fonte de alto nível, passívcompreendida por u programador.

Colaboração

(collaboration) conjinteração entre class

cumprir um objetivosistema.

Comentário (comment ) Ver nota

Componentes

(component ) unidadarmazenam software permitem a manipulaarquivamento, distrib

instalação deste soft



Devem possuir uma bem-definida.

Comportamento

(behavior ) Os efeitoobserváveis de uma ou evento, as operaç

públicas expostas poclasse ou component

Composição

(composition)relacionamento entrecom uma forte propr

de posse, o todo é fo pelas partes que depexistencialmente do



Condição dedisparo

( guard condition)expressão lógica avaquando da ocorrênci

evento e que condiciexecução do evento.

Construção

(contruction) fase dodesenvolvimento ondcomponentes são cri(programados, codif partir dos modelos .

Contexto(context ) conjunto deelementos relacionadinteragem para cumpobjetivo do sistema.



CRC

Classe, ReponsabilidColaboração, do ingClass Responsability

Colaboration

D

Delegação

(delegation) A habilum objeto em compauma responsabilidadoutro objeto, por me

duplicação desta opeentre eles. A delegaçser usada como umaalternativa à herança



Dependência

(dependency) relacioexistente entre classe

alguma forma não esespecificada pela relforma frace derelacionamento.

Design

(design) fase do

desenvolvimento ondelaborar uma estratéresolver o problemade design são tomad

decisões ligadas à sodo problema.



Diagrama

(diagram) representgráfica de uma coleçelementos relacionad

diagramas de classesdiagrama de objetosdiagrama de casos ddiagrama de seqüêncdiagrama decolaboração, diagraestados, diagrama de

atividades, diagramacomponente, e diagradistribuição.

Diagrama de

objetos

(object diagram) reúobjetos e as suas relum instante no tempodiagrama de objeto p



considerado um casoespecial de um diagrclasses..

Diagrama deCasos de Uso

(use case diagram) dum modelo funcional

nível do sistema deinfomações em projeIdentifica os usuáriorepresenta o sistema

a sua visão.

Diagrama deAtividades

(activity diagram)

representação gráficdiferentes estados e que estão associados

cenário. Representa



mensagens entre claseventos intraclasse.

Diagrama de

Classes

(class diagram) moscoleção estática de edo modelo seus cont

relações. Forma a baa tradução em códigocriando uma estruturorientar a construção

Diagrama deColaboração

(colaboration diagrmostra as interaçõesobjetos organizadas objetos e seus vínculAssemelha-se em co

ao diagrama de seqü



Diagrama de

Componentes

(component diagram

a organização e asdependências entre ocomponentes de soft

Diagrama de

Distribuição

(deployment diagramostra a configuraçãtempo de processam

nós de processamentcomponentes, procesobjetos que existem

Diagrama de

( state diagram) mosciclo de vida de uma

na forma de uma troc



Estados estados provocada peventos internos.

Diagrama deSeqüência

( sequence diagram)uma série de mensagobjetos organizadas

seqüencialmente no tDiagramas de seqüêndiagramas de colaboexpressam informaçã

semelhante.

Disparo ( fire) Causa uma tranestado.

(domain) Uma área d



Domínioconhecimento ou ativcaracterizada por umconjunto de conceito

terminologias aceitaespecialistas naquela

E

Elemento

(element ) um compo

um diagrama ou mod

Encapsulamento

(encapsulation) confundamental dos objeassociado ao fato quobjeto deve possuir

dados e as funções



necessárias para suaexistência independe

Engenharia desoftware

( software engeineerciência da computaçaplicada na transfor

computador em umaferramenta útil, resol problemas para os seutilizadores.

Engenheiro deSoftware

( software engineer )

profissional que se u boas práticas de engem um projeto de sof



Enumeração (enumeration) lista dvalores identificadosnomes e usados com

série para um tipo deem particular.

Especificação( specification) descrsistema de software seu componente, deto que ele faz (ou dev

Estado

( state) caracteriza u

condição onde o objdaquela classe podeencontrado. O estadoatividade da classe d

caráter lento (estado



ação), e às vezes até(estado de espera). Oeventos provocam a

no estado.

Estereótipo

( stereotype) são bas

nos elementos já exina UML e podem essemântica, mas não a

estrutura destes elemum dos mecanismosextendibilidade na U

Evento de

tempo

(time event ) evento qacontece em um mom particular. Pode ser

como uma expressão



tempo.

Eventos

(event ) retrata uma arápida e que não podinterrompida. Semprum evento entre doisEstá associado às opdas classes, e à sua d

Expressão

(expression) Uma sede caracteres que resum valor de um tipo

particular. Por exemexpressão " (7 + 5 *resulta em um valor numérico.



F

Foco de controle

( focus of control ) síem um diagrama deseqüência que mostr período de tempo duqual um objeto estáexecutando uma ação

diretamente ou por u procedimento subord

Fornecedor( supplier ) Um tipo, ccomponente que provserviços que podem invocados por outros



Framework

( framework ) micro-arquitetura que prov

modelo extensível paaplicações dentro dedomínio específico.

G

Generalização

( generalization) relaexistente entre um elmais geral e um elem

mais específico de uclassificação. O elemais específico é totconsistente com o ele



mais geral e contéminformação adicionainstância do element

específico pode ser usempre que o elemengeral for aceito.

Granularidade

( granularity) caractassociada ao tamanhelementos de um mod

uma granularidade acaracteriza uma granabstração, uma granu baixa leva a um altoespecificação.

Interface Gráfica do



GUI do inglês Graphics Interface.

H

Herança

(inheritance) propridas classes de podergeradas a partir de oclasses, herdando de

propriedades estátic(atributos) e dinâmic(operações) erelacionamentos.

(interface inheritanc

herança de interface



Herança deinterface

elemento mais genércomo uma classeabstrata. Não inclui h

da implementação qurealizada pela classeherda a interface.

Herança

múltipla

(multiple inheritanc propriedade das clas poder herdar de mai

classe ao mesmo temé um propriedade facimplementável.

I



IDEAmbiente Integrado dDesenvolvimento, do

Integrated Developm

Environment

Implementação

(implementation) de

de como algo é consé processado. Por exuma classe é aimplementação de uum código é a imple(contrução) de uma c

(instance) membroindividual de um tipoclasse. Em um uso m

formal é aceitável se



Instância um membro de uma ccomo um objeto ou uinstância. Sinônimos

ocorrência em algun

Integração

(integration) ação d

colocar partes de um juntas para formar o união das partes requconhecimentos especconfiguração e de técintegração.

(interaction) conjuntrocas de mensagem conjunto de objetos d

um contexto particula



Interação realizar um propósitoespecífico. Uma inte pode ser descrita po

mais cenários.

Interface

(interface) descreve

comportamento extervisível de uma classcomponente ou outra

entidade. É uma clasformada apenas por abstratos, servindo pdefinir uma forma de

comunicação. Descrconjunto de mensageclasses que implemeinterface devem obed



J, K,L

Linha da vida

de um objeto

(object lifeline) linhdiagrama de seqüêncrepresenta a existêncobjeto durante um cetempo.

M

Máquina deestado

( state machine) espesucessões de estadosobjeto ou uma intera passam durante sua v



resposta aos eventosrecebe.

Membro

(member ) parte de uclasse, pode ser repr por um atributo ou u

operação.

Mensagem

(message) comunica

objetos que leva infocom a expectativa quresultará em uma ativO recebimento de um

mensagem é, normalconsiderado um even



Mensagemassíncrona

(asynchronous messde mensagem onde oemissor não tem sua

execução interrompiesperar por resultado

Mensagemsíncrona

( synchronous messade mensagem onde oemissor pausa seu processamento para

por resultados.

Método

(method ) Os método

sugerem passos a serseguidos para cumprvazio existente entre

o produto de softwar



implementação de uoperação. O algoritm procedimento que af

resultados de uma op

Modelo

(model ) representa,

simplificadamente, o pretende construir, c planta de uma residêmodelo mostra não s

requisitos do probletambém como eles seatendidos pelos elemsolução.

(conceptual model )

que reúne todos os c



Modeloconceitual

presentes no problemestudo. Construído eescala menor do que

modelo de contexto,estrutura do sistema, para isso um modelosimplificado de clas

Modelocontextual

(contextual model )representa os aspecto

funcionais de alto nívsistema, possui umaescala grande o bast

acomodar todo o sistum único diagrama.

(detailed model ) inc



Modelodetalhado

todos os detalhes deversão projetada dosoftware. O modelo

detalhado pode possnível de detalhe equiao código do softwa

Multiplicidade

(multiplicity) especiabrangência dacardinalidade permique um conjunto podassumir. Podem ser dmultiplicidade para p

dentro de associaçõedentro de composiçõrepetições e em outro propósitos.



N

Nó

(node) representam oequipamentos em umrede de processamen

dados. As ligações enós representar asassociações físicas eexistentes entre osequipamentos.

Nome (name) seqüência decaracteres que identielemento dos diagra



Nota

(note) um comentárioum elemento ou a umcoleção de elemento

nota não acrescenta usignificado ao eleme pode no entanto restr

O

Objeto ativo

(active object ) objet possui uma linha de de execução e pode i

controle de uma ativUma instância de umativa.



Objeto emissor( sender [object]) ob passa uma mensagemobjeto receptor.

Objetopersistente

( persistent object ) oque existe depois do

processo ou da linhacontrole que o criou,normalmente, associ

bancos de dados e ar

Objetos

(object ) instância de

classe, ele implemenclasse para o sistemaestrutura do objetos definida pela classe,



operações e estados dos atributos) são dena instância.

Operação

(operation)responsabilidades atàs classes, associadaa mensagens que a cl pode receber, e que as funcionalidades q

aquela classe está aprealizar. São implem pelos métodos.

P



Pacote

( package) elementoUML utilizado para aoutros elementos de

sistema, para organizum pacote pode abrioutros elementos, oudiagramas, e até outr pacotes. Um sistema pensado como um ún pacote de alto nível.

Papel

(role) comportamentespecíficado por umuma entidade que pa

de um contexto partic

( parameter ) variáve



Parâmetro pode ser alterada, traou retornada, possuitipo e direção. Parâm

são usados para opermensagens e eventos

Polimorfismo

( polimorfism) proprfundamental da orienobjetos associada aonão se precisa conhe

instância da classe putilizar seus serviços propriedade leva aoque uma mesma men pode ser interpretadamodos diferentes, qurecebida por objetos

diferentes.



Pós-condição

( postcondition) Umarestrição que deve severdadeira na concluuma operação.

Precondição

( precondition) Umarestrição que deve severdadeira quando u

operação é invocada

Problema

( problem) Como todde engenharia, o projsoftware tem como pobjetivo resolver um

problema.



Processo

( process) Uma linha

controle que pode seexecutada simultaneacom outras linhas decontrole.

Processo dedesenvolvimento

(development procesconjunto de passos

ordenados executadoum determinado propdurante o desenvolvide software, que inclconstruir modelos e programar.



Produto

( product ) artefatosconstruídos durante o processo de

desenvolvimento, comodelos, diagramas,documentação e plantrabalho.

Programador decomputadores

(computer program profissional especia

em criar programas fdiferentes linguagens programação existen

(design) A parte do pde desenvolvimento

software cujo propó



Projeto

principal é decidir csistema será implemDurante o projeto sã

tomadas decisõesestratégicas e táticasencontrar osrequisitos funcionaisexigências de qualidum sistema.

Pseudo-estado

( pseudo-state) vérticuma máquina de estaforma de um estado,

se comportam comoestado como: inicialas conexões históric



Q

Qualificador

(qualifier ) atributo luma relação entre claseus valores limitamconjunto de objetos q

participam da associ

R

Raia

( swimlane) pacote p

no diagrama deatividade, que serveorganizar asresponsabilidades as

a um objeto.



Receptor

(receiver [object]) o

endereçado por umamensagem passada pobjeto emissor.

Rede

(network ) ligações enós representando as

associações físicas eexistentes entre osequipamentos.

Relação(relationship) conexsignificados existentelementos do diagra



Requisito

(requirement ) proprou comportamento d

de um sistema. Caracde um problema queresolvida pelo sistem

Responsabilidade

(responsabilitiy) o qclasse deve saber ou

fazer, correspondematributos e às operaçuma classe.

Restrição

(contraint ) condiçãolimita o alcance de uelemento, as restriçõ



parte dos mecanismoextensibilidade da U

Reuso

(reuse) O uso de um pre-existente em outrcontexto além daquequal ele foi criadooriginalmente, econotempo e recursos node desenvolvimento.

S

( signal ) evento comnome, que pode ser iexplicitamente, pode



Sinal anunciado ou pode sdirigido para um úniobjeto ou conjunto d

objetos.

Sistema

( system) união de paum objetivo específiresolver um problemseus usuários. Uniãohardware e software

Software

estratégia utilizada presolver um problem

com apoio de umcomputador, vai alé programa de comput



Subclasse

( subclass) especializoutra classe, a superrelação de

generalização (heran

Subsistemas( subsistem) um siste parte de um sistema Na UML um subsistemodelado como um p

componentes.

Superclasse

( superclass) Em uma

de generalização (hea generalização de oclasse, a sub classe.



Superestados

( superstate) agrupamestados, e os eventosassociados a eles, qu

possuem um comporcomum.

T

Texto ( string ) seqüência dcaracteres.

Thread

(trread ) caminho deexecução de um progum modelo dinâmicoalguma outra represe



de fluxo de controle.

Tipo

(type) define uma esde dados e operaçõeafetam esta estrutura preocupação de impl

estas operações. Um pode definir umaespecificação de ope(como uma assinatur

não a sua implementa

Tipo primitivo

( primitive type) tipo

de um lingaugem, é pdefinido, como um inum caracter.



Transição

(transition) indica qobjeto no primeiro e poderá ir para um se

estado quando um evespecificado aconteccondições específicasatisfeitas.

U

UMLLinguagem UnificadaModelagem do inglêUnified Modeling La

V



Valor(value) Um elementodomínio de tipo, instum atributo.

Valor rotulado

(tagged value) definexplícita de uma pro pelo par: nome-valovalor rotulado, o no

refere ao rótulo. O vrotulado é um dosmecanismos deextendibilidade em U

(link ) conexão de sig

entre objetos. A instâ



Vínculo uma associação, servmeio para que as mefluam e para a

navegabilidade no di

Visão

(view projection)

observação de um m partir de uma determ perspectiva ou pontovista, omite entidade

não são pertinentes a perspectiva.

(visibility) capacidaclasses de envolver cápsula atributos e

operações, ocultando



Visibilidade a informação de outrclasses que se encondesta cápsula. A

visibilidade pode se pública, privada ou protegida.

W, X,Y,Z



APÊNDICE



Códigos Java dosExemplos citados nolivro

Seguem-se extratos dos programasJava que implementam os exemplosdesenvolvidos no livro. O objetivodeste apêndice é mostrar, com um pouco

mais de detalhes os códigos dasaplicações desenvolvidas comoexemplo para o livro. Os comentáriossobre o código, quando necessário,estão presentes no próprio código. Osexemplos desenvolvidos para esteivros podem ser executados pela

nternet , no website



www.eduardodeboni.com/uml dedicadoa este livro..

http://www.eduardodeboni.com/uml



Código Java do Sistema deVendas da Loja

Classe POS (implementada por

uma Applet)

/*

A basic extension of thejava.applet.Applet class

*/

import java.awt.*;

import java.applet.*;



/**

* Applet original que chama ainterface POS da loja

*

* @author JEDeboni

* @version 1.0

* @since 13/01/2003

*/

public class POS extends Apple

{



Loja aLoja;

Produto oproduto="null;"

Cliente ocliente="null;"

int parcelas="1;"

/**

* Programa principal deuma Applet.

* Aqui estão as funçoesde desenhar os componentes dainterface

* e de acioar os objetos



de negocio

*/

public void init()

{

/*

* Cria os dados da Loja

*/

aLoja = new Loja();

//{{INIT_CONTROLS



setLayout(newBorderLayout(0,0));

setSize(445,92);

panel1.setLayout(newGridLayout(3,4,0,0));

add(BorderLayout.NORTH,panel1);

label1.setText("Codigo ");

label1.setAlignment(java.awt.Lab

panel1.add(label1);

panel1.add(textField1);



button3.setLabel("PRODUTO");

panel1.add(button3);

button3.setBackground(java.awt.C


label2.setText("CGC");


panel1.add(label2);


button1.setLabel("CLIENTE");






label3.setText("N.parcelas");


panel1.add(label3);


button5.setLabel("PARCELAS");






button2.setLabel("Limpar");

add(BorderLayout.SOUTH,button2);


//}}

//{{REGISTER_LISTENERS

SymAction lSymAction



= new SymAction();

button1.addActionListener(lSymAc




//}}

}

//{{DECLARE_CONTROLS



java.awt.Panel panel1 =new java.awt.Panel();

java.awt.Label label1 =new java.awt.Label();

java.awt.TextFieldtextField1 = new

java.awt.TextField();

java.awt.Button button3 =new java.awt.Button();

java.awt.TextFieldtextField2 = newjava.awt.TextField();



java.awt.TextField();





java.awt.Label label3 =

new java.awt.Label();




java.awt.Button button2 =

new java.awt.Button();



//}}

class SymAction implementjava.awt.event.ActionListener

{

/**

* Captura os eventoda interface e os transfere paraa Applet

*

* @param eventevento capturado



*/

public voidactionPerformed(java.awt.event.Aevent)

{

Object object event.getSource();

if (object ==button1)

button1_ActionPerformed(event);

else if (objec== button3)








}

}

/**

* Ação do botão CLIENTE



* que obtem um Cliente dlista com base no seu CGC

*

* @param event

*/

voidbutton1_ActionPerformed(java.awtevent)

{

try{

int cgc =Integer.parseInt(textField3.getT

oCliente =aLoja.getCliente(cgc);



textField4.setText(oCliente.getN

} catch(Exception e){

textField4.setText("Erro");

}

}

/**

* Ação do botão PRODUTO



* Obtem um produto dalista de produtos com base nocodigo

*

* @param event

*/


{

try{

int codigo =Integer.parseInt(textField1.getT

oProduto =aLoja.getProduto(codigo);



textField2.setText(oProduto.getD

} catch(Exception e){


}

}

/**

* Ação do botão PARCELAS

* Verifica se a venda

esta aprovada com base noproduto e

* no cliente jaidentificados.



*

* @param event

*/

voidbutton5_ActionPerformed(java.awt

event)

{

try{

Parcelas =

Integer.parseInt(textField5.getT

boolean ok =oProduto.isAprovado(Parcelas,oCliente);



if (ok) {

textField6.setText("Aprovada");

} else {

textField6.setText("

Não Aprovada");

}

}catch(Exception e){


}

}

/**



* Ação do botão Limpar

* limpa os camposanteriores para facilitar umanova consulta

*

* @param event

*/


{

// to do: code goeshere.

textField1.setText("");








}

}

Classe BDLoja

/**



* Classe auxiliar queinicializa a loja.

*/

public class BDLoja

{

/**

* Numero de Clientes daLoja

*/

private int N_CLIENTES;



/**

* Numero de produtos dalista

*/

private int N_PRODUTOS;

/**

* Classe auxiliar queimplementa a persistencia dosdados dos produtos e clientes

* Eh uma classe que echamada na in cializaçao daloja.

* Ela guarda os dados dosclientes em codigo.



* Em aplicaçoes comerciaisdeveria ser substituida poracesso a um banco de dados

*/

public BDLoja(){

/*

Definir a quantidade dedados da loja

*/

N_CLIENTES = 5;

N_PRODUTOS = 9;

}



/**

* Obtem a lista de produtoda loja, cadastrados na classeBDLoja

*

* @return Array de produtoarmazenados na Loja

*/

public Produto[] getListaP({

Produto listaP[] = new

Produto[10];

listaP[1] = newProduto(101,"Guitarra SoloFender",2000);



listaP[2] = newProduto(102,"Saxofone",800);

listaP[3] = newProduto(103,"BateriaEletrônica",750);

listaP[4] = new

Oferta(104,"Piano deCalda",5000);

listaP[5] = newProduto(105,"Guitarra

Baixo",1000);

listaP[6] = newProduto(106,"Violão",200);

listaP[7] = newProduto(107,"Trompete",500);

listaP[8] = new

Produto(108,"Flauta doce",100);



listaP[9] = newOferta(109,"BaixoAcústico",1500);

return listaP;

}

/**

* Obtem o Numero deprodutos da lista

*

* @return Numero deprodutos da lista

*/



public int getNPRODUTOS() {

return N_PRODUTOS;

}

/**

* Obtem a lista de clienteda loja, armazenados na classeBDLoja

*

* @return Array de Cliente

*/

public Cliente[] getListaC(

{



Cliente listaC[] = newCliente[10];

listaC[1] = newCliente(1000,"Stan Getz",1000);

listaC[2] = newClienteVIP(2000,"H.

Hancock",1000);

listaC[3] = newCliente(3000,"CharlieParker",500);

listaC[4] = newClienteVIP(4000,"CharlieMingus",500);

listaC[5] = newCliente(5000,"Miles Davis",300);



return listaC;

}

/**

* Obtem o numero declientes da lista

*

* @return Numero declientes da lista

*/

public int getNCLIENTES() {

return N_CLIENTES;



}

}

Classe Loja

/**

* Classe que representa a Loj

no sistema

*

* @author JEDeboni



* @version 1.0

* @since 2003

*/

public class Loja

{

/**

* Array de produtos queimplementa um catálogo deproduto

*/

protected Produto listaP[]

new Produto[10];



/**

* array de clientes, queimplementa um catálogo declientes

*/

protected Cliente listaC[] new Cliente[10];

/**

* Numero de clientes docatalogo

*/



protected int N_CLIENTES;

/**

* Numero de produtos docatalogo

*/

protected int N_PRODUTOS;

/**

* objeto que representa obanco de dados, da acesso aosdados persistentes

*/



BDLoja bd = new BDLoja();;

public Loja(){

/**

* Construtor padrao da classLoja.

* Aciona os métodos deacesso a lista de clientes eprodutos da classe BDLoja

*/

listaP = bd.getListaP();

N_PRODUTOS =bd.getNPRODUTOS();



listaC = bd.getListaC();

N_CLIENTES =bd.getNCLIENTES();

}

/**

* Pesquisa na lista deprodutos um produto com umdeterminado indice

*

* @param index numerointeiro que indica o indice doproduto na lista

* O indice deve estardentro dos limites da lista



* @return O produto dalista com o indice

*/

public ProdutogetProdutoIndex( int index) {

return (listaP[index]);

}

/**

* Método de acesso ao

Cliente da lista com base noindice

*



* @param index indice docliente na lista. O indice deveestar dentro do limite da lista

* @return um cliente queesta na lista

*/

public ClientegetClienteIndex( int index) {

return (listaC[index]);

}

/**

* método de acesso aocliente com base no CGC



* o método pesquisa a listde clientes para encontrar ocliente que possui este CGC

*

* @param pCGC numero do CG

* @return Um cliente dalista com base no CGC

*/

public ClientegetCliente(int pCGC){

Cliente c = null;

for (int i="1;"i<=N_CLIENTES; i++){

if(listaC[i].getCGC()==pCGC)



{

c = listaC[i];

}

}

return (c);

}

/**

* Método de pesquisa da

lista de produtos por um produtoque possui um codigo

*



* @param pCodigo codigo doproduto

* @return um produto combase no codigo da lista

*/

public ProdutogetProduto(int pCodigo){

Produto p = null;

for (int i="1;"i<=N_PRODUTOS; i++){

if

(listaP[i].getCodigo()==pCodigo)

{

p = listaP[i];



}

}

return (p);

}

}

Classe Produto

/**

* Classe Produto, representaos produtos vendidos na loja

*



* @author JEDeboni

* @version 1.0

* @since 2003

*/

public class Produto

{

private int codigo = 0;

private int preco = 0;

private String descricao=""

/**



* Metodo construtor doproduto com base apensas nocodigo.

* Deve-se usar os metodosde acesso para complementar asinformaçoes

*

* @param pCodigo codigo doproduto.

*/

public Produto ( intpCodigo) {

codigo = pCodigo;

return;

}



/**

* metodo contrutor doproduto com todos os parametros

*

* @param pCodigo codigo doproduto

* @param pDescricaodescricao do produto

* @param pPreco preco doproduto

*/

public Produto (int pCodigoString pDescricao, int pPreco)



preco = pPreco;

codigo = pCodigo;

descricao = pDescricao;

return;

}

/**

* metodo de acesso ao precdo produto

*

* @return valor atual dopreco do produto



*/

public int getPreco () {

return preco;

}

/**

* metodo para atualizaçãodo preco do produto

*

* @param pPreco valor donovo preco do produto

*/



public void setPreco (intpPreco) {

preco = pPreco;

}

/**

* metodo de acesso adescricao do produto

*

* @return a descriçao atua

do produto

*/

public String getDescricao(



{

return(descricao);

}

/**

* metodo para atualizaçãoda descriçao do produto

*

* @param pDescricao novadescricao do produto

*/

public void

setDescricao(String pDescricao)




}

/**

* metodo de acesso aocodigo do produto

*

* @return o codigo doproduto

*/

public int getCodigo() {

return codigo;



}

/**

* metodo que transforma osdados do produto em uma String

de texto

* para facilitar aimpressao

*

* @return String com umadescriçao do produto.

*/

public String toString() {



String s = "n";

s = s + getCodigo();

s = s + ""+getDescricao();

s = s + " R$ "+getPreco()

return s;

}

/**

* método de verificação daaprovação do Crédito

* verificando as regras devenda a crédito para

* um dado cliente



*

* @param n numero deparcelas da venda

* @param c objeto querepresenta o Cliente que e ocomprador do produto

* @return verdadeiro se avenda foi aprovada e falso se avenda for recusada

*/

public booleanisAprovado(int n, Cliente c){

/*

em linhas gerais a venda aprovada se a dívida



da venda for menor que ocrédito do cliente

*/

int divida = preco -(preco/n);

//System.out.println("divida ="+divida+ " credito ="+c.getCredito());

if (divida <=c.getCredito()) {

return (true);

} else {

return (false);

}



}

}

Classe Oferta

/**

* Classe que representa umproduto em oferta.

*

* @author JEDeboni

* @version 1.0



* @since 2003

*/

public class Oferta extendsProduto

{

/**

* método de verificação daaprovação do Crédito

* verificando as regras devenda a crédito para um cliente

*

* @param n numero deparcelas da venda



* @param c objeto querepresenta o cliente compradordo produto

* @return verdadeiro se avenda for aprovada, ou falso sea venda nao for aprovada

*/

public booleanisAprovado(int n, Cliente c){

int preco =super.getPreco();

int divida = preco -

(preco/n);

//System.out.println("divida ="+divida+ " credito =

"+c.getCredito());



if ((divida <=c.getCredito()) || (n<=3)) {

return (true);

} else {

return (false);

}

}

public String toString()

{

String s = "n";

s = s + getCodigo();



s = s + ""+getDescricao();

s = s + " R$"+getPreco()+" EM OFERTA";

return s;

}

/**

* Construtor de um produtem Oferta

*

* @param pCodigo codigo dproduto



* @param pDescricaodescrição do produto

* @param pPreco preço doproduto

*/

public Oferta (int pCodigoString pDescricao, int pPreco)

super (pCodigo,pDescricao, pPreco);

return;

}

}



Código Java do Jogo daVelha

Segue-se o código completo do jogoda velha na sua implementação básica.

Classe Forca

import javax.swing.JOptionPane

/**

* Classe principal, queintegra as outras naimplementaçao do jogo



*

* @author JEDeboni

* @version 1.0

*/

public class Forca {

/**

* objeto boneco usado nojogo

*/

private static Boneco bonec= new Boneco();



/**

* objeto ppalavra queimplementa a Palavra secreta nojogo

*/

private static Palavrapalavra = new Palavra();

/**

* objeto j que representa ojogador no jogo

*/

private static Jogadorjogador = new Jogador();



/**

* programa principal do jogda forca

*

* @param arg não é utilizad

*/

public static voidmain(String arg[]){

char letra;

String tela="";

palavra.escolheSecreta();



do {

//

// constroi o desenho daforca,

// da palava e das letra

usadas

tela =boneco.desenha()+"n"

+palavra.desenha()+"n"

+jogador.getLetrasChutadas();

//

// captura uma letraentrada pelo usuario



letra="JOptionPane".showInputDia[0];

//

// Envia mensagem aojogador para entrar a letra no

jogo

jogador.chutaLetra(letrapalavra, boneco);

}while(!(jogador.ganhar(palavra)||jogado

//

// envia uma mensagem fina

if(jogador.ganhar(palavra))



{

tela = tela + "nParabens! ganhou!";

};

if

(jogador.perder(boneco))

{

tela = tela + "n Quepena, perdeu!";

};

JOptionPane.showMessageDialog(nu

"Jogo daForca",JOptionPane.INFORMATION_M



System.exit(0);

}

}

Código da Classe Palavra

import java.io.*;

/**

* Representa a palavra secretno jogo da forca.

* A classe permite escolher

uma palavra de uma lista



arquivada

* e verificar se a letra estan palavra

*

* @author JEDeboni

* @version 1.0

* @since 2002

*/

public class Palavra

{

/**



* array com as letras dapalavra escolhida que e mantidasecreta

*/

private char[]palavraEscolhida = new

char[100];

/**

* array com as letras jadescobertas da palavra

*/

private char[]palavraDescoberta = newchar[100];



/**

* numero de letrasexistente na palavra escolhida

*/

private int np = 0;

/**

* seleciona aleatoriamenteuma palavra de uma lista

* armazenada em no arquivoListaPalavras e

* inicializa a palavra a



ser descoberta com '_'

* vao existir tantos tracoquantas letras na palavra

*/

public void escolheSecreta

() {

String linha[] = newString[200];

try

{

//

// abre o arquivo

FileInputStream ds = new



FileInputStream("ListaPalavras.t

DataInputStream arquivo= new DataInputStream(ds);

//

// le as palavras do

arquivo

int i="-1;"

do

{

i++;

linha[i]=arquivo.readLine();

} while



(linha[i]!=null);

int lp="i-1;" //numero de palavras no arquivo

//

// escolhe uma palavra

da lista e mede o seu tamanho

int iescolhido = newDouble(Math.random()*lp).intValu

np="linha"[iescolhido].length();

//

// preenche de espaços"_" a palavra descoberta

for (i="0;" i<np; i++)



palavraEscolhida[i+1]=linha[iesc[i];

palavraDescoberta[i+1]='_';

}

} catch (IOException e)

{

System.out.println("Errona leitura do arquivo depalavras");

System.out.println(e);

}

}



/**

* metodo para desenhar apalavra secreta

*

* @return retorna um textocom a palavra secreta

* tracos marcam as letrasnao descobertas

*/

public String desenha()

{

String linha=" ";



for (int i="1;" i<=np; i++{

linha = linha +palavraDescoberta[i]+" ";

}

return(linha);

}

/**

* verifica se a letra estana palavra secreta

*

* @param letra letra a sertestada na palavra



* @return verdadeiro se aletra está na palavra ou falsose nao esta

*/

public booleanletraNaPalavra (char letra)

{

boolean achou="false;"

for (int i="1;" i<=np;i++){

if

(letra==palavraEscolhida[i]){

achou="true;"

palavraDescoberta[i]=letra;



}

}

return(achou);

}

/**

* verifica se a palavraesta completa ou nao

* procurando espaços "_" npalavra a ser descoberta

*

* @return falso se a

palavra esta incompleta ou



verdadeiro esta completa

*/

public boolean isCompleta (

{

boolean ok = true;

for (int i="1;" i<=np;i++)

{

if(palavraDescoberta[i]=='_')

{

ok = false;



}

}

return(ok);

}

/**

* metodo construtor daPalavra

*/

public Palavra ()

{

// não existe construção



especial para a palavra

}

}

Classe Jogador

/**

* Representa o Jogador no jog

da forca

* Permite que o jogadorinteraja com o jogo chutando as

letras para adivinhar a palavrasecreta

* Esta classe ainda guarda apalavra secreta



*

* @author JEDeboni

* @version 1.0

*/

public class Jogador

{

/**

* numero de letras chutadas

até o momento

*/

private int iletra="0;"



/**

* lista de letras chutadasno jogo

*/

private char[]letrasChutadas= new char[50];

/**

* retorna uma lista dasletras chutadas no jogo

*



* @return uma lista dasletras chutadas

*/

public StringgetLetrasChutadas(){

String linha="Letrasusadas: ";

for (int i="1;" i<=iLetra;i++)

{

linha="linha"+letrasChutadas[i];

}

return(linha);



}

/**

* adiciona uma letra nalista de letras chutadas

*

* @param letra letra a seradicionada na lista

*/

public void

addLetrasChutadas(char letra){

iletra="iLetra"+1;



letrasChutadas[iLetra]=letra;

}

/**

* le uma letra para tentarcompletar a palavra secreta e

* verifica se a letra estana palavra, e desenha uma partedo

* boneco se não tiver.

*

* @param letra letra a serverificada



* @param palavra palavra aser descoberta

* @param boneco boneco querepresenta o jogador na forca

*/

public void chutaLetra (charletra, Palavra palavra, Bonecoboneco)

{

addLetrasChutadas(letra);

if

(!palavra.letraNaPalavra(letra))

{

boneco.addParte();



}

}

/**

* operaçao que verifica se jogador ganhou

*

* @param palavra palavra aser descoberta, se for completao jogador ganhou

* @return verdadeiro de ojogador ganhou, falso se nãoganhou

*/



public boolean ganhar(Palavrpalavra)

{

return(palavra.isCompleta());

}

/**

* Operaçao que verifica se jogador perdeu

*

* @param boneco boneco querepresenta o jogador, se forcompleto o jogador perdeu



* @return verdadeiro de ojogador perdeu, falso se nãoperdeu

*/

public boolean perder(Bonecoboneco)

{

return(boneco.isCompleto());

}

/**

* contrutor do Jogador, naopossui parametros



*/

public Jogador ()

{

// não existe construtorespecial para o Jogador

}

}

Classe Boneco

/**



* Representa o boneco do jogoda forca

*

* @author JEDeboni

* @version 1.0

* @since 2002

*/

public class Boneco

{

/**

* numero de partesdesenhadas do boneco.



* Começa com zero e termincom 6 (boneco completo)

*/

private int parte="0;"

/**

* Matriz de 3x3 que desenha forca

*/

private char[][] Dforca =

new char[4][4];

/**



* inicializa a forca,zerando a matriz Dforca

* uso privado internamenteao boneco

*/

private void limpaForca ()

{

parte = 0;

Dforca[1][1]=' '; Dforca[1[2]=' '; Dforca[1][3]=' ';





}

/**

* inclui mais uma parte noboneco, o boneco esta previsto

para

* ser construido com 6partes

*/

public void addParte()

{

parte="parte"+1;

if (parte==1) Dforca[1]



[2]='O'; // desenha cabeça

if (parte==2) Dforca[2][1]='/'; // desenha bracoE

if (parte==3) Dforca[2][2]='|'; // desenha corpo

if (parte==4) Dforca[2][3]='';// desenha bracoD

if (parte==5) Dforca[3][1]='/'; // desenha pernaE

if (parte==6) Dforca[3][3]='';// desenha pernaD

}

/**



* desenha o boneco na formde texto

*

* @return texto com odesenho de um boneco e da forcafeito com caracteres

*/

public String desenha()

{

String linha = "n /-----"

linha = linha + "n |"+Dforca[1][1]+Dforca[1][2]+Dforca[1][3];

linha = linha + "n |"+Dforca[2][1]+Dforca[2]



[2]+Dforca[2][3];

linha = linha + "n |"+Dforca[3][1]+Dforca[3][2]+Dforca[3][3];

linha = linha + "n | ";

linha = linha + "n_________";

return(linha);

}

/**

* verifica se o boneco est



completo

*

* @return verdadeiro se oboneco esta completo ou false senao estiver

*/

public boolean isCompleto(){

if (parte==6) {

return(true);

} else {

return(false);

}



}

/**

* método construtor daclasse Boneco

* este metodo limpa a force prepara para colocar um boneco

* a forca e representadapor uma matrix 3x3 Dforca

*/

public Boneco ()

{

limpaForca();



}

}



Código Java do Item deEstoque

Classe Almoxerife

import java.awt.*;

import java.applet.*;

/**

* Classe de interface do

sistema itemEstoque,

* realiza as açoes de capturaos eventos do usuário,



* enviar mensagens para aclasse de negocio e

* exibir o resultado nainterface

*

* @author JEDeboni

* @version 1.0

* @since 2003

*/

public class Almoxerife extend

Applet

{



/**

* objeto que representa oitem de estoque a ser gerenciado

*/

ItemEstoque item;

/**

* objeto que representa ocomprador que gerencia este itemde estoque

*/

Compras comprador;



/**

* operaçao deinicializaçao da AppletAlmoxerife

*/

public void init()

{

//{{INIT_CONTROLS

setLayout(newBorderLayout(0,0));

setSize(426,266);

panel1.setLayout(newFlowLayout(FlowLayout.CENTER,5,5



add(BorderLayout.NORTH, panel1);

label1.setText("Almoxerife:quantidade");

panel1.add(label1);

textField1.setText("0");


btnRetirar.setLabel("Retirar");

panel1.add(btnRetirar);

btnRetirar.setBackground(java.aw



btnRepor.setLabel("Repor");

panel1.add(btnRepor)

btnRepor.setBackground(java.awt

textArea1.setText("Historico dastransações");

add(BorderLayout.CENTER,textArea1);

panel2.setLayout(new

FlowLayout(FlowLayout.CENTER,5,5

add(BorderLayout.SOUTH, panel2);



label2.setText("Mensagem aocomprador");

panel2.add(label2);


//}}

comprador = newCompras();

item = newItemEstoque("101010", "Tonner de

copiadora", 100, 70, 50,comprador);

textArea1.append(item.toString()



//{{REGISTER_LISTENERS

SymAction lSymAction= new SymAction();

btnRetirar.addActionListener(lSy

btnRepor.addActionListener(lSymA

//}}

}

//{{DECLARE_CONTROLS






java.awt.TextField(2);

java.awt.Button btnRetira= new java.awt.Button();

java.awt.Button btnRepor new java.awt.Button();

java.awt.TextArea

textArea1 = newjava.awt.TextArea();





java.awt.TextFieldtextField2 = newjava.awt.TextField(25);

//}}

class SymAction implementjava.awt.event.ActionListener

{

/**

* operaçao paracapturar os eventos da interface



*

* @param eventevento vindo do usuário e

* que devem sertratados pela classe

*/

public voidactionPerformed(java.awt.event.Aevent)

{

Object object

event.getSource();

if (object ==btnRetirar)



btnRetirar_ActionPerformed(event

else if (objec== btnRepor)

btnRepor_ActionPerformed(event);

}

}

/**

* operacao que trata o

evento de Retirar,

* le o valor daquantidade a ser retirada,



* envia uma mensagem deretirar para o itemEstoque e

* exibe o resultado nainterface

*

* @param event eventovindo da açao do usuário

*/

voidbtnRetirar_ActionPerformed(javaevent)

{

int n =Integer.parseInt(textField1.getT

if



(item.retirarMaterial(n))

{

textArea1.append("nn*** Ação :Retirar "+n);

} else

{

textArea1.append("nn*** Ação deRetirar bloqueada");

}


textField2.setText(comprador.get



}

/**

* operaçao que trata oevento de repor,

* envia uma mensagem derepor para o itemEstoque e

* exibe o resultado nainterface

*

* @param event eventovindo da interface do usuario

*/



voidbtnRepor_ActionPerformed(java.awevent)

{

int n =Integer.parseInt(textField1.getT

if(item.reporMaterial(n))

{

textArea1.append("nn*** Ação :Repor "+n);

} else {

textArea1.append("nn*** Ação deRepor bloqueada");



}


textField2.setText(comprador.get

}

}

Classe ItemEstoque

/**

* Representa o item de umsistema de estoque gerenciado



* A regra de controle deestoque nao permite

* que se faça uma retirada seo estoque estiver baixo.

*

* @author JEDeboni

* @version 1.0

* @since 2003

*/

public class

ItemEstoque

{

private int qtd = 0;



/**

*/

private int qtdReposicao =0;

private int estoqueMinimo =0;

private String descricao=""

private String codigo="";

private Compras comprador;

/**



* Metodo construtor do itemde estoque,

* com todos os atributoscomo parametros

*

* @param pCodigo Codigo

unico do item de estoque,* @param pDescricaoDescriçao textual breve do item

* @param pQtd Quantidade

armazenada no item,

* nao pode ser menor do quo estoque minimo.

* @param pQtdReposicaoQuantidade que deve ser reposta

* @param pEstoqueMinimo

Valor do estoque minimo do item,



ao atingir o estoque minimo e'disparada ao comprador um pedidode compra

* @param pComprador Objetodo tipo Compras que representa ocomprador responsavel por reporeste item.

*/

public ItemEstoque(StringpCodigo,

StringpDescricao,

int pQtd

intpQtdReposicao,

int



pEstoqueMinimo,

CompraspComprador)

{

codigo = pCodigo;


qtd = pQtd;

qtdReposicao =pQtdReposicao;

estoqueMinimo =

pEstoqueMinimo;

comprador = pComprador;

}



/**

* metodo chamado pararetirada dos itens do estoque

*

* @param n quantidade deitens a serem retirados

* @return verdadeiro se omaterial foi retirado

* <br> ou falso se o

material nao foi retirado

*/

public booleanretirarMaterial(int n)



{

boolean ok="false;"

if (isBaixo())

{

comprador.setMensagens("EstoqueBaixo");

} else

{

if (qtd>=n) {

qtd = qtd - n;

ok = true;



}

if (qtd<estoqueMinimo){

comprador.comprar(this);

}

}

return(ok);

}

/**



* metodo chamado nareposicao dos itens no estoque

*

* @param n quantidade deitens a ser reposta,

* mantida para haver

coerencia com a retirada,

* (deve ser sempre igual aqtdReposicao)

* @return verdadeiro se ahouver a reposicao do material

* <br> falso se a reposica

não ocorrer porque o estoqueestava normal

*/

public boolean reporMateria



(int n)

{

boolean ok = false;

if (isBaixo())

{

qtd = qtd +getQtdReposicao();

comprador.setMensagens("materialreposto");

ok = true;

}

return(ok);



}

/**

* Metodo de acesso aquantidade de itens de estoque

*

* @return quantidade emestoque

*/

public int getQtd ()

{



return(qtd);

}

/**

* metodo de acesso aquantidade de reposicao

*

* @return quantidade a serreposta

*/

public int getQtdReposicao()

{



return(qtdReposicao);

}

/**

* metodo de acesso ao valodo estoque minimo

*

* @return quantidade deestoque minimo

*/

public int getEstoqueMinimo()

{



return(estoqueMinimo);

}

/**

* operaçao de acesso adescricao do item

*

* @return descricao do item

*/

public String getDescricao(

{

return(descricao);



}

/**

* operação de definiçao daquantidade de reposicao

*

* @param pQtdReposicao novquantidade de reposicao

*/

public void setQtdReposicao

(int pQtdReposicao)

{

qtdReposicao =



pQtdReposicao;

}

/**

* operacao de definicao doestoque minimo

*

* @param pEstoqueMinimonovo valor do estoque minimo

*/

public void setEstoqueMinim(int pEstoqueMinimo)

{



estoqueMinimo =pEstoqueMinimo;

}

/**

* operacao que verifica seo estoque esta atualmente baixo

*

* @return verdadeiro se oestoque esta baixo,

* <br> e falso se o estoquestiver normal

*/



public boolean isBaixo()

{

boolean ok = false;

if (getQtd()<getEstoqueMinimo()) {

ok = true;

}

return(ok);

}

/**

* operacao que fornece uma



descricao textual do item

*

* @return texto quedescreve o item em seu estadoatual.

*/

public String toString()

{

String s = "n"+codigo+"Item : "+descricao+

"n Estoque ="+qtd+" Mínimo ="+estoqueMinimo+" Reposicao ="+qtdReposicao+



"n Estoque baixo "+isBaixo();

return(s);

}

}

Classe Comprador

/**

* Classe que representa osetor de compras da empresa.

* Neste exemplo ira apenas

guardar as mensagens recebidas



* pelo item de Estoque

*

* @author JEDeboni

* @version 1.0

* @since 2003

*/

public class Compras

{

/**

* mensagem que indica aatividade (estado) do comprador

*/



private String mensagens;

/**

* metodo contrutor doobjeto da classe Compras,

* inicia informando quenao ha mensagens no comprador

*/

public Compras()

{

mensagens = "não hámensagens";

}



/**

* le as mensagens docomprador

*

* @return mensagemarmazenada no comprador

*/

public StringgetMensagens()

{

return(mensagens);

}



/**

* define uma mensagem paro comprador

*

* @param pMensagens novamensagem para armazenar

*/

public voidsetMensagens(String pMensagens)

{

mensagens = pMensagens

}



/**

* operacao de comprar,

* futuramente deveraimplementar os processos decompras

*

* @param item ItemEstoquea ser comprado

*/

public voidcomprar(ItemEstoque item)



{

setMensagens("comprar"+item.getQtdReposicao()+""+item.getDescricao());

}

}



otas de Rodapé

[1]Adaptação do software ao cliente,

originaria da palavra: customer , cliente

em inglês.[2]

CGC – Cadatro Geral deContribuinte, substituído pelo CPF,

Cadastro de Pessoas Físicas, um númeroúnico que identifica os contribuintes domposto de Renda, e que é usado para

dentificar unicamente o cliente.



[3]As funções são escritas usando uma

convenção de notação em inglês: getpara obter, set para definir e is para

Modelagem Orientada a Objetos Com a UML - Jose Eduardo Zindel Deboni

Documents

Transcript of Modelagem Orientada a Objetos Com a UML - Jose Eduardo Zindel Deboni