Вы находитесь на странице: 1из 309

Dedicatria

Ao meu filho, Murilo, pelo estmulo, carinho e compreenso.

A quem se destina este livro


Este livro se destina a diferentes classes de leitores, que tem em comum o desejo de
conhecer tcnicas para se descrever um software, seja porque so profissionais da rea
da computao, seja porque acreditam que um software possa ajud-los a melhorar o
seu negcio, seja ele qual for. Os leitores deste livro podem ser:

Estudantes e Professores que podem encontrar neste livro apoio para o


desenvolvimento de cursos de Engenharia de Software, de Anlise e Projeto de
Sistemas e para o desenvolvimento de projetos de software. Apesar da abordagem dada
a este trabalho no ter uma nfase didtica, ele pode ser utilizado como uma leitura
complementar. Especialmente nos captulos iniciais, onde o livro tece os fundamentos
da orientao a objetos, o teor introdutrio pode ser de grande ajuda a estudantes de
computao e reas afins.

Analistas de Sistema e Programadores de Computador envolvidos em


projetos de sistemas de software, que encontraro reunidas neste livro algumas tcnicas
teis para o desenvolvimento de modelos orientados a objeto destes projetos. A adoo
destas tcnicas pode ajud-los a construir sistemas de software mais robustos, mais
confiveis e de manuteno mais fcil.

Usurios ou Gerentes de Projeto de Software que podem adotar algumas


das idias presentes no livro para facilitar o planejamento de um projeto de software. A
leitura ajudar a criar uma linguagem comum entre o usurio, o gerente de projeto e a
equipe tcnica de desenvolvimento. Como um projeto orientado a objetos requer uma
grande dose de modelagem, este livro pode uniformizar os termos usados na
comunicao com a equipe de projeto e ajudar a definir as etapas e produtos do projeto
de software.

Convenes adotadas neste livro


Para facilitar a leitura, este livro adota as seguintes convenes tipogrficas:

Os termos e conceitos importantes para o texto so escritos em negrito na


primeira vez em que eles aparecem. Estes termos podem ser encontrados novamente no
glossrio, ao final do livro, onde recebem uma breve explicao.

Os comandos e extratos de cdigo, escritos em linguagem de programao


usam fonte currier, assim como os nomes de componentes e elementos do modelo,
quando citados no texto so escritos tambm em fonte currier, para diferenci-los do
seu significado fora do escopo do programa.

As citaes, os extratos de textos da bibliografia e palavras em lngua


estrangeira so escritos com caractr itlico.

A lista de referncias bibliogrficas escontra-se no final do livro. Quando


citadas no texto, as referncias aparecem entre parnteses com o nome do autor e o ano
de publicao. Por exemplo: (Beck, 1999) ou citado por Beck (1999).

Os endereos de websites citados no texto e na bibliografia que podem ser


acessados pela internet so grifados como no exemplo: www.omg.org

1. Introduo
Este captulo discute a importncia de se criar um modelo nos projetos de
software. Inicialmente, apresenta o carter dualista do software: ora produto da
criatividade, ora trabalho sistemtico de engenharia, para ento discutir o porqu,
em ambos os casos, o modelo do software ser colocado no centro do processo de
desenvolvimento, como forma de unificar a viso do software entre os participantes
do projeto. O captulo termina fazendo uma apresentao do restante do livro e de
como ele pode ser lido.

1.1.

Introduo ao Desenvolvimento de Software

software um produto da inteligncia humana, por meio dele possvel se


preservar uma boa idia e transmit-la para muitas outras pessoas. O software uma
das poucas maneiras disponveis capazes de capturar o conhecimento de algum e
coloc-lo servio de outros. Existem algumas formas para se fazer isso, como os
livros ou as aulas nas escolas, mas nenhuma delas tem a capacidade de interao que o
software oferece, e que pode transformar o conhecimento capturado, diretamente, em
uma habilidade para o seu usurio. Um usurio, de posse de um software
adequadamente contrudo, passa a ter novas habilidades e pode fazer coisas que antes
no sabia. Esta versatilidade, faz com que haja um grande interesse em converter
conhecimentos e habilidades, cada vez mais complexas, em software. Este livro trata
desta converso, discute-se aqui como se transforma uma idia em um software til.
Como se captura uma idia para que o desenvolvedor crie um sistema de software que
ir dar esta habilidade ao usurio:

Figura 1- O software pode transformar uma idia em uma habilidade


Na construo de um software existe uma boa dose de criatividade, mas h uma
dose ainda maior de pensamento lgico e trabalho discipliando. O computador, uma das
maiores invenes do homem, uma mero escravo do software. Todas as maravilhas
que um computador capaz de desempenhar, dependem, diretamente, da
disponibilidade de um software projetado para realiz-las. Alm da criatividade so
necessrios mtodos, procedimentos e muita disciplina para criar um software til.
Toda esta organizao conseqncia da distncia que separa os computadores dos
homens, e das suas idias. Os computadores so meros autmatos, sabem realizar com
grande velocidade, e por repetidas vezes, tarefas simples, escritas em um programa de
computador. Os programas de computador so seqncias de comandos simples
escritos em uma linguagem de programao que pode ser entendida pelo computador, e
que ainda est muito longe da linguagem humana, e da complexidade do pensamento
humano.

A distncia entre o conhecimento humano e as linguagens de programao se reflete


nas inmeras dificuldades encontradas durante o desenvolvimento de um software.
Utiliza-se aqui o termo software para descrever um conceito muito mais amplo do que
um mero programa de computador. O sofware, que se refere este livro, compreende
toda a estratgia utilizada para resolver um problema real com apoio de um
computador. Mais do que uma srie organizada de instrues, o software atende uma
finalidade, serve a um objetivo do seu utilizador. Nesta viso, o software se completa
ao hardware, o computador propriamente dito, e seus equipamentos perifricos, que em
conjunto compem o que se pode chamar de sistema computacional. O conjunto de
partes relativa ao software no sistema computacional o chamado sistema de
software.
A atividade de programao de computadores apenas uma etapa do trabalho de
desenvolvimento de um software. Programar escrever a soluo de um problema, que
j est definida, em uma linguagem que possa ser entendida pelo computador.
Desenvolver um software compreende ainda muitas outras atividades como a de
analisar o problema que se pretende resolver, e fazer o design da soluo. Desenvolver
software resolver problemas por intermdio da programao de computadores uma
atividade de engenharia, da assim chamada Engenharia de Software.
Engenharia de Software a cincia da computao aplicada na transformao do
computador em uma ferramenta de trabalho para os seus utilizadores. Ela aplicada
hoje aos mais diferentes desafios, desde a manipulao de dados administrativos em um
sistema de informao gerencial at a transmisso de voz e imagem em equipamentos
de telecomunicao. O software hoje uma tecnologia onipresente. Do telefone ao
despertador, da televiso ao supermercado, do brinquedo ao avio, do elevador
internet, o software est presente, dando uma importante contribuio produtividade
das empresas e qualidade de vida das pessoas.
Pressman (1995) destaca a importncia da Engenharia de Software afirmando, que
as prticas de engenharia de software se intensificaram com o agravamento dos
problemas relativos ao software:
a) A sofisticao dos problemas ultrapassaram a nossa capacidade de construir
software que extraia o potencial oferecido pelo hardware,
b) Nossa capacidade de construir software de qualidade no pode acompanhar a
demanda por novas aplicaes da computao, e
c) Nossa capacidade de manter os software existentes foi ameaada por projetos
ruins e recursos inadequados

Observa-se, nestas consideraes, que a Engenharia de Software lida intimamente


com as limitaes da capacidade humana em criar software. O crescimento do poder
dos microprocessadores torna mais aparente os limites da nossa capacidade de
conceber e criar software que aproveite todo esta potencialidade. As demandas
crescentes por parte dos usurios pressionam os desenvolvedores para uma luta contra
o tempo na busca por bons projetos de software, que possam ser construdos e mantidos
adequadamente. Os problemas atuais, a serem resolvidos pelo software, no apenas se
tornaram complexos, eles esto se modificando continuamente, e se integrando a outros
problemas, igualmente complexos, em uma rede global de computadores que a
internet. A digitalizao da informao, por exemplo, ajuda a criar novas demandas
por software, com a possibilidade da distribuio ampla da informao promovida
pela internet.
Aparentemente, a distncia entre os desafios propostos para o software e as
linguagens de programao disponveis para constru-los intransponvel. As
linguagens se mantm relativamente simples, com instrues elementares, criando
programas de computador longos, ambgos e sujeitos muitas falhas. A principal razo
desta limitao a prpria arquitetura das mquinas de Von Neumann, base de todos
computadores e processadores comerciais existentes hoje (Eck, 1995). Este uso, quase
universal, da arquitetura de Von Neumann, como base para os computadores o fator
mais importante para o projeto de linguagens de programao, e conseqentemente, dos
mtodos disponveis para se criar software, como observa Sebesta (1996).
Para se aproximar o mundo dos problemas reais do universo virtual de um
computador necessrio que se selecione um paradigma nico, no qual se possam
descrever os problemas reais, ao mesmo tempo, que possuam uma trqaduo direta
para a linguagem do computador. A busca deste paradigma pode ser usada para retratar
o histrico das linguagens de programao desde a sua criao, e resulta no que hoje
so as linguagens de programao que se utilizam do paradigma de objetos, as
chamadas linguagens orientadas a objetos. Essencialmente, a programao orientada a
objetos busca a soluo dos problemas de software pela identificao objetos do
mundo real, que so depois traduzidos em outros objetos de um modelo de software
(Sebesta, 1996). As linguagens orientadas a objeto como Java, Delphi, Visual Basic,
C++ e C# facilitam esta traduo por se utilizarem dos mesmos fundamentos do
paradigma de objetos que foram usados na modelagem. A disponibilidade e ampla
divulgao destas linguages so as grandes motivadoras para a evoluo da anlise e
do projeto de sistemas orientados a objeto, como tentativas para se transpor o abismo
entre as boas idias e o software que as implementaria.
Este livro objetiva capacitar analistas, programadores e gerentes de projeto de

software na construo de um modelo orientado a objetos de um problema do mundo


real. A principal meta deste trabalho organizar um conjunto coerente de tcnicas de
anlise e projeto de sistemas orientados a objetos, de modo que o modelo construdo
por estas tcnicas sirva de ponte para a construo do software.

1.2.

Como este livro est organizado

Para cumprir os objetivos propostos para este livro, a construo de modelo de um


sistema de software foi dividida em 6 captulos, um glossrio de termos e um apndice,
que so descritos a seguir:
Captulo 1 Introduo. Apresenta esta introduo aos objetivos do livro, a
organizao proposta, como ele pode ser lido, o seu pblico alvo e destaca a
importncia da modelagem para o desenvolvimento de software.
Captulo 2 - Fundamentos da Modelagem Orientada a Objetos. Apresenta os
conceitos fundamentais da orientao a objetos e a sua relao com o processo de
desenvolvimento de software. As caractersticas que diferem a abordagem de objetos
das outras abordagens so aqui descritas com detalhe. Os conceitos de encapsulamento,
herana, mensagens e polimorfismo so definidos e exemplificados por uma aplicao
simples de automao comercial. um captulo de leitura obrigatria para quem deseja
revisar os conceitos da tecnologia de objetos e conhecer a nomenclatura utilizada no
restante do livro. Aos leitores que j possuem estes conceitos, a leitura deste captulo
pode ser dispensada.
Captulo 3 - O Modelo de Contexto. Apresenta o primeiro modelo a ser
desenvolvido para uma abordagem inicial de um problema de software. O modelo de
contexto um modelo alto nvel baseado na anlise funcional, que visa definir a
fronteira do sistema e os seus objetivos principais. Neste modelo so utilizados os
diagramas de casos de uso propostos por Jacobson (1992) e adotados porteriormente
pela UML (Jacobson, 1998). A fronteira isola o sistema de software dos componentes
externos ao software, mas que interagem com ele. Este captulo especialmente
importante para os leitores envolvidos nas definies iniciais de um sistema
computacional, que devem, em contato direto com os clientes do software, especificar
os requisitos do sistema.
Captulo 4 - O Modelo Conceitual apresentado baseado nos cartes CRC.
Descreve a tcnica dos cartes CRC aplicada na definio inicial de um sistema
orientado a objetos. Esta tcnica utiliza cartes comuns de arquivo para representar os
objetos, e ajudam na distribuio das funcionalidades esperadas entre os objetos do
modelo. Este captulo recomendado para os leitores envolvidos na concepo de
sistemas, com experincia ou no em sistemas no orientados a objetos e que devem
passar a "pensar" em objetos. No um captulo essencial para quem j posssui os
conceitos de objetos bem consolidados. Mesmo neste caso este leitores podem se
servir da tcnica dos cartes CRC como um mtodo que permite envolver os clientes e

usurios no levantamento de requsitos de projeto e no processo de concepo do


software.
Captulo 5 - O Modelo de Detalhado de Objetos. Descreve, finalmente, os
diagramas do modelo orientado a objetos na notao proposta pela UML: diagrama de
classes, estados, seqncia, atividades, colaborao, componentes e distribuio. Cada
diagrama descrito em conjunto com seus elementos componentes e aplicado em
diversos exemplos, que permitem ao leitor visualizar as diversas alternativas da sua
aplicao na modelagem de sistemas. um captulo essencial para a compreenso da
notao e dos detalhes construtivos dos diversos diagramas que compem os modelos
orientados a objeto.
Captulo 6 Estudo de Casos. Aplica os modelos apresentados nos captulos 3, 4
e 5 em trs estudos de caso. Inicialmente o estudo de caso da aplicao comercial do
captulo 2 revisado, assim como o exemplo do jogo da forca utilizado no captulo 4, e
o exemplo de estoque do captulo 5. Desenvolvido com uma viso didtica, ele permite
ao leitor compreender a integrao que existe entre os modelos e diagramas. O leitor
pode, se desejar, iniciar a leitura do livro por este captulo tendo uma abordagem
inicial mais prtica, para dai se aprofundar nos assuntos de maior interesse nos
captulos anteriores.
Um Glossrio finaliza o trabalho listando os principais termos utilizados na
modelagem orientada a objetos. Como alguns destes termos pode ter um significado
diferente fora do contexto da modelagem, o glossrio deve ser consultado sempre que
surgir dvida em algum termo durante a leitura do texto.
O Apndice mostra o resultador da traduo dos modelos da UML em cdigos Java,
transformando os exemplos em aplicaes completas. L encontram-se os cdigos dos
programas e o endereo do website para execut-los. Todos os exemplos usados ao
longo do texo esto disponveis para acesso pela internet.
So vrias as possibilidades de leitura do texto do livro, e elas esto
esquematizadas na figura abaixo, partindo do interesse do leitor por uma viso terica,
uma viso prtica ou por um interesse especfico por algum tema:

Figura 2 - Encadeamento possvel para leitura dos captulos


Pode-se iniciar a leitura pelo Captulo 2 para os que desejam consolidar os
fundamentos da orientao a objetos. No entanto, se os leitores j so familiares a estes
conceitos, podem utilizar este captulo para familiarizarem-se com a nomenclatura
utilizada no restante do texto. Os captulos 3, 4 e 5 so relativamente independentes
por se tratarem de 3 modelos que diferem em escala e objetivo. Podem, por isso, ter
uma leitura independente, mas que em conjunto apresentam as possibildades de
modelagem que a orientao a objetos nos oferece. A leitura seqencial destes trs
captulos favorece o entendimento da evoluo dos modelos que ocorre, naturalmente,
durante o desenvolvimento de um sistema de software. Entretando, se o objetivo do
leitor apenas criar uma especificao de alto nvel do sistema pode interromper a sua
leitura no captulo 3. Se alm do modelo de especificao deseja um aprofundamento
dos conceitos do sistema em um modelo conceitual preliminar, ou se estiver
diretamente envolvido na anlise do sistema, deve continuar sua leitura pelo captulo 4.
O captulo 5 se destina aos leitores que desejam compreender os detalhes de um
modelo orientado a objetos criado com a notao da UML, provavelmente por estarem
envolvidos nas etapas de design e construo de software. Uma alternativa possvel
para o leitor que desejar uma viso rpida das tcnicas de modelagem apresentadas
aqui ir diretamente para o captulo 6 e utilizar-se das referncias citadas neste
captulo para um aprofundamento nos itens de maior interesse nos captulos anteriores.
Se no decorrer da leitura houver dvida sobre algum termo tcnico empregado, o leitor
pode procurar uma explicao no glossrio de termos.

Com esta organizao possvel cobrir vrias possibilidades de abordagem da


orientao a objetos, desde uma abordagem mais formal, at uma abordagem mais
prtica e informal. Com um grande nmero de exemplos, procura-se sempre apresentar
as aplicaes tpicas dos conceitos apresentados. O leitor deve, entretanto, manter-se
atento limitao dos exemplos propostos e imaginar como utilizar estes conceitos em
seus prprios problemas e aplicaes.

1.3.

A importncia da modelagem

fcil observar que outras reas do conhecimento, as outras disciplinas de


engenharia, usam extensivamente da modelagem para representar seus projetos. A
figura clssica de um engenheiro civil algum envolvido com plantas e diagramas,
gerenciando uma construo. Uma planta de uma obra civil uma representao grfica
do produto final, o edifcio. A planta permite que o cliente avalie o produto e garanta
que o resultado final muito prximo do que ele deseja. A capacidade de
gerenciamento da indstria da construo civil, permite uma razovel preciso na data
de entrega das obras graas padronizao de processos de construo e a uma intensa
padronizao de componentes. Com exceo talvez apenas da alvenaria, uma
edificao composta de partes j construdas e que so integradas para formar o
produto final. Estas partes pr-fabricadas so os objetos da construo civil.
A engenharia mecnica, na indstria automobilstica por exemplo, uma indstria
com um alto nvel de automao, padronizao e especializao. Um carro fruto de
um projeto bsico que define os requisitos para os projetos de cada pea. Ele
movimenta uma grande mercado para as indstrias de auto-peas que criam,
isoladamente, os objetos individuais do carro. A construo do carro uma montagem,
uma integrao de objetos.
A engenharia de software procura trazer para a cincia da computao estas lies,
e incentivar a elaborao de um projeto de software, em um modelo orientado a
objetos. Visando a padronizao de componentes de software, o projeto e o processo
de desenvolvimento so desenvolvidos segundo a orientao de se criar objetos.
Projetar software nada mais do que construir um modelo do software. Um modelo
que representa, simplificadamente, o que se pretende construir, como uma planta de
uma residncia. Um modelo que mostra no s os requisitos do problema mas tambm
como eles sero atendidos pelos elementos da soluo. Um modelo que permita avaliar
a qualidade da soluo e simular o resultado final, de modo que projetista, cliente,
construtor tenham todos uma mesma viso do projeto.
O processso de desenvolvimento de software um processo composto no apenas
de componentes tecnolgicos. Uma componente importante, e decisiva para o sucesso
de um empreendimento, a componente social. A componente tecnolgica nos projetos
de software se encontra, principalmente, nas atividades de contruo do software. A
componente social est ligada ao relacionamento entre o usurio e o desenvolvedor, e
uma parcela importante da interao do usurio com o software. Pfleeger (1999) afirma
que o sucesso do software depende mais at do sucesso das interaes sociais do que

da aplicao da tecnologia. No se deve esquecer que software desenvolvido por


pessoas para ser utilizado por outras pessoas. A interao do software uma interao
entre pessoas, mediada pela tecnologia.
A qualidade de um software pode ser avaliada pela satisfao do cliente. O cliente
que se serve do software cria, ao estabelecer os requisitos de um software, uma
expectativa que s ver realizada quando o software estiver concludo. Ao
desenvolvedor cabe captar e atender estas expectativas com as possibilidades de
realizao. Para isso cliente deve contar, desde o incio com um modelo do software.
Este trabalho objetiva auxiliar os desenvolvedores na criao de modelos
orientados a objetos dos sistemas de software. A principal proposta valorizar a
atividade de criao do modelo para reduzir a incerteza do software, aproximar a
expectativa da realizao, facilitar a padronizao e a automao dos projetos,
incentivar a reutilizao dos componentes de software e aumentar a maturidade da
engenharia de software nas equipes de projeto.

2. Fundamentos da Modelagem
Orientada a Objetos
Este captulo descreve os conceitos fundamentais da modelagem orientada a
objetos por intermdio de um exemplo de aplicao. O exemplo mostra a herana, o
encapsulamento e a troca de mensagens entre os objetos sob um ponto de vista
prtico. Apresenta ainda as caractersticas principais do processo de
desenvolvimento de software, os fluxos de trabalho e a importncia da modelagem de
objetos presentes neste processo.

2.1.

Processo de Desenvolvimento de Software

O desenvolvimento de um software depende de muito trabalho disciplinado. Ter


uma boa idia para um software s no basta, ela deve vir acompanhada da organizao
e da disposio necessrias para realizar o trabalho de transform-la em um produto.
Um sistema de software resultado da unio da criatividade , da tecnologia e do
trabalho organizado. Um no funciona bem sem os demais. A tecnologia sozinha no
resolve os problemas, o esforo solitrio fica isolado se no for criativo. O que une a
tecnologia com a criatividade e direciona o trabalho uma idia comum, uma viso,
representada em um modelo. Estudando-se as etapas para transformar uma idia em um
produto de software, verifica-se a importncia em criar um modelo.
Os mtodos para desenvolvimento de software descrevem a organizao
necessria para se criar um software. Mtodos sugerem passos a serem seguidos para
cumprir o vazio existente entre a idia e o produto de software. Este estudo no
pretende desenvolver um novo mtodo, nem to pouco indicar um determinado mtodo
como sendo o mais adequado. Pretende sim destacar algumas propriedades presentes
em todos os mtodos, e observar que as tcnicas de modelagem esto no centro dos
mtodos, e do a sustentao necessria para a edificao do software.
Os mtodos so organizados em fases, que caracterizam as etapas de evoluo pelas
quais o software deve passar. Em cada fase uma srie de atividades so realizadas,
produzindo documentos, esquemas e diagramas que finalizam no cdigo do programa de
computador. Sobre cada um destes subprodutos do mtodo de desenvolvimento podem
ser realizados testes, para garantir que se est evoluindo na direo prevista, e com a
qualidade esperada.
Ao avaliar as etapas de um projeto de software, observa-se que elas no so muito
diferentes das etapas de qualquer outro projeto tpico de engenharia. Como todo projeto
de engenharia, o projeto de software tem como principal objetivo resolver um
problema. A soluo do problema ir trazer benefcios para os usurios do produto do
projeto, no caso, o software. A soluo do problema, no caso da engenharia de
software, o prprio sistema de software.
Identificar os objetivos e reconhecer os requisitos do problema so as atividades
realizadas na fase de anlise. Os requisitos variam de caso para caso, e dependem de
um bom entendimento da rea de conhecimento na qual ser desenvolvida o projeto, das
condies iniciais e das necessidades dos clientes. Pode-se dizer que a anlise serve
para se formular o problema que o sistema ir resolver. Conhecidos os requisitos e as
necessidades do cliente pode-se elaborar uma estratgia para resolver o problema, ou

fazer, o que se chama aqui, do design da soluo. Na fase de design so tomadas todas
as decises que envolvem a soluo do problema, e a partir dele inicia-se a
construo dos componentes da soluo. Este componentes podem ser novos ou
reutilizados de outros projetos, j testados e aprovados. Com os componentes da
soluo disponveis realiza-se a integrao que coloca todas as partes juntas para se
obter o produto final. interessante notar que esta descrio aplica-se igualmente
construo de umar edificao, um projeto de instalao eltrica ou um projeto
mecnico qualquer. Esta coincidncia sugere uma grande semelhana na organizao
das atividades de engenharia seja qual for a disciplina.
Um elemento importante e presente em todos os projetos de engenharia so as
plantas de engenharia. Todo projeto de engenharia realizado sobre uma planta, que
uma representao grfica minuciosa do que se pretende construir. Sobre a planta so
avaliadas possveis alternativas de soluo, tomadas as decises de projeto e a partir
dela so obtidas as orientaes para a construo do produto. A planta ,
essencialmente, um elemento de comunicao entre os participantes do projeto. A
planta representa o projeto de uma forma simplificada, um modelo do sistema final.
Os modelos so contrudos para ajudar a entender um problema e para comunicar
este entendimento a outros. A simplicidade, prpria dos modelos, permite apenas que
ele represente as informaes importantes, deixando de lado detalhes que dificultem a
compreenso do problema. Entendido o problema, o analista pode utilizar o modelo
para comunicar ao cliente o que entendeu e como pretende resolv-lo. O projetista
comunica, por um modelo, como devero ser construdos os componentes e como estes
sero integrados na soluo. Terminado o projeto, o modelo ainda ajuda a comunicar
aos responsveis pela operao e manuteno do sistema, os cuidados que devem ser
tomados ao se realizar uma modificao ou um reparo no sistema. Como uma
poderosa ferramenta de comunicao o modelo deve ser representado em uma
linguagem ao mesmo tempo precisa e clara, que comunique sem gerar dvidas de
interpretao. Este talvez o maior desafio da modelagem, e a principal razo deste
trabalho: como criar um modelo de software claro, preciso e ao mesmo tempo simples.
Outra propriedade importante dos modelos a de poder acompanhar a evoluo do
projeto. No incio, comum os modelos serem apenas linhas gerais e esboos. Em
alguns casos, nem os limites do problema esto ainda em definidos. Com um
entendimento melhor do problema, o modelo passa a agregar mais informao e a se
tornar-se uma viso mais completa de onde se pretende chegar. Um simples esboo
pode dar lugar a um diagrama mais preciso, a partir do qual vrias decises de projeto
podem ser tomadas. Concluda a etapa de design, o modelo contm todas as
informaes necessrias para se iniciar a construo da soluo, o modelo est agora

bastante detalhado e preciso. Finalmente, com o produto construdo e em operao


importante manter-se o modelo atualizado e vivo, refletindo nele as eventuais
alteraes feitas no produto quando ele sofre uma manuteno, ou so realizadas
expanses.
O modelo uma parte importante do projeto e deve evoluir com ele. Assim
possvel resumir as qualidades desejveis de um modelo como sendo a clareza, a
preciso, a simplicidade e a facilidade de evoluo. A figura mostra um esquema das
atividades em um projeto de desenvolvimento de software qualquer, e a correspondente
evoluo do modelo deste sistema.

Figura 3 - Esquema de um projeto de software


Com base neste esquema analisa-se a evoluo do modelo no projeto de sistemas,
as atividades realizadas para obt-los e os principais personagens envolvidos nestas
atividades. Estuda-se, inicialmente, os dois principais fluxos de atividades
representados neste esquema: o ciclo de desenvolvimento, representado pelas
atividades do lado do desenvolvedor, e o ciclo de teste do produto, representado pela
seta vertical esquerda, do lado do cliente.

2.1.1.

Ciclo de teste do software

O ciclo de teste do software um processo de responsabilidade do cliente, ou do


seu representante. Visa garantir que as necessidades levantadas para a definio dos
problemas estejam sendo atendidas pelo produto. No ciclo de teste o cliente verifica se
o produto fornecido pelo ciclo de desenvolvimento est de acordo com os requisitos de
projeto, e para isso ele realiza testes sobre o produto. Testes que colocam o produto em
situaes de uso normal, e procuram detectar falhas e novos requisitos no
identificados ainda. Como um sub-produto dos testes surgem correes e novas
necessidades, que devem ser incorporadas aos requisitos de uma nova verso deste
produto, dando incio a um novo ciclo de desenvolvimento.
Os clientes so todos os que contratam o servio de desenvolvimento do software,
porque esto interessados pelo resultado que o software ir dar ao seu negcio. Os
clientes podem ser os usurios finais, que iro usar o software, podem ser seus gerentes
que devem garantir a qualidade e a funcionalidade do software ou patrocinadores do
software que iro incentivar o desenvolvimento e arcar com seus custos
Gerente da aplicao o responsvel pela operao do sistema no ambiente do
usurio. Durante o desenvolvimento do projeto o gerente o lider dos usurios e
atua como facilitador dos relacionamento entre eles e a equipe de
desenvolvedores. Uma vez desenvolvido o sistema de software o gerente da
aplicao passa a responder por ele internamente organizao.
Usurio final quem se utilizar do sistema para auxili-lo em suas atividades.
Em problemas complexos os usurios podem variar de departamento, funo,
hierarquia na organizao. Nestes casos importante se criar um comisso de
usurios, representativa da comunidade, para orientar o desenvolvimento do
sistema.
Patrocinadores fazem parte do grupo de clientes que do apoio financeiro,
tcnico ou poltico ao desenvolvimento do sistema. Este apoio vital para que os
desenvolvedores possam ter acesso s informaes e possam executar, se
necessrio, as alteraes na organizao para a implantao do sistema.

2.1.2.

Ciclo de desenvolvimento do software

O ciclo de desenvolvimento do sistema um fluxo de trabalho cclico que gera


novos produtos a partir das informaes obtidas no levantamento de necessidades do
problema. dades cclico porque o produto de sada alimenta o ciclo seguinte, de
modo que a cada volta aproxima-se o produto das necessidades levantadas. Espera-se
que o ciclo seja convergente, isto , em um determinado estgio o produto atender
todos os requisitos e poder ser considerado terminado. Este ciclo realizado
inteiramento no lado do desenvolvedor, mas possui interaes com o lado cliente, no
ciclo de testes do produto.
O ciclo de desenvolvimento de um sistema caracterizado por 4 atividades
principais: anlise, design, construo de componentes e integrao. A seguir verificase o papel do modelos nas fases e os papel dos participantes de cada uma delas.

Fase de Anlise
A anlise a fase de levantamento dos requisitos do problema a ser resolvido. Nela
estabelecem-se os limites do problema, e identificam-se as necessidades do sistema.
Deve-se procurar limitar a anlise exclusivamente ao problema em estudo, evitando a
influncia de elementos que esto fora do escopo do problema. Detalhes de
implementao que podem ofuscar a definio do problema, falsos requisitos,
limitaes inexistentes devem ser deixadas de lado. Para ajudar o analista na busca de
uma maior clareza nas definies inciais, ele deve criar um modelo do problema. Este
modelo dever ter apenas as informaes relevantes para o entendimento do problema e
dever receber a aprovao por parte do cliente, garantindo que o caminho est correto
e servindo de base para as demais fases do projeto.
As tcnicas aplicveis anlise so muitas, e dependem, grandemente, da
experincia do analista. Quanto mais complexo o problema, mais difcil a anlise e
mais importante o uso de modelos para reduzir e gerenciar esta complexidade. Todas as
informaes obtidas do cliente devem ser avaliadas e levadas em considerao na
anlise. No existe um momento preciso que indica o final da anlise, mas o analista
pode identificar este momento quanto todas as facetas do problema foram exploradas e
a viso que o modelo traduz suficiente para iniciar as fases seguintes do projeto.
Mesmo que alguns requisitos foram esquecidos, no motivo de preocupao, como o
processo de desenvolvimento cclico sempre ser possvel rever a anlise e incluir
estes novos requisitos.

A anlise tarefa do analista de sistemas. Em projetos mais simples esta atividade


pode ser desempenhada por um desenvolvedor snior, ou pelo prprio gerente de
projeto, se estes possuirem um conhecimento bsico de modelagem de sistemas, e a
disponibilidade para entrevistar usurios, levantar e organizar as informaes
disponveis para o incio do projeto. Em projetos mais complexos esta tarefa pode ser
dividida entre diversos profissionais como o Analista de Negcios, o Analista de
Documentao e o Analista de Banco de Dados.
Analista de Negcios - deve ser um especialista na rea de conhecimento a que o
sistema se destina, e tem como objetivo identificar as responsabilidades que o
sistema deve cumprir para o negcio do cliente. O analista de negcios pode
desenvolver uma anlise do retorno esperado com o invetimento no sistema, e
estudar a viabilidade tcnica do sistema, integrando-o ao ambiente computacional
existente. Os requisitos de negcio, as regras e os processos de negcios devem
ser modelados por este profissional.
Analista de Banco de Dados - como uma grande parte dos sistemas de informao
so baseados na tecnologia de banco de dados, importante ter um entendimento
preciso das informaes j existentes em bancos de dados, antes de iniciar um
novo projeto. O analista pode se utilizar de tcnicas prprias e ferramentas de
software para criar os esquemas dos bancos de dados existentes e que sero teis
para o novo projeto de sistema.
Analista de Documentao - o responsvel por elaborar a documentao do
sistema, os documentos de especificao, manuais e diagramas. Como a fase de
anlise uma fase onde a gerao de documentos maior, importante ter-se um
profissional tcnico especializado encarregado da produo desta documentao.
Uma prtica interessante pode ser a de produzir o manual do usurio do sistema j
na fase de anlise, e utiliz-lo com parte da especificao tcnica de requisitos do
sistema.
Como parte importante da fase de anlise temos um modelo inicial do sistema que
far parte do documento de especificao, produto da fase de anlise. Porque as
correes nas fases iniciais de um projeto so sempre mais fceis de serem feitas, do
que em fases mais avanadas, os documentos e os modelos desta fase devem ser,
continuamente, avaliados e verificados pelos clientes.

Fase de Design
O design se concentra na soluo do problema identificado na fase de anlise.

Busca incorporar aos modelos, os elementos que formam um sistema para resolver o
problema de projeto. Como quase sempre a seleo de uma estratgia de soluo traz
compromissos com outros sistemas, deve-se, nesta fase, avaliar o melhor caminho,
testar e escolher a alternativa de soluo mais adequada. O designer conta com a sua
experincia e o apoio de modelos do sistema em projeto para apoiar sua deciso.
O design uma tarefa para engenheiros de software experientes. Em um projeto
mais complexo, diversos aspectos de um sistema de software devem ser considerados,
o que exige a participao de outros especialistas, como o Engenheiro de Redes e o
Designer de Interfaces.
Engenheiro de Software - o especialista em criar o operar os modelos dos
sistemas para lev-los ao cdigo. Deve possuir habilidade de conceber os
componentes do sistema e caracteriz-los de modo a que atendam os requisitos do
problema. Pode testar solues e se utilizar de padres de solues j consagradas
e aplic-las a novos problemas. O engenheiro de software deve garantir tambm
que as boas prticas de engenharia sejam respeitadas no projeto, assegurando a
qualidade do produto.
Engenheiro de Redes - um especialista importante quando o sistema ser
implementado em um ambiente de processamento distribudo. Neste caso, a
comunicao entre os componentes do sistema ser feita pela rede de comunicao
de dados, que deve ser projetada para dar vazo ao volume de comunicao
esperado. Existindo uma grande interao entre os componentes da soluo pode
exigir, em alguns casos, que componentes especiais de comunicao sejam
especificados e construdos.
Designer de Interfaces - um especialista na comunicao entre os usurios e o
computador. um profissional muito importante em sistemas com grande interao
com os usurios como os sistemas para internet. O aumento do nmero de
usurios nos sistemas de informao tem feito com que este profissional tenha um
papel cada vez mais importante para a aceitao e para a usabilidade do sistema.
Ele deve possuir a habilidade de e a criatividade para criar metforas para a
operao do sistema.
Ao final da fase de design todas as definies do projeto devem estar registradas no
documento de especificao. Modelos, listas e esquemas servem como referncias para
os construtores dos componentes e para a integrao do sistema. O modelo produzido
pelo design pode variar muito no nvel dos seus detalhes. No incio do projeto
apresenta poucos detalhes mostrando conceitualmente a soluo, para uma avaliao
inicial, ou para a validao de um cliente. Nos ciclos mais avanados do projeto, o
modelo deve estar muito bem detalhado para determinar aos programadores todos os

pormenores do software.

Fase de Construo doms Componentes


Na fase de construo de componentes inicia-se as atividades de programao na
construo do software. A boa prtica de construo recomenda a adoo do conceito
de componentes de software reutilizveis para reduzir prazos e custos no
desenvolvimento, mantendo a qualidadade do produto. cada vez mais comum se
dispor de componentes pr-fabricados prontos para serem utilizados em diversos
projetos, organizados em um framework. Nestes casos a construo de componentes se
limitar a criar os componentes que so especficos para o novo projeto.
A construo civil um exemplo tpico de padronizao de peas pr-fabricadas.
Poucas so as partes criadas especficamente para uma construo. Na rea mecnica o
exemplo mais interessante de criao de componentes encontra-se na indstria
automobilstica, onde um carro efetivamente a montagem de peas e partes completas
feitas por outras empresas,. Muitas vezes a mesma pea utilizada em diferentes
carros. Esta abordagem ainda nova na engenharia de software, mas est, aos poucos,
revolucionando o desenvolvimento de software.
A construo dos componentes um trabalho para o programador de
computadores, que o especialista nas linguagens de programao. Um mesmo sistema
pode possuir compontentes escritos em diferentes linguagens, no entanto, para facilitar
a manuteno e simplificar o sistema quanto menor o nmero de linguagens mais
facilmente o sistema ser mantido. O programador segue princpios e prticas prprias,
que no faro parte deste trabalho. Como uma grande parte dos sistema atuais se utiliza
de um banco de dados para armazenar as informaes e possui uma grande dose de
interao com os usurios, importante tambm envolver na fase da construo outros
especialistas: o programador de banco de dados, o programador de componentes e o
programador de interfaces.
Programador de interfaces o profissional responsvel por desenvolver os
componentes de interao entre o sistema e os seus usurios. Os componentes de
interface devem se caracterizar pela facilidade de uso e pela preciso na
comunicao. O uso de uma interface grfica e regras prprias para criar estes
componentes, projetador por um designer, exigem que um programador
especializado nesta tarefa seja convocado para realiz-la.
Programador de Componentes escreve os componentes de negcio obedecendo
as regras de negcio definidas pelo Analista de Negcios e projetadas pelo

Engenheiro de Software. Sua principal tarefa garantir a qualidade do


componente, sua eficfica e robustez. Utiliza, em geral, uma linguagem robusta em
um ambiente de desenvolvimento prprio.
Programador de Banco de Dados um profissional importante na fase de
construo se houver necessidade de criar componentes especficos para o
armazenamento e recuperao de informao. Em sistema orientados a objeto o
uso do banco de dados limitado e organizado pelos objetos, sendo que este
profissional deve ser responsvel por integrar os sistemas orientados a objeto com
os sistema legados em bancos de dados.
Analista de Teste. Como o produto final da fase de construo so os prprios
componentes. Cada componente prprio ou adquirido de ter terceiros deve ser
testado individualmente, para garantir que ele esteja de acordo com a
especificao do projeto. Este teste faz parte do processo de criao de
componentes mas no deve ser desprezado. Pode-se criar, em projetos maiores,
uma funo especfica com esta responsabilidade, garantindo a sua qualidade e
funcionalidade. O analista de testes no pode ter uma funo acumulada com a
funo de programador, para evitar um conflito de interesses.

Fase de Integrao
A fase de integrao encerra o processo de desenvolvimento gerando, como
produto final, uma nova verso do software. Nesta fase, a atividade mais importante a
de configurao da verso do software, compilando e instalando os componentes
necessrios nos equipamentos servidores. uma fase de trabalho minucioso e
organizado, onde se deve assegurar que todos os componentes necessrios foram
integrados. Aps este integrao importante realizar uma fase de teste. comum nesta
fase se criar roteiros automatizados de teste, assim como pode ser necessria alguma
atividade de programao para integrao final dos componentes.
As atividades de integrao podem, em sistemas mais simples, ser realizadas pelo
Engenheiro de Software ou pelo prprio Gerente de Projetos. Em sistemas mais
complexos comum encontrarmos o Gerente de integrao ou Gerente de
Configurao que ir coordenar uma equipe de profissionais, os Integradores que
respondero pela unio correta dos componentes.
Os modelos, na fase de integrao, servem de mapa para a configurao do sistema,
e unio dos componentes. Em muitos casos, no se est interessado em criar um sistema
totalmente novo, mas sim em adaptar um sistema existente para as necessidades

especficas de um cliente. Chama-se ao processo de adaptar um software especialmente


[1]

para as necessidades de um cliente de customizao . O processo de customizao


passa por todas as fases do processo de desenvolvimento, mas tem uma nfase maior na
fase de integrao, onde so realizadas a maior parte das atividades de configurao do
software.

2.2.

Modelos de um Software

O processo de desenvolvimento de um software apresentado baseado na evoluo


de uma viso que os desenvolvedores controem, em conjunto com os clientes, sobre o
problema a ser resolvido. Esta viso concretizada em modelos, que devem
representar esta viso e evoluir com ela. No incio, a viso incompleta e pode possuir
ambiqidades e distores, que ao longo do processo de desenvolvimento, com o
entendimento do problema, so eliminadas. No final, o modelo resultante equivalente
em significado ao cdigo gerado para implementar a soluo do problema, eles devem
ter igual riqueza de detalhes e preciso.
Em um problema complexo, dificilmente uma viso nica, completa e bem definida
ser obtida logo no incio do processo. importante que os compromissos do software
representados no modelo sejam assumidos aos poucos, acompanhando o entendimento
que se tem do problema. As tcnicas de modelagem, que sero exploradas em detalhes
nos prximos captulos, ajudam os analistas e designers a documentar e comunicar o
entendimento que adquirem do problema em diagramas de forma precisa, evitando a
construo de sistemas de software inconsistentes.
Um nico modelo apenas insuficiente para representar todos os fenmenos
existentes em um sistema complexo, so necessrios um conjunto coerente de modelos
com diferentes escalas, criados a partir de diferentes pontos de vista. Jacobson (1992)
prope que a complexidade seja introduzida gradualmente no modelo do sistema, com a
ajuda de uma srie de sucessivos modelos que aos poucos so capazes de gerenciar
essa complexidade. Ele prope 5 tipos diferentes de modelos:
modelo de requisitos, que captura requisitos funcionais do sistema,
modelo de anlise, que d ao sistema uma estrutura de objetos,
modelo de design, que refina esta estrutura para a implementao,
modelo de implementao, que efetivamente implementa o sistema,
modelo de teste que verifica o sistema.
Este estudo utiliza apenas trs modelos para representar os sistema de software:
modelo de contexto,
modelo conceitual e
modelo detalhado.
A idia central aqui tambm introduzir a complexidade aos poucos. O modelo de
contexto equivale ao modelo de requisitos de Jacobson, enquanto o modelo

conceitual se equivale ao modelo de anlise de Jacobson. O modelo detalhado pode ser


aplicado ao design, implementao ou ao teste do sistema, dependendo do nvel de
detalhes e da finalidade a que ele se destina; assim, substitui os 3 outros modelos
propostos por Jacobson.
O modelo de contexto inicia a definio do problema. construdo em uma
escala grande, onde grande parte dos detalhes do problema esto encobertos.
Representa os aspectos funcionais de alto nvel do sistema, analogamente ao modelo de
requisitos de Jacobson (1992). Serve para representar o sistema proposto no contexto
do negcio do cliente. Deve possuir uma representao simples, sem uma
formalidade excessiva, para poder ser entendido e validado pelo cliente, que
normalmente leigo em assuntos de software. No modelo de contexto define-se a
fronteira do problema e os principais objetivos que o sistema deve cumprir para os
seus usurios. Este modelo , essencialmente, desenvolvido durante a fase de
anlise pois refere-se, principalmente, uma viso do problema a ser resolvido. Deve
ser possvel ao modelo de contexto situar o sistema no contexto do cliente,
identificando pontos de integrao com outros sistemas j existentes e caracterizar a
contribuio do novo sistema.
O modelo conceitual um modelo que rene todos os conceitos presentes no
problema em estudo. Construdo com uma escala menor do que o modelo de contexto,
cria a estrutura do sistema, usando para isso um modelo simplificado de classes. Nele
devem estar representadas os principais componentes do sistema e suas relaes. No
modelo conceitual est caracterizada as proposta de soluo do problema, mas sem o
detalhe necessrio para a sua implementao. A idia central representar,
simplificadamente, em poucos diagramas, o sistema como um todo e as partes
principais que o constituem. Como o modelo final do sistema pode ser muito complexo,
o modelo conceitual serve de ndice, de orientao, para que dele sejam detalhados os
modelos de implementao. um modelo desenvolvido nas fases de anlise e design
porque recebe no s os detalhes do problema a ser resolvido, como tambm os
elementos incorporados ao modelo durante o design da soluo.
A quantidade de detalhes do modelo conceitual deve estar entre a abstrao do
modelo de contexto e a grande quantidade de detalhes do modelo detalhado. Como o
modelo conceitual possui um nvel maior de detalhamento que o modelo de contexto,
possvel, a partir dele estabelecer um planejamento do desenvolvimento e um
dimensionamento mais preciso dos recursos necessrios para a construo do sistema.
Estas definies so impossveis de serem feitas apenas com o modelo contextual,
assim o modelo conceitual assume tambm um importante papel no gerenciamento do
processo de desenvolvimento de software.

O modelo detalhado, por sua vez, incorpora todos os detalhes de uma verso
projetada do software. O modelo detalhado pode possuir um nvel de detalhe
equivalente ao cdigo do software, podendo-se at criar uma correspondncia
biunvoca com ele. Para cada verso de um software o modelo detalhado pode mudar,
incorporando as novidades desta verso. Podem ser gerados quandos modelos
detalhados quantas verses do produto existirem. O objetivo principal do modelo
detalhado a construo do sistema, assim nele devem estar representados todos os
detalhes construtivos e as definies de projeto. um modelo que se inicia na fase de
design, com os detalhes com componentes a serem construdos e detalhado na fase de
construo. Como o modelo detalhado possui uma escala ainda menor que o modelo
conceitual, os detalhes do sistemas so revelados com preciso, na medida da
necessidade do desenvolvimento, seja para uma maior definio precisa do design, seja
para implementao ou seja para testes.
A figura abaixo mostra, de forma esquemtica, as relaes entre a escala proposta
de modelos e os produtos de software em suas diversas verses.

Figura 4 - Seqncia de Modelos em um Projeto de Software Tpico

2.3.

Documento de Especificao de Projeto

O principal documento do desenvolvimento do software o Documento de


Especificao de Projeto. Como seu prprio nome diz, ele deve descreve,
detalhadamente, o projeto de um software. Normalmente, a especificao tomada
como um documento feito para orientar a construo do software, mas neste estudo a
especificao tomada como um espelho do projeto do sistema, e assim deve ser
mantida atualizada durante toda a evoluo do sistema, inclusive aps a sua construo.
Na fase de anlise a especificao deve considerar os objetivos do problema,
apresentando os modelos de contexto e conceitual. Na fase de design a especificao
recebe os detalhes das solues escolhidas, para que na construo todas as alteraes
no sistema possam ser representadas em modelos detalhados na especificao.
Mantm-se assim o documento vivo, acompanhando todo o projeto do sistema.
Como este trabalho no se prope a apresentar um mtodo para desenvolvimento de
um software, o documento de especificao no ser detalhado. Entretanto, de
esperar, encontrar muitos diagramas e modelos em um documento de especificao de
software.

2.4.

A Modelagem Orientada a Objetos

Para criar um modelo preciso escolher o que considerado importante, e por isso
ser representado no modelo, do que pode ser omitido. A seleo do que , e do que
no , importante segue um paradigma, um ponto de vista, uma forma de olhar a
realidade que se vai modelar. Descreve-se aqui algumas caractersticas dos diferentes
paradigmas usados para modelar sistemas de software.
Para desenvolver um sistema de software necessrio criar uma viso do problema,
representada em um modelo que orienta o processo de desenvolvimento. Para se
estabelecer esta viso deve-se definir um ponto de vista, isto , deve-se a olhar o
software segundo um paradigma. O paradigma define uma unidade de decomposio do
sistema, destacando alguns aspectos em prejuzo de outros. Algumas possveis vises e
as unidades de decomposio associadas so:
A Viso Funcional decompe um sistema em funes;
A Viso dos Dados decompe um sistema em estruturas de dados; e
A Viso de Objetos decompe um sistema em classes de objetos.
A viso funcional valoriza o fluxo de informao do sistema, buscando responder o
que o sistema deve fazer. A idia, que se traduz em uma anlise funcional, a de definir
o sistema como uma grande funo, que pode ser quebrada em funes menores, em
uma tcnica de anlise chamada de anlise top-down (de cima para baixo). Este
procedimento parte do princpio que um sistema de software deve fazer algo para o seu
usurio. Uma funo complexa pode ser decomposta em funes mais simples,
continuamente, at que a quebra funcional leva a funes to simples a ponto de
poderem ser implementadas e testadas. Testadas isoladamente, as funes elementares
so agrupadas e integradas em uma estratgia de integrao botton-up (de baixo para
cima). Integrando todas as funcionalidades tem-se, ao final, o sistema completo com
toda a funcionalidade pretendida.
O termo funo quem orienta todo o processo de desenvolvimento. O que o
sistema deve fazer conduz o processo de anlise e construo. Por isso, se for
necessrio introduzir alteraes, modificaes e novas funcionalidades nos softwares
desenvolvidos sobre este paradigma a tarefa mais difcil. Ao se introduzir uma
altero, uma srie de outras funcionalidades que decorreram desta podem ser afetada.
A quantidade de cdigo envolvido pode ser muito grande, inviabilizando grandes
mudanas em sistemas desenvolvidos sob uma viso exclusivamente funcional.

Figura 5 - Esquema da Modelagem Funcional


Na modelagem de dados, outro paradigma possvel no desenvolvimento de
software, o destaque se volta para a estrutura da informao que tratada pelo sistema,
ao contrrio das operaes ou funes s quais estas informaes estaro sujeitas. A
estrutura da informao de um sistema corresponde ao conjunto organizado de
entidades que guardam alguma informao para o software e como elas se relacionam.
O princpio por trs da modelagem de dados que um sistema de informao processa
informao. D-se uma maior em qual informao processada e no em como se d
este processamento.
Na modelagem de dados no h lugar para representar as caractersticas dinmicas
do problema, suas funes, operaes ou algortmos. Ainda que algumas regras de
negcio reflitam apenas em elementos estticos ou limites destes elementos, a maioria
das regras de negcio exige a criao de algortmos mais complexos que no encontram
abrigo no modelo de dados. Existe, entretanto, na modelagem de dados uma grande
reutilizao das informaes armazenadas e da sua estrutura. A capacidade em se
adaptar uma mesma estrutura de dados em problemas semelhantes muito grande,
dando amplas possibilidades de uma grande reutilizao deste tipo de modelo.
Problemas semelhantes usam estruturas de informao semelhantes.
importante se observar que nem sempre a estrutura da informao reflete a
estrutura do problema. Algumas vezes redundncias e hierarquias presentes no
problema so eliminadas ao se analisar apenas a informao armazenada. O processo
de normalizao de tabelas de um banco de dados um exemplo desta simplificao.
Outra observao importante que um sistema exige dados e funes, e que nem
sempre uma abordagem permite uma viso se integra perfeitamento na outra.
Desenvolver um sistema pelo paradigma de dados ou pelo paradigma funcional resulta

em um sistema com grande acoplamento, onde qualquer modificao necessria, seja


em dados, seja em funes pode resultar em um trabalho complexo demais. A figura
mostra que um dado pode ser necessrio para mais de uma funo e que que modificar
um dado requer modificar muitas funes.

Figura 6 - Um programa combina dados e funes


A orientao a objetos enfoca a busca da estrutura do problema, e no apenas da
informao. Identifica em objetos, os elementos importantes do domnio do problema,
que guardam dados e possuem funes que podem operar seus dados. No so apenas
as funes que o sistema deve desempenhar, como na modelagem funcional, nem
somente os dados que sero armazendados, como na modelagem de dados; a
importncia maior encontrar os elementos do problema que possuem todas estas
propriedades.
Sebesta (1996) estuda a evoluo das linguagens de programao e verifica que
enquanto a programao procedural foi desenvolvida na dcada de 70, na dcada de 80
comeou-se a combinao de algoritmos e estruturas de dados em objetos com a
linguagem Smalltalk. As idias da programao orientada a objetos foram incorporadas
linguagem C gerando C++ que ajudou a popularizar as linguagens orientadas a objeto.
Apesar de ser possvel haver programao orientada a objetos desde 1980, os
conceitos que envolvem o projeto de sistema com esta filosofia no so simples, e por
isso demoraram a ser utilizados pela comunidade de desenvolvedores. Os programas
continuavam, at meados da dcada de 90, a serem projetados com uma separao clara
entre a anlise funcional e a anlise de dados. Num sistema onde qualquer funo
pudesse se utilizar de qualquer dado armazenado, seria impossvel saber quais dados
so necessrios para cada funo, sem analisar cada uma das funes separadamente.
Esta grande dependncia entre os dados e as funes dificulta uma alterao nos dados

ou nas funes, porque as conseqncias so imprevisveis. importante criar um


critrio para se unir dados e funes em conjuntos organizados e coerentes. Desta idia
surge a modelagem orientada a objetos.
Um objeto, segundo Jacobson et al (1992), caracterizado por um conjunto de
operaes e um estado que armazena os efeitos das operaes que o objeto capaz de
realizar. Assim os dados armazenados no estado objeto servem para armazenar o efeito
das funes, criando-se o vnculo desejado entre as operaes e os dados. Os objetos
tem uma dimenso maior do que apenas os dados e as funes isoladamente, como
exemplifica a figura.

Figura 7 - Objetos renem dados e funes


A orientao a objetos parte da constatao que o mundo formado por elementos
autnomos e relativamente independentes, e que criar um modelo de um sistema de
software identificar quais destes elementos so relevantes para o software. Os
objetos que devem ser includos no modelo so os que realizam algo de destaque para o
problema em questo. Esta abordagem reduz a distncia entre o modelo e o mundo real,
porque utiliza elementos da realidade para criar o modelo, facilitanto o entendimento
do problema pelo analista e pelo cliente.
Selecionar a orientao a objetos para analisar um problema, inclui uma srie de
caractersticas intrnsicas tecnologia de objetos que devem ser bem entendidas para
que o analista possa fazer um uso correto deste paradigma. Dentre estas caractersticas
destacam-se o conceito de encapsulamento das classes, a herana, a troca de mensagens
e o polimorfismo. Estas caractersticas sero apresentadas a seguir, acompanhadas de
exemplos prticos que visam a facilitar o entendimento.

2.4.1.

Encapsulamento

Todos os dados e operaes necessrias para um objeto existir, e realizar suas


responsabilidades para o sistema, devem estar armazenadas no prprio objeto. Diz-se
que o comportamento e os dados esto encapsulados no objeto. Envoltos em uma
cpsula os dados dos objetos no esto mais isolados das funes, eles caminham
juntos.

Figura 8 - Esquema do encapsulamento


O encapsulamento a principal caracterstica para se identificar um objeto. O
princpio por trs desta idia que o objeto possua todos os dados e as funes
necessrias para sua existncia. Selecionar um objeto da realidade para o modelo
indica que ele representa algo que existe de fato no domnio do problema, e que ser
transportado para o domnio do modelo do software, com toda a sua autonomia.

Figura 9 - Um objeto deve representar algo que existe de verdade


Um lmpada, como a da figura, um objeto importante, por exemplo, para um
sistema de controle domstico. As propriedades que a lmpada possui, para este
sistema so uma tenso eltrica e um preo. A lmpada oferece para este sistema as
funcionalidades de acender a um determinado preo pelo qual foi comprada.

O encapsulamento protege os dados de um objeto do acesso descontrolado por


outros objetos. O acesso realizado por intermdio de mensagens trocadas entre
objetos, que nada mais so do que chamadas das funes do objeto. Apenas a interface
do objeto, formada pelo conjunto de funes, exposta, oferecendo servios deste
objeto ao mundo exterior. Como as mensagens passam por uma funo do objeto antes
de acessar os dados, esse acesso controlado e o dado protegido. As informaes do
objeto e como ele implementa estes servios so mantidos ocultos. A este conceito
chamamos de ocultamento de informaes, e outra decorrncia importante do
encapsulamento de objetos.
O encapsulamento dos objetos encontra analogia em diversas situaes da vida
diria. Um exemplo de sucesso de encapsulamento presente em nossas casas o caso
do aparelho de TV e do aparelho de reproduo de DVD. Vamos observar que as
funes da TV e da unidade de DVD so muito bem definidas: o aparelho de TV possui
como funo apresentar imagens, enquanto o a unidade de DVD reproduz imagens
armazenadas no formato padro do DVD. Eles se complementam para servir o seu
usurio, e ao mesmo tempo se mantm independentes.

Figura 10 - Exemplos reais de encapsulamento


Alm das funes especficas, os aparelhos possuem uma interface bem definida e
padronizada que permite que sejam operados sem a necessidade de se conhecer o
funcionamento interno dos aparelhos. Assim como nos objetos, estes aparelhos
protegem os componentes e suas informaes de um uso indevido, expondo apenas uma
interface externa.
O encapsulamento implica em outra caracterstica prpia da orientao a objetos,
que a colaborao entre os objetos pela troca de mensagens. A integrao dos
componentes ocorre interligando a sada de um objeto com a entrada do outro, de modo
que um objeto possa acionar uma funo do outro objeto. De modo anlogo, o DVD se
comunica com a TV para utilizar a funo de exibio de imagens. O aparelho de DVD

pede TV que apresente as imagens, e para isso ele envia pela interface externa de
comunicao , a mensagem com a imagem a ser apresentada. A operao em separado
dos aparelhos confivel e segura, o que leva a uma confiabilidade e segurana da
operao em conjunto.
O encapsulamento leva reutilizao, outro grande benefcio da orientao a
objetos. Com ela possvel separar a criao de objetos, da integrao destes objetos
em sistemas. A reutilizao uma das conseqncias mais procuradas no projeto
orientado a objeto, pois dela decorre uma reduo no custo do desenvolvimento de
novos sistemas e uma maior facilidade de manuteno e expanso. Um objeto bem
projetado, testado e confivel pode ser utilizado em diversas situaes, diluindo o seu
custo entre vrias aplicaes. A manuteno simplificada e a expanso pode ser
realizada de forma mais controlada. Usando ainda o exemplo da TV e do DVD deve-se
observar que a TV pode ser utilizada como um objeto para apresentao de imagens em
diversos sistemas de multimdia, assim como quando um aparelho de vdeo cassete
pode ser substituido, quase sempre, por um aparelho de DVD, mais moderno, sem
necessariamente alterar o aparelho de TV.

Figura 11 - Exemplo de interface padronizada


A figura mostra uma interface padronizada para a operao da maioria dos
aparelhos eletrnicos de reproduo de som e imagem. O uso repetido permite que seja
qualquer for a implementao interna, o usurio saber o que ir acontecer se escolher
a seta (reproduzir) ou o quadrado (interromper).
O que caracteriza um encapsulamento eficiente a definio precisa da interface. A
interface a a lista dos servios que o objeto oferece, ela esconde como o objeto as
implementa. Muitas interfaces j esto padronziadas e h um grande esforo geral de
padronizao para tornar o acesso aos servios de objetos mais fcil e simplificado.
Existem boas perspectivas para a modelagem orientada a objetos nos servios de
objetos distribuidos. Diversos servios comuns a muitos sistemas podem ser oferecidos
aos objetos desde eles atendam a uma interface padronizada, como o padro
CORBA ou o padro EJB. (Orfali, 1998).

2.4.2.

Mensagens

A comunicao entre os objetos se d por meio de mensagens. Um objeto que


desejar uma informao de outros objetos deve solicitar s funes destes objetos, na
forma de mensagens, que responda ao seu pedido. Como um sistema formado por um
conjunto de objetos, o processamento do sistemas obtido mediante a troca de
mensagens entre os objetos.
Uma mensagem a chamada de uma funo de um objeto, o acionamento de uma
operao encapsulada no objeto de destino, feita a partir do objeto de origem. A
informao transmitida passada ao objetos de destino pelos parmetros da funo,
enquanto a resposta da mensagem obtida pelo parmetro de retorno da funo. Assim,
por definio, toda mensagem tem uma resposta de retorno e pode transmitir uma
informao na chamada e no retorno.
Para que os objetos se comuniquem necessrio que haja algum tipo de
vnculo integrando estes objetos. Estes vnculos, que podem ser relacionamentos
existentes entre os objetos, asseguram um conhecimento que um objeto tem da
existncia do outro.

Figura 12 - Troca de mensagens entre objetos


Retomando o exemplo o DVD, nota-se que ele se comunica com a TV por
intermdio da funo de exibir imagens que a TV possui. Esta funo est disponvel na

interface da TV, o que permite que outros aparelhos possam servir a TV com imagens.
Outra forma interessante de comunicao existente entre estes objetos a comunicao
existente entre os equipamentos eletrnicos e o controle remoto. O controle remoto
recebe os comando do usurio e os transmite para a TV como mensagens. Esta
comunicao facilitada porque as interfaces entre o controle e a TV, e entre a TV e o
DVD so padronizadas.
O que permite esta forma de comunicao entre os objetos a definio de uma
interface precisa. Assim, como o encapsulamento isola as estruturas internas do objeto,
ele deve expor uma interface que permita que o objeto receba mensagens de outros,
formando o sistema. Vale observar que a comunicao entre os objetos bastante
restrita, as mensagens recebidas por um objeto se limitam s operaes expostas na
interface. Caso o sistema exija que uma nova mensagem seja enviada, necessrio criar
uma funo especfica para receber esta mensagem no objeto de destino. A definio
das interfaces e das mensagens a serem implementadas nos objetos uma importante
atividade de modelagem do sistema, desempenhada durante a fase de design no projeto
de um software.

Figura 13 - Exemplo da comunicao entre objetos

2.4.3.

Tipos, Classes e Objetos

Aplicando o encapsulamento em larga escala, observa-se que existem grupos de


objetos compartilham a mesma interface, isto , apesar se serem objetos distintos,
oferecem os mesmos servios para o sistema. Estes objetos seguem a mesma estrutura e
definem o que chama-se de um tipo abstrato de dados. Um tipo uma estrutura de dados
com um conjunto de definies de operaes que afetam esta estrutura. No tipo no
existe a preocupao de implementar estas operaes, ele serve apenas para se definir
um padro no modelo, reduzindo a complexidade da modelagem.
A implementao de um tipo uma classe. A classe possui, alm das definies, a
implementao das operaes, para criar um componente autnomo para o sistema. A
classe um molde para a criao de objetos, porque permite descrever um conjunto de
objetos que compartilha a mesma estrutura de dados e as mesmas definies operaes.
Todos os objetos de uma classe possuem as mesmas definies mas podem possuir
valores diferentes nos dados, respondendo de modo diferente s mensagens enviadas
ele.

Figura 14 - Exemplos de Classes e Objetos


Um objeto uma instncia de uma classe, ele realiza a classe para o sistema. A
estrutura do objetos definida pela classe, mas as operaes e estados so definidos na
instncia (Jacobson, 1992). No mundo real os objetos existem e trocam mensagens. a
partir destes objetos que se abstrai as classes para o modelo, porque no modelo se est
interessado nas estruturas dos objetos. O processo de classificao dos objetos, isto ,
determinar a classe a que o objeto deva pertencer, a essncia da modelagem orientada
a objetos.
Em um exemplo tpico de uma instalao de engenharia possvel classificar os
equipamentos como equipamentos eltricos e equipamentos hidrulicos. A figura
abaixo mostra esta classificao na forma de conjuntos . As classes esto associadas
aos conjuntos,e os objetos aos seus elementoss destes conjuntos, que compartilham as
mesmas propriedades. Pertencer ao conjunto equivale dizer que o elemento compartilha

algumas caractersticas. Podem existir equipamentos que possuem caractersticas de


mais de um conjunto.

Figura 15 - Subclasses da classe Reprodutor de Imagens


O exemplo pode mostrar a classificao no nica e pode estar sujeita a mltiplas
interpretaes, dependendo do enfoque que se queira dar ao problema. O importante
verificar em cada classe quais as propriedades que esto sendo compartilhadas pelos
seus elementos, para haver uma boa relao entre o modelo e a realidade.

Figura 16 - Classes se assemelham a conjutos de objetos

2.4.4.

Herana

A herana uma das principais caractersticas da orientao a objetos, e que est


intimamente associada ao conceito de agrupamento dos objetos segundo um conjunto de
propriedades comuns. Uma classe de um objeto o agrupamento de objetos que
compartilham a mesma estrutura de dados e funes. possvel se encontrar grupos que
possuam um conjunto de propriedades, e que a partir deste grupo seja possvel criar
outros grupos que possuam propriedades ainda mais especficas, formando assim um
subconjunto do anterior. A orientao a objetos permite criar uma relao entre as
classes de objetos de modo que classe pode ser gerada a partir de outra classe,
herdando dela suas propriedades estticas (atributos) e dinmicas (funes).
A herana permite ainda que as caractersticas herdadas da classe me possam ser
alteradas e expandidas pela classe filha. Incluindo novas caractersticas, ou
modificando caractersticas existentes. Esta capacidade dos modelos orientados a
objetos permite que a modelagem seja feita em camadas de classes, criando uma rvore
para cada classe, com um nvel decrescente de abstrao, quando se caminha da me
para a filha.
O uso da herana permite criar classes mais genricas, com funcionalidades gerais e
que podem ser herdadas por vrias classes em diferentes situaes simplificando a
modelagem e implementao. A herana de classes aumenta muito a capacidade de
reutilizao das classes, porque pode-se criar classes genricas com propriedades
gerais e que podem ser utilizadas em diversas situaes. O reuso de classes apresenta
um efeito positivo no prazo e no custo do desenvolvimento de projetos de software.

Figura 17 - Exemplo real de herana


No exemplo, a herana utilizada para distribuir os equipamentos em categorias.

Observa-se que, inicialmente, todos so equipamentos. Os equipamentos podem ser


para casa, podem ser eltricos e podem ser mecnicos. Alguns equipamentos para casa
so tambm eltricos, criando a classificao dos eletrodomsticos.
O conceito de herana e de objetos em software no novo, mas foi pouco utilizado
nos projetos de sistema at que as linguagens de programao que permitissem
implementar em software estes conceitos com facilidade. Hoje existem vrias
linguagens orientada a objetos que permitem incorporar herana e encapsulamento nos
sistema de software.

2.4.5.

Polimorfismo

Uma decorrncia interessante da comunicao por mensagens e da herana a


orientao a objetos o polimorfismo. Define-se polimorfismo como a propriedade
que o emissor de uma mensagem no precisa conhecer a instncia da classe que recebe
esta mensagem. (Jacobson, et al, 1992). Esta propriedade leva ao fato de que uma
mesma mensagem pode ser interpretada de modos diferentes, quando for recebida por
objetos diferentes. Assim, como as implementaes das funes que recebem a
mensagem so diferentes elas podem responder de forma diferente (poli = mltiplas,
morfo="forma"). Polimorfismo a propriedade de que a mesma mensagem pode ser
respondida de forma diferente por duas ou mais classes.
H alguma confuso entre o encapsulamento e o polimorfismo porque ambos se
referem ao ocultamento da implementao do mundo externo ao objeto. No entanto, o
polimorfismo est centrado na possibilidade de uma resposta diferente devido ao
desconhecimento do destinatrio da mensagem, enquanto no encapsulamento a
implementao est apenas oculta do mundo exterior.

Figura 18 - Polimorfismo: a mesma mensagem tem respostas diferentes

2.4.6.

Vantagens da Orientao a Objetos

Ao escolher desenvolver um software pelo paradigma de objetos, o


desenvolvedor procura obter uma srie de vantagens, decorrentes das
caractersticas desta abordagem:
O uso de objetos na modelagem torna mais fcil descrever as estruturas e o
comportamento existente no mundo real. Essa proximidade faz com que os clientes
possam se identificar mais diretamente com os problemas nos modelos.
O encapsulamento do conhecimento em componentes isola o comportamento, o que
permite que as mudanas nos requisitos possam tambm serem isoladas em cada
componente sem afetar o sistema como um todo.
O uso de classes e objetos facilita a integrao das fases do processo de
desenvolvimento, porque ao contrario de outros modelos onde cada fase possui
tcnicas e paradigmas prprios, na orienta a objetos o mesmo paradigma
conduzido da anlise construo.
O encapsulamento favorece o teste dos sistemas de software, que pode ser isolado
para cada componente. O resultado um aumento na qualidade do sistema.
O encapsulamento permite ainda que os componentes possam ser desenvolvido
por fornecedores diferentes,
A reutilizao, decorrente do encapsulamento, reduz custos e prazos no
desenvolvimento de software porque possibilita que o mesmo componente seja
usado em vrios projetos,
A herana associada ao encapsulamento permite abordar problemas mais
complexos do que com outras abordagems de desenvolvimento. A herana cria
uma famlia de objetos com uma complexidade crescente e que podem ser
aplicados em vrios problemas diferentes.
Algumas das vantagens da orientao a objetos podem ser compravadas na prtica
com o estudo de caso que se segue.

2.5.

Estudo de Caso: Automao de Vendas

Para melhor entender os conceitos da tecnologia de objetos, segue um exemplo da


aplicao desta tecnologia. O objetivo destacar, didaticamente, as caractersticas da
orientao a objetos em um sistema que reproduz uma automao de vendas. No se
pretende resolver o problema de automao comercial, mas utilizar como exemplo o
problema do sistema de informaes para apoio s vendas em uma loja. Como um
sistema de informao gerencial, ele deve atender as regras do negcio e,
simultaneamente, ser flexvel para acomodar as mudanas destas regras, resultado
natural da evoluo do negcio. A adoo do paradigma de objetos ajuda a obter esta
flexibilidade, conseguida pelo uso correto das caractersticas desta tecnologia como:
encapsulamento, as mensagens, a herana e o polimorfismo, que sero demonstradas a
seguir.
Este estudo de caso tambm serve para exemplificar a abrangncia e aplicabilidade
dos modelos em um sistema prtico. Inicia-se formulando o problema por meio de uma
viso do contexto onde este sistema se encontra. Segue-se construindo um modelo
conceitual do sistema, que define as principais classes do sistema e suas relaes. Das
definies preliminares passa-se para um detalhamento que se traduz na implementao
do sistema. O escopo do exemplo limitado ao entendimento dos princpios da
orientao a objetos, sem descer em detalhes excessivos dos cdigos e das opes de
implementao, que podem ser encontrados no captulo 6, no final do livro.

2.5.1.

Contexto do Problema

O estudo de caso ocorre com uma loja de departamentos e o seu processo de venda.
Um cliente escolhe os produtos que deseja comprar. Ele se encaminha a um caixa que
deve finalizar a venda. Em geral, o caixa possui um terminal com um leitor de cdigo
de barras que obtm, com base em um cdigo, o preo dos produtos. Alguns produtos
podem ter descontos para pagamento a vista, ou parcelamento em 2 ou 3 vezes, com ou
sem juros. Este estudo se interessa pelas etapas de determinao do preo e das
condies de pagamento do produto. Deseja-se um sistema de informao que dado o
cdigo do produto informe o preo e as condies de pagamento deste produto. As
condies de pagamento sero definidas em funo do crdito que o cliente tem com a
loja em uma regra de negcio pr-estabelecida. Segue-se a arquitetura do sistema e as
regras de negcio:

Arquitetura do Sistema
O sistema processado em uma rede de postos de venda, tambm conhecidos como
POS (do ingls: point of sale). Eles fazem a interface entre o caixa, funcionrio da loja,
e um computador central que processa as requisies do processo de venda. A figura
abaixo descreve esta arquitetura:

Figura 19 - Esquema da Arquitetura do Sistema da Loja


O computador central armazena os dados dos produtos, dos clientes e do histrico
das vendas em um banco de dados. As regras do negcio tambm so processadas no
computador central. Os POS implementam uma camada de apresentao e comunicao
com o caixa, e fazem as requisies ao computador central. Existe um pequeno poder
de processamento local nos POS que pode ser utilizado, dependendo da aplicao e da
estratgia de desenvolvimento escolhida.

Regras de negcio
O processo de venda proposto para esta loja resume-se a trs aes, executadas
pelo caixa, por meio do POS:
1. Identificar o produto pelo seu cdigo,
[2]

2. Identificar o crdito do cliente e seus dados pessoais pelo seu CGC , e


3. Informando o nmero de parcelas, verificar se a venda parcelada foi aprovada.
A principal regra de negcio neste sistema est na aprovao do crdito nas vendas
prazo. Por uma norma estabelecida pela administrao da loja, todo cliente tem um
crdito gerenciado pela loja e que pode ser elevado pelo gerente, conforme as novas
compras do cliente na loja. No entanto, o cliente no pode financiar compras acima do
seu crdito. Se o saldo de uma compra parcelada for superior ao crdito do cliente, a
venda no aprovada.
Por exemplo, se um cliente possui um crdito de R$1.200,00 e deseja comprar um
produto de R$ 2.100,00 ele pode comprar vista porque no fica com saldo devedor.
Pode tambm parcelar em duas vezes de R$1.050,00 porque o saldo devedor ser de
R$1.050,00 e inferior ao seu crdito de R$1.200,00. No entanto, se ele quiser parcelar
em 3 vezes iguais de R$700,00 ter um saldo de R$1400,00 superior ao seu crdito, e
no conseguir aprovar a venda.
Esta regra pode ser expressa pelo pseudocdigo abaixo, para uma venda de n
parcelas, onde:
saldo - valor que resta a pagar aps a entrada
preco - preo do produto vista
n
- nmero de parcelas da venda
credito - limite de crdito do cliente com a loja
saldo = (n-1)*preco
se (saldo<=credito)
ento vendaAprovada
seno vendaNoAprovada

Para incentivar a venda para alguns clientes especiais identificados como


ClientesVIP a loja d um crdito dobrado para estes clientes, de modo que os clientes
considerados VIP podem fazer dvidas com a loja duas vezes superiores ao valor do
crdito, se no fossem VIP.
possvel que alguns produtos tenham, em poca de promoes e descontos,
condies especiais de venda a serem definidos posteriormente. Por exemplo, uma
promoo pode permitir a venda de determinados produtos, em at 3 parcelas
independente do crdito do cliente. O sistema a ser desenvolvido para automatizar a
loja deve ser flexvel para acomodar estas modificaes e outras novas regras de
negcio no futuro.

2.5.2.

Modelo Conceitual

Estabelecendo-se este contexto e seus requisitos, possvel definir um sistema para


atend-los, partindo dos principais conceitos deste problema. No modelo conceitual j
so percebidas as caractersticas da orientao a objetos, onde o primeiro passo
identificar as classes presentes no sistema. Analisando a descrio do contexto do
sistema, observa-se que o processo de venda ocorre entre os seguintes personagens:
O Cliente, que pode ser VIP ou no e possui o crdito;
O Caixa que processa os pedidos como usurio final;
O POS que define a interface com o sistema;
A Loja onde esto aramazenadas as regras e informaes e
O Produto que possui o preo e as ofertas.
Com estes personagens, possvel se definir o processo de venda, sob o ponto de
vista da orientao a objetos, caracterizando as mensagens que os objetos trocam entre
si. Sob este ponto de vista, o processo de venda ocorre em 3 fases, a saber:

Fase 1 - Identificao do Produto


Para identificar o produto pelo seu cdigo, o caixa inicialmente l o cdigo no
produto e pergunta para a loja: Qual o produto com o cdigo xxxxx? . A pergunta
dirigida para a loja porque a loja responsvel por manter uma lista de seus produtos.
A loja ento, procura nesta lista o produto desejado e o retorna ao caixa com as
informaes sobre este cdigo. O caixa pode ento, se quiser, descobrir o nome e o
preo do produto.

Fase 2 - Identificao do Cliente


Analogamente ao produto, o caixa pode pegar o nmero do CGC do cliente, e
perguntar para a a loja, quem o cliente que possui o CGC yyyyyy? A resposta da loja,
caso o cliente esiver presente na lista de clientes da loja, ser o prprio cadastro do
cliente, que retorna ao POS. Neste cadastro o caixa pode verificar os dados do cliente
como nome, o crdito que este cliente possui, entre outras informaes.

Fase 3 - Autorizao do Crdito, para vendas Prazo

O caixa, representado pelo POS, possui, aps as consultas anteriores, um produto e


um cliente. Sabendo que o cliente deseja fazer a compra em n parcelas, algum elemento
do sistema deve informar se esta venda pode ser realizada ou no. No exemplo, a venda
ser realizada se a dvida do cliente, na compra parcelada, for menor do que o crdito
que o cliente possui com a loja, como manda a regra de negcio. Algum componente da
loja precisa ser responsvel por testar esta regra de negcio. Tomando uma deciso de
projeto, optou-se em atribuir esta responsabildade para o produto. Assim, para saber se
a venda pode ser realizada o caixa pergunta para o produto: Voc produto, pode ser
vendido para este cliente por n parcelas? O produto, conhecedor da regra de negcios,
responde com um sim ou no e termina esta etapa do processo de venda.
Estas trs aes podem se decompostas na forma de mensagens trocadas entre os
componentes principais do negcio: caixa/POS, produto e cliente e loja. Imaginemos
estes componentes como personagens de um mundo fictcio, onde o processamento do
sistema realizado com uma coleo de perguntas e respostas entre estes componentes,
esquematizada na figura abaixo:

Figura 20 - Comunicao entre os Componentes da Loja


Neste modelo conceitual pode-se analisar as caractersticas de encapsulamento das
classes, integrao com banco de dados, mensagens e herana; prprias do modelo
orientado a objetos.

Encapsulamento
A primeira caracterstica que se observa na descrio do problema a existncia de
alguns objetos bem identificados. Na descrio foram usados o POS, a Loja, o Cliente
e o Produto. Nenhuma ao ficou sem uma origem ou um destino entre estes objetos. O
hbito de fazer compras em lojas, torna estes conceitos familiares para a maioria dos
leitores, o que facilita muito o entendimento do processo. Todos sabem que uma loja
um estabelecimento comercial onde os clientes encontram os produtos e podem adquirlos. Pra facilitar o processo de venda a loja mantm, alm de uma lista de produtos
para venda, uma lista de clientes cadastrados, com um limite de crdito.
A lista de produtos anloga a uma estante onde os produtos a serem vendidos
estariam expostos para a venda. Cada Produto possui um preo, uma descrio e um
cdigo para facilitar a venda. Qualquer outro objeto do sistema pode escolher um
Produto e verificar seu nome, preo e cdigo simplesmente perguntando para ele. O
Produto possui estas informaes a seu respeito, e possui ainda meios para responder
perguntas o tipo: Qual o seu preo? A caracterstica do Produto de ser autosuficiente em prover informaes sobre si mesmo conseqncia do encapsulamento.
No modelo, a Loja uma entidade que se relaciona com os POS para prover
informaes para as vendas. O POS uma interface de acesso s informaes da Loja,
e por isso ele pergunta para a Loja o que ele quer saber. Para conseguir dar todas as
respostas como o preo do produto, ou o crdito do cliente a Loja conta com outros
objetos encapsulados na prpria Loja: uma listaDeClientes, que guarda a lista de
todos os clientes da loja e uma listaDeProdutos, que guarda todos os produtos
venda. Ao ser questionada sobre qual o produto que possui um determinado cdigo, a
Loja procura este produto na sua lista e devolve o objeto oProduto. Este produto
criado e transferido para fora da classe Loja, para uso do POS. Esta uma importante
caracterstica relacionada ao encapsulamento dos objetos: o objeto oProduto
transferido para o POS em resposta esta mensagem, todas as informaes e a
capacidade de receber mensagens e dar respostas vai com ele. Como est encapsulado
no objeto todas estas habilidades, elas so transferidas em 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, e prosseguir o processamento do sistema. Analogamente, a Loja
fornece um Cliente ao POS quando pede para identificar o Cliente pelo seu CGC. O
nome, o crdito prprios deste cliente so transferidos encapsulados no objeto. Em um
sistema orientado a objetos no h como separar uma informao do seu proprietrio.
No possvel existir um mtodo sem que um objeto seja o seu dono. O
encapsulamento obrigatrio.
Temos, neste exemplo, duas classes: a dos Produtos e a dos Clientes. As classes
definem tipos de objetos. Uma classe define uma estrutura que compartilhada por
todos os objetos que forem criados a partir daquela classe. Esta estrutura formada por
um conjunto de dados armazenados pelo objeto, e um conjunto de funes que o objeto
usa para se comunicar. Os dados e as funes esto encapsuladas no objeto e s
existem enquanto existir o objeto. Cada funo uma possvel mensagem que o objeto
est habilitado a responder.
A anlise de um sistema parte, inicialmente, por uma definio das classes do
sistema para ento definir como os objetos, gerados a partir destas classes, iro
interagir. O modelo conceitual de um sistema , em sntese, um modelo das classes do
sistema, e da sua estrutura. No modelo conceitual devem ser descritas as classes
extradas do domnio do problema e como elas se organizam. de se esperar que
terminada esta descrio, grande parte dos problemas estejam, conceitualmente,
resolvidos. Resta entretanto, o detalhamento necessrio para a implementao.

Integrao com Banco de Dados


A lista de clientes e a lista de produtos da loja devem estar disponveis para a
pesquisa assim que o sistema inicia a operao. Para que isto seja possvel elas devem
ficar armazenadas em um banco de dados, na forma das tabelas: Tabelas de Clientes,

Tabela de Produtos.

Figura 22 - Fluxo dos dados na carga do banco de dados


Para efeito de testes sero utilidadas as seguintes tabelas de dados, que mostram a
estrutura dos dados disponveis para a loja

Um objeto pode receber chamadas de mensagens de outros objetos, para isso ele
dispem de funes que so acionadas pelo objeto chamador. Uma mensagem pode
enviar com ela uma informao e recebe outras informaes como resposta. A
comunicao entre o caixa, que uma pessoa, e o POS, uma classe de um software
orientado a objetos, ocorre na forma de mensagens. O Caixa ativa eventos no POS,
pressionando botes para enviar as mensagens, e recebendo as respostas em uma tela.
As mensagens enviadas pelo Caixa ao POS se transformam e outras mensagens que o
POS e pode enviar a outros objetos do sistema como a Loja.A execuo do sistema se
inicia com a criao da lista de clientes (listaClientes) e de produtos (listaProdutos).

Antes da execuo do programa esta lista estava armazenada no banco de dados da


loja, para transferir estas tabelas para os objetos foi criada uma classe auxiliar:
BDLoja. Esta classe cria os objetos com base nos dados existentes no banco de dados.
Neste exemplo optamos por executar esta criao na inicializao do sistema. No
entando, ela pode ser feita em tempo de execuo, isto , na medida em que os objetos
so solicitados pelo sistema eles so procurados no banco de dados.

Mensagens
A comunicao entre os objetos ocorre na forma de mensagens. Uma mensagem a
chamada de uma funo de um objeto, requerida por outro objeto. O objeto POS uma
interface grfica criada para o caixa poder acionar as funcionalidades disponveis nos
objetos da loja, ou em objetos locais. Ele recebe a solicitao feita pelo Caixa e as
transfere para os outros objetos do sistema. Esta seqncia de mensagens forma o
processamento em um sistema orientado a objetos.
O POS uma classe criada para se colocar entre o usurio final, o caixa, e os
demais objetos do sistema. Os elementos presentes no POS so caixas de dilogo e
botes. Uma caixa de dilogo permite que se entre com dados em caixas de texto
apropriadas. Outras caixas de dilogo apresenta uma forma do POS se comunicar com
o usurio pelas mensagens escritas. Os botes representam as funcionalidade que o
POS oferece ao Caixa.

Figura 23 - Interface do POS


A classe Cliente, por exemplo, oferece ao sistema a funcionalidade de informar o
seu crdito. As mensagens podem ser entendidas como perguntas feitas de um objeto a
outro. As perguntas no so formuladas na forma interrogativa como Qual o crdito?,
mas sim escritas na forma imperativa como obtenha o crdito ( ou getCredito ). Assim
dado o objeto comprador do tipo Cliente (Cliente:comprador); podemos perguntar ao
[3]

comprador qual o seu crdito, usando a funo getCredito , que devolve um valor de
crdito como resposta, na forma da mensagem:

vCredito = comprador.getCredito()
Neste comando, a varivel vCredito recebe o valor do crdito do comprador. Como
podemos ver, o formato tpico de uma mensagem, tambm conhecida como a assinatura
de uma mensagem, mostrado abaixo. Entre os parentesis ( ) da funo podem ser
transferidos parmetros e dados de entrada na pergunta.
Resposta = objeto.funo( )
O boto CLIENTE serve para enviar a pergunta para a Loja: Quem o cliente que
possui o CGC yyy? Onde o valor do cgc foi digitado na rea de entrada de dados. A
mensagem que enviada ao objeto Loja :
Comprador = loja.getCliente(yyy)

Figura 24 - Exemplo da Operao do Sistema


O boto PRODUTO pergunta para a Loja: Qual o produto com o cdigo xxx? ,
com o valor do cdigo digitado na rea de entrada de dados.

oProduto = loja.getProduto(xxx)
O boto PARCELAS pergunta para o produto, se ele pode ser vendido para este
comprador por n parcelas? Onde n foi digitado na rea de entrada de dados e o
oProduto e o comprador foram obtidos nas respostas das perguntas acionadas por
CLIENTE e PRODUTO.

Aprovado = oProduto.isAprovado(n, comprador)

Figura 25 - Exemplo do sistema em operao


A figura mostra o processamento que no aprovou a venda do item de cdigo 101
para o cliente 1000 em 3 parcelas.

Herana
No exemplo, foi definida uma regra de negcio na qual o cliente pode se tornar um
cliente do tipo VIP que possui as mesmas caractersticas do cliente comum, mas com
uma capacidade de crdito dobrada. Isto , ele pode fazer dvidas duas vezes maiores
que o seu crdito. Assim deve-se criar uma classe ClienteVIP que deriva da classe
Cliente, ou como se diz na linguagem da orientao a objetos, a classe ClienteVIP
herda da classe Cliente os seus dados e funes.
A capacidade de uma classe herdar de outra classe uma das principais
caractersticas da orientao a objetos. A classe Cliente chamada de super classe, ou
classe me, da subclasse ClienteVIP ou classe filha. O que isso que dizer que a classe
filha , inicialmente, uma classe igual classe me, mas pode modificar ou extender
suas habilidades, podendo ser mais especializada que a classe me original.
No exemplo, a classe ClienteVIP uma classe Cliente possuindo por isso um
nome, um CGC e um crdito; no entanto, por ser um ClienteVIP ele ter o seu crdito
dobrado. Para implementar esta modificao a funo de informar o crdito reescrita
de modo a responder com o crdito em dobro, como mostra a tabela que compara estas
duas funes:

Cliente.getCredito( )

ClienteVIP.getCredito( )

public int getCredito ()

public int getCredito ()

{
}

return (credito);

return (2*credito);

Como o ClienteVIP tambm uma classe do tipo Cliente, os objetos gerados por
ClienteVIP podem assumir o papel dos objetos do tipo Cliente, isto podem fazer
parte da lista de Clientes da Loja e tambm ser enviado como resposta ao POS. Em
qualquer situao onde um objeto do tipo Cliente possa ser usado um outro objeto do
tipo ClienteVIP tambm pode. Esta versatilidade dos sistemas orientados a objeto d
ao analista uma liberdade muito grande para expandir o sistema sem perder as
funcionalidades j implementadas. O analista pode buscar as heranas prprias do
problema estudado, e criar rvores de classes, descrevendo o problema por intermdio
de camadas crescentes de significado e funcionalidade. Quando o sistema em projeto
atingir o nvel de significao desejado interrompido o desenvolvimento.

3. Modelo de Contexto

Este captulo descreve o modelo de contexto do sistema, representado na


UML pelo diagrama de casos de uso. Este modelo, o primeiro a ser criado para
definir um problema, representa as expectativas funcionais dos usurios e por isso
desenvolvido em conjunto entre analistas e usurios. So descritos aqui alguns
cuidados prprios deste tipo de modelagem, e o resultado da aplicao desta tcnica
em um exemplo de aplicao.

3.1.

Introduo

A escala de observao o fator que define o nvel dos detalhes observados em um


modelo. Algum olhando de uma grande distncia pode distinguir uma casa na paisagem
e at dizer se h fumaa saindo pela chamin, mas no saber dizer se as paredes so
lisas e bem cuidadas, ou se h algum 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 algum na sala, mas deixa de
observar a chamin. Perde-se a noo do todo ao se manter atento a um nico detalhe.
Deve-se escolher a distncia e o ponto de vista em funo do que se pretende analisar
com o modelo.
Observando um fenmeno com uma grande escala pode-se ver o seu comportamento
global e o balano entre as entradas e sadas, mas perde-se o detalhe de cada processo
independente. Reduzindo a escala, o nmero de detalhes aumenta, e observa-se
particularidades que estavam perdidas na viso geral, o problema que agora perde-se,
inevitavelmente, a viso global. No possvel observar globalmente e ao mesmo
tempo ter todos os detalhes. Cada fenmeno a ser estudado exige que selecionemos uma
escala adequada para model-lo.
Este estudo prope-se organizar a modelagem de sistemas de software segundo trs
modelos: modelo de contexto, modelo conceitual e modelo detalhado. Este captulo
descreve o modelo de contexto, que observa o sistema a uma grande distncia, de
modo que um nico diagrama suficiente para representar o sistema como um todo.
No possvel, com o modelo de contexto, observar detalhes da operao, construtivos
ou de implementao. No entanto, um modelo suficiente para se notar as
funcionalidades principais do sistema e se ter uma definio clara de quais so os
elementos externos ao sistema com quem ele deve se relacionar. O modelo de contexto
ajuda a definir onde o sistema estudado se insere na empresa, ou seja, em qual contexto
da empresa o sistema se encontra.
com o modelo contextual que se inicia a definio do problema, colocando o
sistema no contexto do negcio e do cliente. A idia de desenvolver um modelo que
faa a integrao do sistema em estudo com o contexto do cliente exige que o modelo
seja simples, e de certo modo at intuitivo. Isto , o cliente deve ser capaz de
reconhecer o sistema no modelo sem a necessidade de um treinamento especial. O
modelo de contexto no deve possuir uma formalidade excessiva, para poder ser
entendido e validado pelo prprio cliente. Deve ser possvel ao cliente situar o sistema
no seu contexto de trabalho, identificando pontos de integrao com outros sistemas e
com seus usurios.

Para criar o modelo de contexto usaremos dois recursos da UML: o diagrama de


pacotes e o diagrama de casos de uso. O modelo de pacotes ajuda a dividir um sistema
em subsistemas, e identificar as dependncias entre os subsistemas. O modelo de casos
de uso ajuda a definir os requisitos funcionais e a desenhar a fronteria de cada
subsistema.

3.2.

Pacotes, Sistemas e Subsistemas

Ao se estudar um sistema de informaes, que se pretende automatizar, pode-se


chegar a um nmero de problemas que impledem o seu tratamento, como um todo
porque o conjunto complexo demais. O analista precisa ter neste momento,
ferramentas para organizar este sistema complexo em partes menores, s quais chamamse de subsistemas. Um subsistema possui todas as caractersticas de um sistema, e
parte integrante de um sistema completo maior.
A organizao em subsistemas surge, naturalmente, da anlise detalhada de um
problema. Ela pode ser realizada por um particionamento funcional, organizacional,
operacional, ou por diversas outras formas. A nica exigncia que a unio destas
partes, ao final, formem o sistema completo proposto inicialmente.
O pacote o elemento da UML utilizado para agrupar os elementos de um sistema,
para organiz-los, um pacote pode abrigar outros elementos, 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 uma unidade, pode ser
modelado na UML por um pacote.

Figura 26 - Representao de um pacote


A representao grfica de um pacote feita pelo o cone de uma pasta, metfora
que recorda um armazenador, um conjunto de contedos organizado sob um nome, o
nome do pacote.
Apesar de estarem sendo indicados aqui para modelar os sistemas e subsistemas, os
pacotes podem ser aplicados em qualquer fase do desenvolvimento de um software,
inclusive para organizar as prprias fases do desenvolvimento, verses do sistema,
isolar componentes de software, etc. Os pacotes se aplicam a todos os modelos da
UML, mas tem uma aplicao maior nos diagramas estruturais como os de classes e
casos de uso.
A boa prtica manda usar nomes simples, curtos, escrito em letras minsculas. Os

nomes devem estar associados aos componentes principais, ou subsistemas, que o


pacote representa. Os pacotes podem se relacionar com outros pacotes, atravs de uma
relao de dependncia. Um subsistema pode depender de outro subsistema. Esta
relao pode ser apresentada graficamente, em um diagrama de pacotes. As
dependncias so representadas por meio de setas tracejadas. As setas partem do
subsistema dependente e apontam para os subsistemas independentes.

Figura 27 - Exemplo de dependncia entre subsistemas


Retomando o exemplo do sistema de automao comercial que controla as vendas
de uma loja e gerencia o crdito e o cadastro dos clientes. Para organizar este sistema
pode-se divid-lo em trs subsistemas: vendas, crdito e cadastro; como mostra a
figura. Nela pode-se ver que o subsistema vendas depende do subsistema de crdito e
de cadastro, adicionalmente, o subsistema de crdito tambm depende do cadastro dos
clientes.
Os pacotes oferecem um meio simples de se organizar os modelos, que na medida
em que eles se tornam mais complexos. comum com o crescimento do entendimento
do problema ou com a evoluo do sistema em direo fase de implementao, os
modelos se tornam demasiadamente complexos, grandes ou poluidos com informao
em excesso. O uso de pacotes pode ajudar a organizar os modelos nestes caso, alm da
diviso em subsistemas j vista. Deve-se, no entanto, tomar o cuidado para no utilizar
pacotes em excesso, que uma vez pode ser um elemento que dificulta a leitura de
modelos simples.
Em uma primeira abordagem, a escala dos subsistemas permite definir os limites do
sistema e sua diviso, quando necessria, em subsistemas. Deve-se agora observar o
interior de cada subsistema, para criar um modelo que permita observar cada

pacote isoladamente, em um nico diagrama. O modelo de contexto aumenta o seu nvel


de detalhes, mas permite ainda uma viso global, feita com uma grande escala, com um
alto nvel de abstrao.

3.3.

Modelo de Contexto

O modelo de contexto define a fronteira entre o que sistema do que no sistema.


O que sistema pode ser modificado pelo desenvolvimento do software. O que no
sistema, e por isso ficar fora da fronteira, no pode ser modificado pelo software, mas
interage ele. Utiliza-se os diagramas de casos de uso propostos por Jacobson (1992) e
adotada pela UML, para descrever o modelo de contexto. A tcnica tem como principal
vantagem a simplicidade da representao, que permite uma interao direta com os
clientes e usurios na definio dos requisitos funcionais do sistema
Em 1987, Jacobson apresenta os Casos de Uso (Use Cases) usados como ferramenta
da metodologia Objectory. A adoo do termo Caso de Uso possui claramente a
intenso em mostrar uma viso do usurio do sistema, e de que o sistema de informao
construdo para os seus usurios. No diagrama de casos de uso o sistema descrito
como uma caixa preta, e que possui algumas funcionalidades. Cada funcionalidade
corresponde ao que se convencionou chamar de Caso de Uso. Em 1992, Jacobson
(1992) lana um livro onde onde toda a Engenharia de Software Orientada a Objetos
desenvolvida sob uma abordagem de Caso de Uso. O diagrama de Casos de Uso foi
incorporado desde a primeira verso da UML (Jacobson, 1998) como uma abordagem
funcional feita pelo usurio, com finalidade de nortear os demais diagramas do modelo
orientado a objetosda UML.

3.3.1.

Diagrama de Casos de Uso

O objetivo do diagrama de casos de uso descrever um modelo funcional de alto


nvel do sistema em projeto. Este diagrama procura identificar os usurios e representar
o sistema segundo a sua viso. Jacobson (1992) afirma que um conjunto de descries
de casos de uso deve especificar completamente a funcionalidade do sistema, assim os
desenvolvedores devem procurar junto aos usurios de cada subssistema formar este
conjunto de casos de uso.
Os casos de uso so utilizados em todas as fases do desenvolvimento de um sistema.
No incio, durante o desenvolvimento e ao final, quando o sistema est pronto. A
aplicabilidade inicial do diagrama de casos de uso a de auxiliar o analista na
definio dos requisitos do sistema. Os requisitos que o sistema devem atender so
decorrentes do uso que os usurios pretendem do sistema. As funcionalidades
pretendidas devem ser transformadas em objetivos que o sistema deve cumprir para
seus usurios. Esta definio de requisitos pode ser suficiente para se assumir um
contrato entre os clientes e desenvolvedores na fase inicial do projeto. Os objetivos
dos usurios sero os casos de uso do sistema, e o compromisso dos desenvolvedores
de atend-los.
Durante as fases de design e construo, os casos de uso so usados para ajudar a
criar outras vises, alm da funcional, do sistema. A anlise da descrio dos casos de
uso pode ajudar a entender os processos e a dinmica dos problemas envolvidos no
sistema. A partir da descrio, contida nos casos de uso, pode-se extrair o que sistema
deve fazer e como ele deve atender os usurios. Os casos de uso devem ser explorados
durante o desenvolvimento para validar o sistema. A cada nova funcionalidade
implementada no sistema os casos de uso podem ser usados para validar se esta
funcionalidade est de acordo com o especificado pelos usurios.
Como os casos de uso so criados a partir da viso do usurio. Eles podem ser
aplicados na fase final de testes de integrao do sistema. A partir de cada de uso
possvel definir testes, por vezes chamados de casos de teste, que so aplicados no
sistema, quando este estiver pronto. Os diagramas de casos de uso podem ser usados
para o planejamento do desenvolvimento do sistema, uma vez que possvel extrair das
funcionalidades contidas nos casos de uso uma medida da complexidade.
Apesar de grande flexibilidade, a utilizao dos casos de uso deve ser limitada, e
pode ser mal utilizada se for extrapolada a abrangncia da sua aplicao. comum se
tentar traduzir a funcionalidade expressa nos casos de uso diretamente para um sistema
de software, deixando de lado os modelos orientados a objeto. Esta uma abordagem

exclusivamente funcional, uma vez que os diagramas de casos de uso so anlogos aos
diagramas de fluxos de dados (DFD) da abordagem funcional. Agindo assim, abandonase a orientao a objetos e volta-se ao paradigma funcional.
O diagrama de casos de uso deve isolar os elementos do sistema de software dos
elementos externos. Os elementos externos so chamados de atores, e interagem com os
casos de uso no sistema. A figura abaixo mostra um exemplo de um diagrama de casos
de uso.

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 finalidade (casos de uso 1
e 2). Assim tambm, 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 elementos externos ao sistema que interagem com ele.


Estar fora do sistema no poder ser alterado pelo desenvolvimento do sistema. Isto
quer dizer que o desenvolvedor no tem sobre o ator o poder de programar a sua ao,
como ele tem sobre o computador nos casos de uso. Ao focar os atores, a modelagem
procura se concentrar em como o sistema ser utilizado, e afastar o analista de como o
sistema ser contrudo. Ainda no deve haver na descrio dos casos de uso
compromisso assumido com a construo. A importncia dos atores, no modelo de
contexto, vem do princpio de que os sistemas computacionais servem para atender as
necessidades de seus usurios. O mais importante nos primeiros passos do
desenvolvimento de um sistema identificar quem so os atores e quais so as suas
necessidades.
Um ator um papel de algum ou alguma coisa no ambiente que se relaciona com o
sistema. Alternativamente, Jacobson (1992) define ator como representando tudo que
precisa trocar informao com o sistema, ou seja, qualquer coisa que interage com o
sistema. Assim, uma mesma pessoa pode assumir mais de um papel, e ser representada
no sistema por mais de um ator. O termo ator caracteriza bem a possibilidade do
mesmo usurio, em diferentes situaes, assumir personalidades diferentes para o
sistema, agindo como um ator em uma pea teatral. Em cada uma destas situaes,
deve-se procurar identificar as necessidades dos atores, que se tornaro requisitos para
o sistema, na forma de casos de uso. A linha que separa os atores dos casos de uso a
fronteira do sistema.
Deve-se notar a diferena entre atores e usurios. Os usurios do sistemas so
instncias dos atores. Um mesmo usurio pode, em diferentes momentos do sistema,
instanciar diferentes atores, ou seja um mesmo usurio pode assumir diferentes papis
no sistema.

Representao
. Os atores so, normalmente, representados por uma figura humana estilizada. A
UML admite tambm o uso de cones e outras simbologias para representar um ator, que
podem ser representados tambm por um retngulo com a anotao <<ACTOR>>. A
anotao <<ACTOR>> , representa um esteretipo da UML, e permite transformar a
simbologia escolhida em um ator.

Figura 29 - Formas alternativas de representar um ator.


Os atores devem ser identificados com um nome que traduz o papel deles no
sistema. No existem regras rgidas para dar nomes aos atores, mas uma boa prtica
utilizar nomes substantivos, com o significado ligado ao domnio do
problema estudado. Deve-se evitar dar nomes muito genricos como: Usurio,
Operador ou Sistema. O uso da palavra "Usurio", como o nome de um ator, pode ser
utilizada desde que, por exemplo, aquele ator represente todos os usurios do sistema.
Os atores so encontrados entre os usurios provveis do sistema. Usurios que
podem ser pessoas ou at mesmo outros sistemas computacionais. Uma das tcnicas
cercar, imaginariamente, o sistema e observar quem interage com ele. Pode-se procurar
a quem a soluo do problema interessa, e quem colabora para se chegar a esta
soluo. Nestes personagens encontram-se os atores. comum encontrar grupos de
personagens, que se comportam da mesma forma frente ao sistema. Estes grupos so
representados com um nico ator do sistema. A mesma pessoa, usuria do sistema,
pode pertencer a mais de um grupo, e assim uma mesma pessoa pode assumir mais do
que um papel, e ser representada no modelo de contexto por mais do que um ator.
Em um processo possvel que os atores se relacionem entre si, trocando
informaes, mensagens ou realizando algumas operaes entre si. O analista deve
observar se esta comunicao entre atores se d dentro ou fora do sistema, para decidir
se deve ou no represent-la. Quando a comunicao feita dentro do sistema ela
importante para o desenvolvedor porque devero existir comandos e interfaces no
software para permitir que os dois atores se relacionem. No caso da comunicao fora
do sistema ela no representada pelos casos de uso e no importante para o
desenvolvimento do software.
Um ator representado no sistema no pode ser programado, ele fica fora do escopo
do desenvolvimento do sistema, e, provavelmente, no alterado pelo sistema.
Observa-se, entretanto, que a introduo de um sistema de informaes afeta muito alm
do que as fronteiras definidas inicialmente, podendo ir para alm dos usurios. No

incio do desenvolvimento de um sistema um ator possui necessidades que so


expressas e consideradas como requisitos do sistema de software. Quando o software
implementado, e as necessidade iniciais so atendidas, surgem outras necessidades nos
usurios, que foram provocadas pela introduo do sistema, ou seja, o sistema pode
tambm alterar os atores. Este efeito , normalmente, desconsiderado no
desenvolvimento pela sua alta complexidade e pela incapacidade de ser modelado e
tratado com preciso. O analista experiente pode tentar prever um sistema que se
adapte esta nova realidade e incluir estes requisitos no problema.

Exemplo
A figura abaixo mostra alternativas de representao de atores em um determinado
sistema. Considerando que a melhor alternativa aquela que incorpora uma quantidade
maior de informao, temos que:

3.3.3.

Caso de Uso

As necessidades dos atores so representadas nos casos de uso. Um caso de uso


uma seqncia de transaes ocorridas no sistema, que refletem em algo de importncia
para o ator que se comunica com este caso de uso. Os atores definem suas necessidades
na forma de objetivos a serem cumpridos pelo sistema, que so capturados pelos casos
de uso.
O princpio, por trs deste diagrama, que um sistema de software criado para
atender os seus usurios, representados no diagrama pelos atores. Os atores demandam
resultados do sistema, que se organizam em objetivos, representados nos casos de uso.
Um caso de uso se traduzir em uma srie de aes, que vo descrever como um ator
poder atingir o seu objetivo, assim como as alternativas e as excees que iro
impedir a concluso com sucesso deste objetivo. Todos estes cenrios de interao do
ator com o sistema devem estar inclusos na descrio dos caso de uso.
Utiliza-se um caso de uso quando se deseja representar uma funcionalidade de alto
nvel no sistema, ou para representar um conjunto de funcionalidades esperadas por um
ator. Para identificar os casos de uso devemos consultar os atores, e observar as suas
necessidades, agrupando-as e associado-as aos atores. Um caso de uso composto por
uma representao grfica e por um descrio textual, que so descritas a seguir:

Representao Grfica
Um caso de uso representado, graficamente, por uma elipse em torno do seu nome,
como mostra a figura. Associado ao nome, um breve texto descreve o objetivo que o
caso de uso est representando.

Figura 30 - Representao Grfica de um Caso de Uso


O nome do caso de uso , em geral, uma orao verbal curta que representa, no
contexto do sistema, o objetivo pretendido. Os atores formam o sujeito da ao

expressa pela orao. Desta forma, conveniente utilizar verbos no presente, no


infinitivo ou no gerndio para identificar os casos de uso, como mostram os exemplos a
seguir:
Os diagramas de casos de uso podem ser lidos colocando-se o ator como sujeito e
os casos de uso como predicado, na forma:
O Gerente (pode) aprovar crdito
O Cliente (est) consultando Catlogo
O Comprador realiza a compra.

Figura 31 - Exemplos de Casos de Uso

Descrio Textual
Associado a cada caso de uso um texto descreve os fluxos de eventos que resultam
no objetivo pretendido pelo ator. Todo caso de uso tem, necessriamente, um fluxo de
atividades principal, que vai levar o ator ao sucesso do seu objetivo. A seqncia
normal de atividades pode apresentar caminhos alternativos ao fluxo principal,
assim como seqncias de atividades que descrevem falhas que impedem o ator de
atingir o seu objetivo. A figura mostra, esquematicamente, estes fluxos, que devem
ser descritos em um texto que acompanha o caso de uso:

Figura 32 - Fluxos possveis em um caso de uso


(a) principal, (b) alternativo e (c) caminho com falha
A descrio dos casos de uso pode ser escrita em uma linguagem informal, em um
texto estruturado ou at mesmo com um pseudocdigo. O importante que a descrio
de um caso de uso possa ser aprovada pelo cliente do sistema, e que os projetistas
possam entender o processo de negcio. Os casos de uso podem tambm ter pr e ps
condies, que vo condicionar a seqncia de transaes que devem ocorrer. As
precondies dizem que para o ator poder executar aquele objetivo so necessrias
algumas condies anteriores, assim como a execuo do objetivo leva a uma condio
posterior execuo (ps-condio).
Toma-se como exemplo o caso de uso onde um cliente consulta um catlogo de
produtos de uma suposta loja virtual. Este caso de uso, chamado de Consultar Catlogo
pode ser descrito textualmente, de forma no estruturada como:

Caso de Uso: Consultar Catlogo

Busca por um ou mais produtos em um catlogo de produtos. Os produtos so


organizados por tipo e famlia. A consulta pode ser feita selecionando-se o tipo de
produto e em seguida escolhendo uma famlia daquele tipo. Os produtos podem ser
ordenados por preo ou por ordem alfabtica do nome. possvel procurar um
produto por parte do nome ou da descrio. A procura fornece uma lista de produtos
onde o texto procurado foi encontrado no nome ou na descrio. Se o usurio da
consulta j se identificou para o sistema, a lista dos ltimos 10 produtos procurados

pode ser apresentada, facilitando a procura.


Este mesmo caso de uso tambm pode ser descrito de forma estruturada, como:
Nome: Consultar Catlogo
Objetivo principal: Permitir a procura de um ou mais produtos em um catlogo
de produtos organizado por tipos e famlias de produtos.
Alternativas Alternativamente a procura pode ser feita por uma palavra existente no
nome ou na descrio do produto.
Excees Se o catlogo no oferece o produto procurado, oferecer uma lista com
os dez produtos mais procurados.Se mais de 50 produtos atendem o critrio de
procura, os produtos so apresentados em grupos de 50.
Prcondies : O cliente deve estar cadastrado,
Ps-condies : Aps a procura os produtos encontrados passam a compor a lista
de produtos procurados, que podem seguir para o processo de compra.
A descrio estruturada mais formal e por isso mais completa que uma descrio
no estruturada e informal. A descrio informal suficiente na maioria dos sistemas,
principalmente para a validao do modelo de contexto por parte dos usurios. No
entanto, a descrio estruturada mais adequada na aplicao dos Casos de Uso em um
mtodo formal para desenvolvimento de sistemas.

Colaborao entre os Casos de Uso


Os casos de uso podem colaborar com atores e com outros casos de uso. Estas
colaboraes so expressas no diagrama por meio de ligaes entre os elementos que
colaboram. As ligaes podem, opcionalmente, ter uma seta que no tem valor
semntico, ela apenas orienta a leitura do diagrama. As colaboraes dos casos de uso
so sempre bidirecionais, o que quer dizer que pode haver troca de informao nos
dois sentidos da colaborao.
Os atores se comunicam, controlam e recebem informaes dos casos de uso. Uma
colaborao entre os casos de uso e os atores indica que os objetivos do ator so
definidos pelos casos de uso. Deve-se verificar se todos os objetivos do ator esto

presentes e so bem definidos.


Um caso de uso pode colaborar com outros casos de uso para conseguir cumprir o
seu objetivo principal. Isso quer dizer que um objetivo principal pode ser decomposto
em objetivos intermedirios de outros caso de uso. Esta decomposio far com que os
casos de uso mantenham entre si uma relao de dependncia, representada pela seta
tracejada. O caso de uso dependente est na origem da seta, e o independente no destino
da seta.

Figura 33 - Colaborao entre os Casos de Uso

3.3.4.

Consideraes Gerais sobre o Modelo de Contexto

Algumas consideraes gerais so importantes na formao do diagrama de casos


de uso, e podem auxiliar a criar um diagrama correto.

Independncia entre Casos de Uso


Os casos de uso devem ser escolhidos de modo a serem independentes entre si,
apesar de poderem existir relaes entre eles. Isso se deve para evitar que hava uma
confuso entre as funcionalidades especificadas. Erros na separao pode, algumas
vezes, levar inconsistncias entre os casos de uso. Um caso de uso pode especificar
um tipo de responsabilidade que negada por outro. O modelo de contexto no tem
meios de evitar ou lidar com estas inconsistncias, que sero tratadas por outros
modelos, posteriormente.

Granularidade dos Casos de Uso


Um dvida frequente durante a construo do modelo de contexto o grau de
detalhes que se deve adotar ao se criar em caso de uso. Por definio, os casos de uso
renem um conjunto de transaes que conduzem um objetivo do ator. Assim, se por
um lado, os casos de uso devem ser mais complexos do que uma simples transao; por
outro lado os casos de uso no devem compreender um nmero muito grande de
transaes. Um nmero grande de objetivos, poderiam ser decompostos em alguns
casos de uso. A situao desejada uma situao intermediria. Espera-se que os
casos de uso escondam uma complexidade razovel, que sero exploradas,
posteriormente, no modelos conceituais e detalhados (pelos diagramas de seqncia e
colaborao). Os fluxos de informao textual conduz o leitor do diagrama a uma
estrutura funcional do sistema. Na anlise conceitual, os fluxos de eventos vo conduzir
o analista aos conceitos fundamentais do sistema, que sero distribudas entre as
classes do sistema. No se deve confundir os casos de uso com as classes. Berard
(1996) destaca este e outros cuidados que se deve ter ao aplicar os Casos de Uso para
no comprometer a aplicao do paradigma de objetos no decorrer do projeto.

Evitar a decomposio de casos de uso

Outro erro comum, na aplicao dos casos de uso, a tentao de se realizar uma
decomposio de objetivos dos atores, como comum na anlise estruturada. Criandose casos de uso intermedirios como etapas de um processo, transformando-se o
diagrama de casos de uso em um fluxograma de processos. Pode-se estabelecer uma
relao direta entre um diagrama de contexto da anlise estruturada e diagrama de
casos de uso, mas no se deve transformar um diagrama de casos de uso em um
fluxograma.
Na decomposio funcional h uma grande proximidade com as funes, na
abordagem de dados, a proximidade com os dados, e na abordagem de objetos a
proximidade com o objetos. Como os casos de uso tem uma natureza funcional, a
mudana para objetos, realizada nas fases seguintes da anlise, pode provocar erros.
Por exemplo, alocar casos de uso a equipes diferentes de desenvolvedores, provoca um
desastre na modelagem orientada a objetos, mesmo que de subsistemas diferentes,
porque provavelmentem, haver a criao de objetos iguais nas duas equipes com
funcionalidades semelhantes e que deveriam estar agrupados (Berard,1996).

Integrar o cliente na modelagem


O diagrama de casos de uso deve ser construdo em conjunto entre os usurios e
demais projetistas. A notao simples facilita o entendimento e estimula a crtica ao
modelo, permitindo valid-lo j nas fases iniciais da anlise. Como o diagrama de
casos de uso traduz uma viso de fora para dentro do sistema, descrevendo o que o
sistema deve fazer, importante a aprovao do cliente e usurios para o sucesso do
projeto.
Deve-se, entretanto, evitar o excesso de formalismo na elaboraos dos casos de
uso. Desaconselha-se, por exemplo, o uso de recursos computacionais na elaborao
dos casos de uso quando da apresentao dele para os seus usurios, que pode afastlos do processo de desenvolvimento. O uso de um retroprojetor, quadro-branco, flipchart, papel e lpis encorajado ao se discutir um modelo com os usurios. Estas
ferramentas so mais familiares e aproximam os usurios leigos em computao com o
desenvolvimento do sistema. O computador ou sistemas sofisticados de software
podem ser considerados barreiras participao dos usurios nesta fase do projeto.
A validao de um sistema pelo cliente, nas fases iniciais so projeto, garante que
est se construindo o sistema correto. Isto , as reais necessidades dos usurios esto
sendo consideradas e atendidas. Para isso necessrio revisar, iterativamente, o
modelo de contexto inmeras vezes com os usurios. Em alguns casos, pode ser

necessrio criar um prottipo da interface, para apresentar ao usurio, que assim pode
se assegurar que o sistema ir atend-lo, pois visualiza ali a operao do sistema. A
identificao dos requisitos de interface podem ser extrados facilmente do diagrama de
casos de uso, analisando as relaes entre um ator e os casos de uso com quem ele se
comunica. de se esperar que para cada caso de uso deva haver uma interface para
acionar o objetivo e receber as respostas.

Comprometimento com a implementao


O ocultamento de informao (Information Hiding) o processo de tornar certas
partes do sistema de software inacessveis. Sugere-se que os detalhes do sistema, as
decises de projeto difceis ou que provavelmente vo mudar, devam ser ocultadas do
sistema. Assim, o resto do sistema tem acesso apenas as decises bem definidas, e
inalteradas. Com a especificao descrita pelos casos de uso deve-se evitar expor
detalhes em demasia, ou impor decises que sero tomadas no projeto ou na
implementao. Deve-se procurar evitar a tentao de especificar a estrutura interna ou
caratersticas de implementao que condicionem, exageradamente, o componente,
limitando-o quando da sua implementao.

Casos de Uso em Testes


Um caso de uso descrito por cenrios de sucesso, alternativos e de fracasso de um
objetivo do ator no sistema. Analisando um caso de uso possvel se criar um conjunto
de dados de entrada que simule cada um destes cenrios. Assim, para cada caso de uso
possvel se construir um caso de teste, que garante que o sistema, ao implementar o
caso de uso, ser completamente testado. Essa uma importante caracterstica de um
projeto de software com casos de uso, que iro orientar todo o desenvolvimento do
software atendendo as necessidades dos usurios. Se houver dificuldade em se
estabalecer estes testes, deve-se suspeitar da clareza e da preciso deste caso de uso,
ou at mesmo da sua real necessidade.

Cuidados nas descries textuais


Probasco (2001) destaca o cuidado que deve haver, por parte dos desenvolvedores,
na redao da descrio dos casos de uso. Em especial, ele destaca uma ateno maior

para a palavra deve. Como os requisitos dos casos de uso expressam a vontade dos
usurios, utilizar a palavra deve pode gerar obrigaes que no podem ser
cumpridas, ou limitar, exageradamente, a implementao do sistema. Como prtica
geral, no se recomenda o usar a palavra deve, sugerindo substitu-la por sugerese, recomenda-se, etc. O importante do caso de uso que ele sirva como meio de
comunicao entre o cliente e os desenvolvedores.

3.4.

Exemplo de Aplicao: Sistema de Vendas de Loja

Este exemplo retoma o sistema de vendas da loja descrito no captulo anterior, para
introduzir a formalidade do modelo de contexto e dos diagramas de casos de uso.

3.4.1.

Descrio de Subsistemas

Em uma loja qualquer, o sistema de vendas deve estar integrado a outros sistemas
de informao internos, importantes para o gerenciamento do empreendimento. Pode-se
representar cada sistema de informao como um subsistema da loja, caracterizado por
um pacote, como exemplifica a figura. Na figura mostra que o subsistema de vendas
dependente do sistema de cadastro do cliente e do sistema de estoque, que poderia ser
o responsvel por manter uma lista de produtos. A dependncia entre estes
subsistemas fica clara em um diagrama de pacotes.

Figura 34 - Subsistemas relacionados ao sistema da loja


Neste exemplo, explora-se apenas uma pequena parte do subsistema de vendas. Da
descrio do sistema, elaborada no captulo anterior, pode-se extrair que:
O caixa faz a venda em um terminal (POS)
O caixa le o cdigo do produto
O caixa identifica o cliente pelo CGC
O caixa verifica o parcelamento
Vemos que o ator do sistema o caixa, e que ele vem ao sistema com tres
objetivos, identificados nos trs casos de uso da figura abaixo, a saber: Identificar
produto, Identificar cliente e Autorizar o parcelamento.

Figura 35 - Diagrama de Casos de Uso dos Processos de Venda

3.4.2.

Descrio dos Casos de Uso

Segue uma descrio textual dos casos de uso identificados acima.

Identificar Cliente
O caixa recebe o nmero do CGC do cliente. Caso o cliente estiver presente no
cadastro da loja, verifica-se os dados do cliente como nome e o seu crdito. Um cliente
especial pode ter o dobro do crdito do cliente comum.

Identificar Produto
O caixa deve ler o cdigo no produto, em um leitor de cdigo de barras, ou deve
teclar o cdigo. A loja responsvel por manter uma lista de seus produtos, com os
dados de nome e preo, entre outras informaes sobre o produto. Com o cdigo
identificado, o caixa recebe os dados do produto.

Autorizar parcelamento
O caixa de posse dos dados do produto e de um cliente, pode verificar se o cliente
pode fazer a compra parcelada. A venda ser realizada se a dvida do cliente, na
compra parcelada, for menor do que o crdito que o cliente possui com a loja. O
sistema de vendas deve aprovar a venda ou no.
Este modelo poderia ser enviado para o cliente, irir analisar a especificao e
assegurar que o software, quando desenvolvido corresponde s suas expectativas. Esta
a finalidade do modelo de contexto.

4. Modelo Conceitual
Este captulo apresenta uma tcnica para se desenvolver um modelo
conceitual do projeto de software. O objetivo aqui identificar os principais
conceitos presentes em um problema e represent-los em classes, dando os primeiros
passos na direo da construo de um modelo orientado a objetos do problema.
Este objetivo conseguido utilizando a tcnica dos cartes CRC. Originalmente
criada para ensinar orientao a objetos, esta tcnica aplicada aqui como uma
forma de transformar os requisitos levantados no modelo de contexto nas classes do
modelo conceitual.

4.1.

Introduo ao Modelo Conceitual

Este captulo descreve o processo de criao de um modelo conceitual de um


sistema de software. Este modelo obtido a partir dos requisitos levantados pelo
modelo de contexto. O analista deve se posicionar suficientemente prximo do sistema
para extrair dos requisitos do problema os conceitos principais, sobre os quais ser
construda a soluo. Esta aproximao gradativa do sistema, que esta abordagem de
modelagem recomenda, evita a sobrecarga de complexidade no modelo nas fases
iniciais do processo de desenvolvimento, facilita o entendimento do problema e auxilia
no desenvolvimento do sistema de software.
Enquanto o modelo de contexto descreve, funcionalmente, o sistema sob o ponto de
vista do usurio externo, o modelo conceitual d as primeiras noes de como ser o
interior do sistema. No modelo conceitual so esboadas as idias principais que
compem o ncleo do sistema, descrevendo-o de dentro pra fora. A modelagem
conceitual se encontra entre as prticas propostas por Larman (1997) em seu livro
sobre a aplicao da UML. Neste trabalho, o modelo conceitual definido como a
representao de conceitos ou objetos do domnio do problema. A estratgia
recomendada de se criar um rascunho do diagrama de classes, onde a nfase est em
descobrir os requisitos mais evidentes, antes de lanar mo de uma investigao
aprofundada. Mais tarde nos ciclos seguintes do desenvolvimento, o modelo conceitual
poder ser refinado, incrementalmente, e estendido para considerar os demais
requisitos.
O modelo conceitual est tambm presente em mtodos incrementais de
desenvolvimento de sistemas. As primeiras fases do processo criam uma viso da
arquitetura completa do sistema. Uma arquitetura que, nas fases seguintes, orienta a
produo de verses do sistema. Assim, cada verso chega, incrementalmente, mais
prxima da viso da arquitetura completa.
O modelo conceitual captura os conceitos do sistema em um diagrama de classes. O
diagrama de classes a representao fundamental da modelagem orientada a objetos, e
evolui de uma viso conceitual para uma viso detalhada, com o desenvolvimento do
sistema. No modelo conceitual de classes possvel descrever os elementos principais
de um sistema, suas caractersticas individuais e como eles se relacionam.
A identificao de classes e das suas inter-relaes uma das etapas mais
complexas da anlise orientada a objetos. Para sistematizar esta busca, apresenta-se a
tcnica dos cartes CRC. Esta tcnica um mtodo eficaz para se fazer a transio do
modelo de contexto para o modelo conceitual. Proposta por Beck e Cunningham (Beck,

1989), o uso dos cartes CRC facilita a aplicao do paradigma de objetos na anlise
de um problema de software, e incentiva o envolvimento de usurios nas fases iniciais
da anlise. No final deste captulo, desenvolve-se o modelo conceitual do conhecido
jogo da forca, um dos casos estudados neste trabalho. Este exemplo retomado no
captulo 6 e tem o seu cdigo construdo na linguagem Java no apndice.

4.2.

Diagrama de Classes

Para se construir algo seguro importante se ter uma base slida. Uma afirmao
verdadeira tanto para uma construo civil, como, por exemplo, na construo de um
sistema de software. Para se obter um sistema de software confivel necessrio criar,
inicialmente, uma estrutura slida e estvel. Sobre esta estrutura so armazenadas as
informaes do sistema, e so desenvolvidos os processos necessrios para a soluo
do problema em questo. A estrutura de um sistema de software formada pelas
classes do sistema. Analogamente ao esqueleto dos animais, as classes formam uma
armao que d a forma ao sistema. As qualidades de um sistema so garantidas por um
conjunto de conceitos fundamentais, bem definidos, capturados nas classes e que
acompanharo o sistema da concepo implementao.
Classes so matrizes de objetos, elas identificam grupos de elementos do sistema
que compartilham as mesmas propriedades. A diferena entre classes e objetos j foi
assunto do captulo 2, mas aqui esta diferena revista luz da anlise de requisitos.
Os objetos so os elementos concretos envolvidos nas transaes dos sistemas, criados
a partir das definies abstratas das classes. Os objetos so instncias das classes.
Freqentemente, a descrio de um sistema descreve um caso, uma situao em
particular onde o personagem o objeto. Na representao, usa-se escrever os nomes
dos os objetos por letras minsculas e das classes por letras maisculas.
As classes representam um conceito importante para o problema em questo.
Enquanto uma classe descreve um conceito abstrato do domnio do problema, um objeto
representa um elemento deste conceito, que utilizado no sistema, de modo concreto.
Ao criar um objeto, com base em uma classe, ele assume valores para os atributos,
definindo um estado e herda um comportamento das classes que permite alterar este
estado. Os estados e os comportamentos so compartilhados por todos os objetos da
mesma classe, e so definidos na fase de anlise.
A UML incorporou a representao de classes utilizada na OMT de
Rumbaugh (Rumbaugh et al., 1994) com pequenas alteraes na notao. As classes so
identificadas por retngulos divididos horizontalmente em tres pores, como mostra a
figura. No tero superior encontra-se o nome da classe, no tero mdio a lista de
atributos e no tero inferior a lista de operaes que esta classe pode realizar. Apesar
desta ser a forma bsica de representao, existem formas alternativas que variam de
acordo com o interesse de representao e a preciso desejadas.

Figura 36 - Representao tpica de uma classe


A figura abaixo mostra algumas alternativas de representao da classe Loja do
problema do captulo 2. Na figura a classe Loja possui desde uma representao
simplificada at uma representao bem detalhada, onde os atributos e as operaes
so descritos com grande preciso e adornados por smbolos que iro definir a sua
visibilidade, valor inicial e tipologia. Para efeito do modelo conceitual iremos adotar a
representao (a ) ou (b), deixando a notao (c) para o modelo detalhado, que o
assunto do captulo seguinte.

(a)

(b)

(c)

Figura 37 - Formas alternativas de se representar uma classe


Os atributos das classes formam uma estrutura que permite o armazenamento de
informao. Podemos ter objetos encapsulados nos atributos das classes, com a sua
prpria estrutura de atributos, e a sua prpria capacidade de armazenamento de
informaes.
As operaes so as mensagens que a classe pode receber, e que definem as
funcionalidades que aquela classe est apta a realizar. Os objetos relacionados com a
classe podem oferecer a ela funcionalidade adicional na forma de mensagens que so
trocadas. Uma classe isolada , essencialmente, um depsito de informaes nos seus
atributos e oferece ao sistema um conjunto de funcionalidades definidas pelas suas
operaes. Para fazer uso destas potencialidades as classes precisam se relacionar.

No exemplo da loja, do captulo 2, foram identificados os conceitos de Produto,


Cliente, ClienteVIP e Loja. Cada um com suas propriedades como o Nome do
Cliente, o Cdigo do Produto, etc. O trompete que possui o cdigo 107 um objeto da
classe Produto. Charlie Parker o nome de um objeto da classe Cliente, Charlie
Mingus o nome de outro objeto da classe ClienteVIP. Como um ClienteVIP
possuir um comportamento de crdito diferente do Cliente, que permite parcelar as
compras de maior valor. O exemplo mostra que os conceitos, atributos e
comportamentos so definidos juntamente com as classes, mas s se tornam reais
quando as classes se tornam objetos durante o processamento do software. Vale
observar ainda, que a classe Loja, na figura possui na sua definio uma lista de
objetos da classe Cliente (listaClientes) e uma lista de objetos da classe Produto
(listaProduto). Este exemplo mostra como os conceitos podem se relacionar para criar
conceitos mais complexos.

4.2.1.

Relacionamento entre as classes

Sistemas orientados a objetos so formados por conjuntos de classes. Uma classe


no pode atender isoladamente todas as necessidades do problema, e por isso ela se
integra s outras, para juntas apresentarem uma soluo ao problema. Em conjunto, as
classes trocam mensagens para realizar os objetivos do sistema. O relacionamento entre
as classes serve de caminho para esta troca de mensagens, permitindo que as classes se
conheam, e criando um caminho que possibilita a comunicao.
As classes podem se relacionar de modos que variam de acordo com as afinidades
existentes entre as classes. Os relacionamentos podem ser fracos, indicando que as
classes no possuem uma grande afinidade, ou fortes atestando uma grande
interdependncia entre elas. Seguindo esta escala, podemos classificar os
relacionamentos como:
Dependncia (mais fraco)
Associao
Agregao
Herana (mais forte)

4.2.2.

Dependncia

O relacionamento mais fraco a dependncia. Representada por uma seta tracejada


ligando as classes, a dependncia parte da classe dependente e aponta para a classe
independente. Na figura abaixo, a classe A depende da classe B, o que quer dizer que,
de alguma forma, no especificada pela relao, os atributos ou as operaes da classe
A dependem da classe B. A dependncia no indica como ocorre esta dependncia,
mas serve para indicar que estas classes devem participar juntas do sistema.

Figura 38 - Exemplo de dependncia: A depende de B

No exemplo da loja do captulo 2, podemos dizer que a classe Loja depende das
classes Produto e Cliente. Esta dependncia representada pelas setas que ligam estas
classes na figura abaixo. A dependncia pode evoluir, em uma fase posterior da
modelagem, para outro tipo de relacionamento que defina melhor a afinidade entre as
classes.

Figura 39 - Exemplo de dependncia entre as classes.


A dependncia um relacionamento comum entre os pacotes. Ela representa o fato
de que existe algum tipo de relacionamento entre as classes que compem os pacotes e,
conseqentemente, os pacotes esto tambm relacionados. Como o relacionamento
entre os pacotes no est claramente determinado porque depende das classes que eles
contm, usa-se represent-lo pela dependncia.

Figura 40 - Exemplo entre dependncia entre os pacotes

4.2.3.

Associao

As associaes aparecem quando h um nvel maiorde envolvimento, e mais bem


definido do que na dependncia, entre as classes. Na associao as classes esto
ligadas semanticamente umas s outra. Ou seja, as classes mantm-se independentes,
mas guardam uma algum tipo de significado na sua relao. Esta relao j permite a
troca de mensagens entre as classes na ajuda para o cumprimento de suas
responsabilidades. Na figura abaixo a classe R est associada classe S. A classe R
pode chamar as operaes de S por intemdio do objeto varS que um objeto da classe
S, e que representa a associao. A representao da associao uma linha que
interliga as classes. Esta linha pode possuir uma seta indicando a direo da
associao. Outros adornos das associaes sero vistos mais frente no texto.

Figura 41 - Exemplo de associao entre as classes


Deve-se observar que uma associao significa 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 atravs da associao. Estando presente, R pode se comunicar
com S atravs de varS.

4.2.4.

Agregao

Alguns tipos de associao podem exigir um aumento no grau de envolvimento entre


as classes o que cria a agregao. A agregao equivalente associao mas indica
que as classes possuem uma dependncia existencial, isto , uma classe s existe em
conjunto com as suas agregadas. A classe todo composta pela(s) classe(s) parte. Na
figura abaixo a classe X composta pela classe Y, o que quer dizer que a classe X
possui um objeto da classe Y, identificado por varY, que tambm o nome da relao.
A agregao representada por uma seta unindo as classes com um losango indicando a
classe todo.

Figura 42 - Exemplo de agregao


No exemplo da loja apresentado no captulo 2 a classe POS possui um objeto da
classe Produto chamado de oProduto e um objeto da classe Cliente chamado
oCliente. Estes objeto representam o produto que ser vendido e o cliente interessado
em compr-lo. O POS os utiliza para o processamento das aes de venda. Estes
objetos foram criados e transmitidos ao POS pela classe Loja, mas fazem parte da
classe POS e por isso so representados como uma agregao onde o todo o POS e
as partes so oProduto e oCliente. Supondo, por hiptese, que o POS venha a ser
desligado, os objetos da venda que no foi ainda concluda sero perdidos. Assim
tambm a lista de clientes e a lista de produtos fazem parte da Loja. Supondo que a loja
seja vendida, o novo dono recebe tambm a lista de clientes e a lista de produtos, eles
so indissociveis. No exemplo, as listas de clientes e de produtos so fortemente
dependentes da Loja. Sendo este o fator determinante na deciso na modelagem deste
relacionamento como uma agregao.

Figura 43 - Exemplo de Associao entre Classes


Pode-se considerar a agregao como um caso especial da associao, onde h um
vnculo maior entre as classes. Este vnculo pode crescer a ponto de uma classe
depender existencialmente da outra. O que significa dizer que se a classe todo deixar de
existir, as classes partes deixam tambm de fazer sentido para o sistema. Na
associao, as classes se mantem independentes, isto , elas podem participar de outras
associaes no projeto onde no haja esta depedncia e podem ser instanciadas
isoladamente.

4.2.5.

Herana

Um tipo de relacionamento importante para o desenvolvimento de sistemas


orientados a objeto a herana. O conceito de herana tambm foi apresentado no
captulo 2 e se caracteriza por criar uma hierarquia entre as classes do sistema. Nesta
hierarquia, algumas classes, chamadas de superclasses, servem de matriz para a criao
de outras classes, as subclasses, que especializam as superclasses originais.
Constri-se uma hierarquia de generalizao-especializao indo de superclasses
mais gerais para subclasses mais especficas. Ao se especificarem, as subclasses
aproveitam tudo o que j foi definido pelas superclasses pela herana. As subclasses
herdam atributos, operaes e relacionamentos da classe me, mas podem modificar o
material herdado, sobrescrevendo os atributos e operaes ou criando novos atributos
ou operaes.
A herana representada por uma linha unindo as classes com um tringulo
indicando a superclasse. No exemplo da loja do captulo 2 a classe Cliente
superclasse para a classe ClienteVIP, como mostra a figura.

Figura 44- Classes Cliente e ClienteVIP com operaes e atributos


A classe ClienteVIP herda da classe Cliente todos os atributos e todas as
operaes como a setCGC, getNome entre outras. Entretanto, a classe ClienteVIP
modifica a classe Cliente alterando a operao getCredito. Conforme as regras no
negcio o crdito do ClienteVIP possui o dobro do crdito do Cliente. A figura mostra
as classe com as operaes sobrescritas e a tabela mostra a diferena entre a
implementao das duas operaes.

A implementao das operaes getCredito() apresentadas acima foram foram


escritas na linguagem Java, e retornam um valor inteiro referente ao crdito do cliente,
armazenado no atributo credito. A referncia super.getCredito() na implementao da
classe ClienteVIP indica que ser usada a operao getCredito() da
superclasse Cliente, que multiplicado por dois, como manda a regra de negcio.

Operao getCredito do Operao getCredito do


[4]
Cliente
ClienteVIP

public int getCredito()

{
return(credito);
}

public int getCredito ()

return
(2*super.getCredito());
}

A herana uma forma eficiente de distribuio de funcionalidades. As subclasses


dispem de todas as funcionalidades que as superclasses oferecem. Assim a criao
de um modelo orientado a objetos um processo de classificao, busca-se criar uma
hierarquia de classes que compartilhem as operaes umas das outras.
No exemplo, importante notar que uma classe ClienteVIP tambm uma classe
Cliente, e pode ser usada sempre que uma classe cliente puder ser aplicada. Por
exemplo, a lista de clientes comporta as classes Cliente e ClienteVIP. A definio das
classes foi feita quando do carregamento das classes ao iniciar o sistema.

4.3.

A tcnica dos cartes CRC

Uma das maiores dificuldades enfrentadas por quem est iniciando na tcnica da
orientao a objetos encontrar as classes. desejado sempre manter uma boa
correspondncia entre o modelo conceitual e o domnio do problema, e tambm uma
grande estabilidade dos conceitos expressos pelas classes. No entanto, as classes so
conceitos abstratos e as vezes de difcil compreenso por parte da equipe de projeto,
ainda mais por parte de clientes que por alguma razo devem estar envolvidos nesta
fase do projeto de software. Pode-se partir do modelo de contexto, j validado, que
delimita o sistema sob o ponto de vista funcional, para tentar extrair deste modelo os
conceitos fundamentais do sistema capturados pelas classes, mas o trabalho ainda assim
no dos mais simples.
A proposta da tcnica dos cartes CRC tornar o conceito abstrato das classes em
algo concreto e manipulvel pelos analistas, tornar a identificao das classes um
processo interativo com a participao efetiva dos usurios. A idia, proposta por
Beck e Cunnigham (1989), utiliza cartes de papel, muito utilizados em bibliotecas,
para representar as classes e organizar um trabalho em equipe para identificar e
descrever as classes de um sistema.
A modelagem CRC uma tcnica muito efetiva para identificar e validar os
requisitos dos usurios. Ele pode ir de mo em mo como os use case e os prottipos,
e conduz diretamente ao modelo de classes. O objetivo do desenvolvimento de
aplicaes resolver problemas de negcio, e no satizfazer a curiosidade
intelectual dos desenvolvedores que s querem brincar com novos brinquedos.
Trabalhe com os seus usurios, e no contra eles (Scott Ambler, 1998)

Figura 45- Exemplo de Carto CRC

4.3.1.

Histrico do carto CRC

Os cartes CRC foram introduzidos por Kent Beck e Ward Cunningham em 1989 na
[5]

OOPSLA . A tcnica atraiu a ateno da comunidade por ser uma tcnica de fcil
aplicao para um problema difcil, que o de descobrir e definir classes. No livro
Rebecca Wirfs-Brock (1991) detalhou o processo dos cartes que se tornou conhecido
como a tcnica de projeto por responsabilidades. Nancy Wilkinson (1995) publicou
sobre suas experincias com CRC na AT&T. Bellin (1997) oferece uma viso
abrangente da tcnica e da sua aplicao. Mais recentemente Kent Beck (1999) referese novamente tecnica dos cartes CRC nas fases de modelagem da aplicao do seu
mtodo XP (eXtreme Programming) de desenvolvimento rpido.
[6]

A palavra CRC uma abreviao para :Classe, Responsabilidade e Colaborao,


conceitos bsicos da modelagem orientada a objetos. Os cartes de CRC so cartes de
ndice muito utilizados em arquivos e bibliotecas, que so utilizados para registrar as
classes sugeridas, as coisas que elas fazem, e as relaes com as outras classes.
Enquanto se escreve o nome da classe, pode-se pensar no que aquela classe deve saber
de si mesma (responsabilidade de conhecimento) e o que ela deve saber fazer
(responsabilidade de comportamento), pode-se ainda ver como a classe que se est
definindo se relaciona com as outras classes no sistema. Pode-se ver como a idia de
encapsulamento e polimorfismo so reforadas, ao se mover uma responsabilidade de
uma classe para outra e criar uma colaborao.
Os cartes foram criados para dar uma resposta necessidade de documentar as
decises do projeto colaborativo. Projetar com cartes tende a progredir a modelagem
do conhecido em direo ao desconhecido, em oposio abordagem top-down de
decomposio usada na anlise funcional. Os cartes de CRC representam
expcitamente mltiplos objetos ao mesmo tempo. Entretanto, ao contrrio de
simplesmente acompanhar os detalhes da colaborao na forma de envio de mensagens,
os cartes CRC colocam o projetista no foco da motivao para colaborao
representando, potenciamente, muitas mensagens com frases em linguagem natural.
(Beck e Cunningham, 1989)
A natureza visual dos cartes de CRC um importante catalisador para a soluo do
problema. Ao mover um carto sobre a mesa pode-se obter novas idias da equipe de
projeto. Talvez mais importante que as tarefas bsicas, os cartes ajudam na soluo
dos problemas porque favorecem o trabalho em equipe.

4.3.2.

Vantagens do trabalho em equipe

Necessitamos de uma ferramenta que nos ajude a resolver problemas. Um


resolvedor de problemas trabalha com alternativas, se uma delas escolhida porque
um nmero maior de associaes lgicas levaram a esta escolha. Quando um grupo de
pessoas esto tentando resolver um problema, eles esto engajados em um processo que
leva a uma associao lgica. As ferramentas que suportam e facilitam este tipo de
soluo de problemas so valiosas. A ferramenta projetada para ser um catalizador
de novas idias, a equipe deve ser ao mesmo tempo paciente e aberta a novas idias. Se
a tcnica for usada somente como um meio para anotar as idias velhas, a chance de um
insight, de uma nova idia est drasticamente reduzida. Quanto mais se entende como
trabalhar em equipe, mais chance de se ter de um sucesso na soluo.
Estudos mostram que um grupo ter mais chance de sucesso na soluo de um
problema se este grupo for treinado na lgica de soluo do problema antes de ser
apresentado ao problema. As pessoas que esto concientes sobre a sua estratgia de
soluo de problemas vo melhores do que aquelas que dependem de uma resposta
insconsciente ou da sorte. Isso significa que o grande poder do uso dos cartes CRC
est na equipe de desenvolvedores que no somente sabe o que eles deve fazer, mas
tambem sabem como resolver problemas complexos. Por isso, recomenda-se uma
abordagem de aplicao da tcnica dos cartes CRC que envolvem duas estatgias para
facilitar a soluo de problemas: brainstorm e interpretao. (role play).

4.3.3.

Objetivos dos cartes CRC

A tcnica dos cartes CRC tem como principal objetivo o de facilitar o trabalho de
indentificao das classes de um sistema e das suas inter relaes principais. Ao
mesmo tempo, a tcnica serve como meio para o aprendizado da prtica da modelagem
orientada a objetos e para o ensino dos conceitos envolvidos. Sendo uma tcnica de
fcil utilizao, ela incentiva o envolvimento dos usurios no processo de anlise e
projeto dos sistemas.
Os fundamentos da tcnica dos cartes CRC so os mesmos fundamentos da
orientao a objetos, e sero revisados aqui. Considera-se que os sistemas sejam
formados por objetos, categorizados em classes. As classes encapsulam atributos e
operaes que caracterizam responsabilidades que os objetos devem executar para o
sistema. A anlise orientada a objetos deve identificar estas classes e distribuir entre
elas as responsabilidades identificadas no levantamento de requisitos do sistema. Para
cumprir integralmente as suas responsabilidades, as classes podem contar com a ajuda
de outras classes.
A tcnica dos cartes CRC procura responder s perguntas:
Quais so os componentes (Classes) do sistema ?
O que cada um deles deve fazer (Responsabilidades) ?
Como eles trabalham em conjunto (Colaborao) ?
As respostas estas perguntas so registradas em um carto como na figura:

Figura 46 - Estrutura de um carto CRC

Uma classe de um sistema orientado a objetos cumpre parte das


responsabilidades do sistema, e confia em outras classes para ajud-la a completar sua
misso no sistema. Cada classe representada por uma carto CRC, com o nome da
classe ocupando a linha de topo do carto. Parte-se de requisitos do sistema,
previamente levantados, que so transformados em responsabilidades nas classes. As
responsabilidades so listadas esquerda do carto, e eventuais colaboraes de
outras classes para aquela responsabilidade direita.
Ao mesmo tempo que um modo eficaz para se anotar informao sobre classes, os
cartes CRC criam um motivo para as pessoas envolvidas com o problema se
agruparem para trocar idias. uma tcnica infomal que reduz o conflito e amplia a
socializao no desenvolvimento de software. Um dos elementos fundamentais para o
sucesso de projeto de software o trabalho em equipe e o aprendizado ativo. Ao
contrrio de ler um relatrio de outra pessoa, uma equipe de CRC est sempre fazendo
algo que contribui para o modelo do sistema, isto , eles esto sempre aprendendo
alguma coisa. (Bellin, 1997)

4.3.4.

Organizao para aplicao da tcnica

Baseado em Bellin (1997) prope-se uma organizao para aplicao da tcnica,


apresentada aqui para ser aplicada aps a modelagem de contexto em um processo de
desenvolvimento de um sistema. O mtodo organizado nas seguintes etapas:
1.

Formao da equipe de trabalho,

2.

Uso de brainstorm para descrio dos requisitos do sistema,

3.

Identificar classes candidatas,

4.

Analisar os requisitos

5.

a.

Identificar e Distribuir as responsabilidades,

b.

Caracterizar os colaboradores, e

c.

Simular a dinmica do cenrio, validando o modelo.

Traduo dos cartes em modelo conceitual de classes

Figura 47 - Esquema da aplicao da tcnica de CRC

4.3.5.

Formao da equipe de trabalho

Uma das principais vantagens do uso dos cartes CRC a integrao dos usurios
no processo de modelagem do software. Para explorarmos esta possibilidade
necessrio criar uma equipe de trabalho composta de analistas e usurios. Uma boa
proporo a de um analista ou desenvolvedor para cada usurio especialistas no
problema em estudo. importante manter pequena a equipe pequena, entre 5 a 6
pessoas, o que leva a se compor a equipe com 2 a 3 analistas e 2 a 3 usurios. Um
analista deve fazer o papel de facilitador e atuar como coordenador dos trabalhos,
cuidar da agenda e da infra-estrutura para apoiar a reunio de trabalho.
Entre os analistas deve haver pelo menos um especialista em modelagem orientada a
objetos, que deve orientar os questionamentos e tomar as decises relativas
representao das classes. Alguem deve, durante a reunio, assumir o papel de
secretrio da reunio e fazer os registros necessrios.
O quadro abaixo pode ajudar na formao das equipes de modelagem.

Reunio CRC
Projeto:_______________ Usurio Usurio Usurio Usurio Analista Analista Analista
Local:_________________ 1
2
3
4
1
2
3
Data:____/ ____/ _____
Especialista do Problema
Especialista em Objetos
Coordenao
Facilitador
Secretrio
Agenda
Material de Apoio
Coffe break
Outros
As reunies devem ter uma agenda definida com antecedncia, e devem ser
precedidas sempre com um breve reviso da figura do carto e da tcnica que se est
aplicando, esta introduo visa garantir que todos tenham um entendimento, ao menos

superficial, sobre o mtodo. Os cartes devem ser sempre escritos utilizando a


terminologia do usurio. Para explicar termos tcnicos e pouco comuns pode-se criar
um glossrio de termos que ser til para os desenvolvedores terem uma melhor
compreenso do significado dos cartes.
Durante as reunies deve-se manter baixo o nvel tecnolgico, isto , deve-se evitar
o uso de computadores e programas de modelagem. Com eles corre-se o risco de
aumentar a distncia entre os usurios, que no tem familiaridade com estes meios, e os
analistas. Entretanto, o uso de prottipos e rascunhos de telas e relatrios podem ajudar
a mostrar para os usurios as possibilidades de implementao dos cartes. Na maioria
dos casos uma nica reunio no ser suficiente, o que d a oportunidade para a
preparao do material nos espaos de tempo entre os encontros. Se no houverem
reunies produtivas o desenvolvimento pode tornar-se demasiadamente lento. Portanto,
para ter uma reunio mais dinmica e produtiva:
Organize os cartes e os prottipos entre uma reunio e outra,
Inicie a reunio revisando o que foi obtido na reunio anterior,
Encerre a reunio resumindo o que foi discutido at aquele ponto,
Ao final, agende uma nova reunio, se necessrio.
Divulgue os resultados da reunio o mais rpido possvel.

4.3.6.

Brainstorm para especificao do sistema

O brainstorm uma estratgia utilizada para levantar os requisitos de projeto em


um trabaho em equipe, que tem sido usada em vrias equipes de trabalho, desde
equipes de publicidade at grupos de teatro. Quando uma equipe de analistas se prope
a trabalhar em um sistema, a troca de idias de um modo rpido e desinibido, como
deve ser no brainstorm, pode levar a um resultado melhor do que o trabalho individual.
(Bellin; Simone, 1997)
O modelo de contexto oferece uma descrio dos objetivos dos casos de uso para
dar a partida para a modelagem conceitual. Mesmo quando no existe material para dar
incio modelagem pode-se utilizar do brainstorm com a equipe de projeto para
detalhar a descrio funcional do sistema. O brainstorm uma tcnica til at mesmo
para a elaborao do prprio modelo de contexto.
Uma reunio para modelagem do sistema se inicia com uma descrio deste sistema.
Esta descrio pode partir da leitura do modelo de contexto, ou na inexistncia deste,
do material disponvel sobre o problema. Na reunio de trabalho a participao de
todos deve ser estimulada. O objetivo desta etapa do trabalho levantar as
funcionalidades que o sistema deve possuir para atender os seus usurios. A
experincia dos especialistas importante pois deles o conhecimento das
necessidades reais a serem atendidas. importante um papel de questionamento, por
parte dos analistas, para obter um modelo completo e preciso. A palavra, em uma
reunio de anlise, deve ser dada a todos. Pode-se registrar tudo em um gravador, mas
como a transcrio deste material difcil, prefervel registrar a reunio, diretamente,
em papel.
No decorrer do brainstorm se contri uma descrio do sistema na forma de uma
lista organizada de requisitos. O produto final da etapa do brainstorm esta descrio
refinada pela anlise, discusso e ponderao da equipe de projeto. O papel do
facilitador e do secretrio so essenciais na elaborao da lista de requisitos, quando
alguns dos requisitos listados podem ser retirados, assim como novos requisitos podem
ser includos.

4.3.7.

Identificar as classes candidatas

De posse da lista de requisitos obtidas pelo brainstorm, e da descrio dos casos


de uso do modelo de contexto possvel iniciar a procura pelas classes. As classes
definem um nvel de abstrao do problema. Como regra geral, as classes aparecem
como sujeitos nas aes listadas nos requisitos. Analisando, por exemplo, os requisitos
abaixo:

O cliente pede emprstimo;


O pedido possui um prazo previsto para entrega.

identificam-se : cliente e pedido como conceitos importantes e candidatos se


tornarem um carto e portanto uma classe.
Essa no a nica fonte de classes. As classes podem estar nos documentos e
relatrios do sistema, nos papis dos personagens envolvidos nas aes, assim como
em qualquer outro elemento importante que guarde alguma informao, ou que tenha
alguma ao no problema estudado.
Uma grande barreira na modelagem a tendncia em se manter preso aos mesmos
modos de ver o mundo. O analista habituado a uma abordagem funcional ou de dados
tem a tendncia a continuar pensando em termos de bancos de dados e funes, e ser
mais difcil ver as classes, e se utilizar das vantagens da orientao a objetos. Analisar
um conjunto qualquer de letras para identificar as palavras que podem ser formadas,
mais fcil, as vezes, criar uma palavra nova, se as letras no formarem uma palavra
evidente. Pode-se ficar olhando as letras e no ver as palavras. Assim, para ter
sucesso no encontrar e dar nomes s classes, usando os cartes CRC, deve-se treinar o
olhar.
Deve-se ter um cuidado especial ao dar nomes para as classes. Os nomes devem ser
significativos e bem especficos, extrados do contexto do problema. Uma boa prtica
evitar nomes genricos demais como: sistema, usurio, controlador e operador. A
menos no ser, claro, que estes nomes tenham um significado prprio no domnio do
problema estudado. O nome da classe e de um objeto criam um vocabulrio para se
discutir o projeto. Beck e Cunnigham observam que o projeto de objetos tem mais em
comum com uma linguagem de projeto do que com a programao procedural.

imperativo que se encontre um conjunto significativo de palavras para descrever o


objeto, um conjunto que seja consistente e representativo do ambiente de projeto.
(Beck, 89)
Os exemplos abaixo mostram como criar palavras mais representativas unindo
expresses dos diversos domnios de projeto,
Ambulatrio, Enfermaria, PronturioMdico
PassagemArea, Balco, Bagagem, Avio
FichaDePresena, RelogioDePonto
Nem sempre identificar objetos simples e intuitivo. Particularmente em grandes
aplicaes classes mais genricas podem gerar classes mais especficas cuja seleo
adequada um dos segredos do sucesso da boa modelagem. O uso de tcnias como o
CRC podem ajudar a testar e revisar diferentes diagramas de classe durante as fases de
projeto. Nenhuma tcnica, entretanto, substitui a investigao, as entrevistas e a
experincia em campo.

4.3.8.

Analisar os resquisitos

Identificado um conjunto de classes candidatas, passa-se a avaliar os cenrios


descritos nos requisitos. Cada cenrio representa uma responsabilidade que o sistema
deve assumir, que devem ser distribudas entre as classes, na forma de atributos e
operaes. No cumprimento de uma funo uma classe pode chamar outras para ajudla, caracterizando assim uma colaborao entre elas.
A dinmica desta tcnica a seguinte: escolher um cenrio, imaginar e simular a
lgica do processo, distribuir as responsabilidades determinando o carto que deve
cumprir esta responsabilidade, atualizar o carto sempre que necessrio, colaborar com
outras classes se for preciso.

4.3.9.

Distribuir as responsabilidade

A responsabilidade de uma classe uma funo que o sistema exige que a classe
cumpra. Tais funes so decorrentes dos objetivos listados pelos usurios (atores),
nos requisitos do modelo de contexto.A responsabilidade algo que uma classe sabe ou
faz. O que a classe sabe est expresso nos seus atributos, e o que a classe sabe fazer
so funes que a classe oferece ao sistema.
Responsabilidades expresso aes que identificam problemas a serem resolvidos.
As solues existiro no interior da implementao destas aes. Uma
responsabilidade serve para levar discusso das potenciais solues. Quanto mais se
puder exprimir com essas frases, mais poderoso e consiso ser o projeto. Aqui tambm
encontrar as palavras certas um valioso uso de tempo no projeto (Beck, 1989). Em
geral, as responsabilidades so expressas por uma srie de frases verbais curtas, cada
uma contendo um verbo de ao e algum objeto, como mostam os exemplos abaixo:
Fazer Pedidos
Definir o preo
ConsultarViagens
Calcular salario
Se um requisito pedir por uma responsabilidade ainda no coberta por nenhuma das
classes, pode-se adicionar a responsabilidade em uma das classes existentes ou,
excepcionalmente, criar uma nova classe para receber esta responsabilidade. Anota-se
a responsabilidade em uma linha do carto, como j mostrado nas figuras. O nmero
limitado de linhas do carto proposital, porque se uma das classes se torma muito
complexa, durante este processo, copia-se a informao deste carto em um outro
carto procurando meios mais concisos de representar o que o objeto deve fazer. Se
ainda assim a classe continuar complexa, identifica-se uma nova classe para assumir as
responsabilidades, se no existir pode-se criar uma nova classe.

4.3.10.

Caracterizar os colaboradores

Uma classe incapaz de cumprir sozinha todas as responsabilidades de um sistema.


No cumprimento de uma responsabilidade que lhe foi atribuda, ela pode solicitar a
colaborao de outras classes. Isso quer dizer que em algum ponto do cumprimento da
sua funo, a classe invoca uma outra responsabilidade da classe colaboradora. Este
fato indicado no carto se escrevendo o nome da outra classe ao lado da
responsabilidade.
A existncia da colaborao prpria da natureza dos objetos, e do fato que nenhum
objeto uma ilha isolada, mas faz parte de um sistema. Os objetos se relacionam uns
aos outros e criam as redes de colaborao. Colaboradores so os objetos para os
quais se envia mensagens para satisfazer uma determinada responsabilidade. Um objeto
pode colaborar com vrios outros, e no possuir nenhum colaborador. Assim como
alguns objetos podem exigir muitos colaboradores e no colaborar com nenhum outro
objeto.
Supondo que exista uma classe Pedido, que armazenda os dados de um pedido de
compras, em resposta a um requisito do tipo:
... o preo do pedido deve ser estimado com base na lista de produtos ...
Representa-se na modelagem de um cenrio foi atribuda a esta classe a
responsabilidade EstimarPreco da classe pedido, que calcula o preo estimado do
pedido com base no preo de cada produto, individualmente. Para isso, a classe Pedido
pede a colaborao da classe Produto, que possui a responsabilidade CalcularPreco,
que calcula o preo do produto com base na quantidade a ser adquirida e no preo
unitrio, tambm presente na classe Produto. Estas relaes so representadas nos
cartes CRC como mostra a figura:

Figura 48 - Exemplo de colaborao entre cartes CRC

Ao final da anlise dos cenrios, tem-se cartes ricos em responsabilidades e


colaboraes. Cada carto representa um elemento importante do sistema e a unio
destes cartes representa, conceitualmente, o sistema a ser constudo. Pode-se ainda,
validar o sistema simulando a dinmica de cada cenrio, para saber se a distribuio de
funcionalidades e as colaboraes so adequadas e suficientes.

4.3.11.

Simular a dinmica do cenrio

Na simulao do sistema, cada participante da reunio, desenvolvedor ou cliente,


assume o papel de alguns cartes enquanto se executa o cenrio. Semelhantemente a um
teatro, os projetistas assumem o papel das classes e respondem aos estmulos externos
como aquela classe responderia.
Uma boa estatgia para dar incio simulao arranjar os cartes adequadamente
sobre a mesa. Esta viso espacial dos cartes muito valiosa, pois ela ajuda a
identificar um projeto ainda incompleto ou ainda pouco entendido. A relao espacial
permite destacar famlias de classes, e grupos de classes que devem atuar em conjunto,
ou at mesmo a necessidade de uma colaborao maior entre duas ou mais classes.
A possibilidade que os cartes CRC oferecem de manipular as classes, antes
abstratas, e agora concretizadas nos cartes, muito importante para o analista e,
especialmente, para os usurios. Pode-se olhar os cartes envolvidos em um cenrio e
tentar ver o que eles tem em comum. Pode-se tentar rearranjar estruturas atuais em uma
nova estrutura. Os cartes CRC no iro fazer este trabalho para o analista, mas ao
focar as classes, usando a linguagem das classes eles podem ajudar a descobrir o que
crtico para o sucesso de um sistema orientado a objetos.
Beck e Cunningham (1989) reforam ainda a importncia em no se criar objetos
para atender necessidades futuras do sistema, mas somente para atender as
necessidades do presente, expressas nos requisitos dos cenrios. Isto garante que o
projeto contm apenas a quantidade de informao que o projetista apreendeu, e evita
uma complexidade prematura. Pode-se organizar o trabalho em equipe para evitar que
isto ocorra. Seleciona-se um projetista para sugerir novos cenrios destinados,
especificamente, a localizar falhas, fraquezas e omisses do sistema proposto.

4.3.12.

Traduzindo os cartes em classes UML

Ao final da aplicao da tcnica CRC o analista tem nas mos um conjunto de


cartes que representa conceitualmente o sistema. O destino dos cartes depende do
mtodo adotado. Dando seqncia abordagem de modelagem proposta aqui, os
cartes devem ser traduzidos em classes na notao da UML. O diagrama de classes, ao
final desta traduo o modelo conceitual do sistema. Este processo uma traduo
porque apenas a linguagem est sendo alterada, no acrescida nenhuma nova
informao na representao do novo modelo.
A traduo segue as seguintes regras:
1.

Para cada carto cria-se uma classe,

2.

O nome do carto o nome da classe,

3.

As classes podem ter superclasses que so representadas no modelo.

4. As responsabilidades atribudas a cada carto so traduzidas em atributos


ou operaes:
a. As responsabilidades que esto associadas ao armazenamento de uma
informao da classe so traduzidas em atributos, e
b. As responsabilidades que esto associadas a aes que a classe deve
executar para o sistema, so traduzidas em operaes.
5. Havendo colaboraes entre duas classes uma indicao que pode haver
algum tipo de relacionamento entre as classes. O tipo de relacionamento ir
depender, a critrio do projetista, da forma como sero implementadas as
colaboraes.

4.3.13.

Vantagens da tcnica dos cartes CRC

Uma das maiores vantagens da aplicao da tcnica dos cartes CRC em projetos
de software que com um pequeno investimento em treinamento, tem-se os especilistas
de uma rea fazendo a anlise e descrevendo o software e usando efetivamente o
paradigma de objetos. Esta descrio no meramente um relato mas sim um modelo
conceitual consistente do sistema.
Uns poucos minutos de introduo suficiente para preparar a audincia para
uma apresentao baseada em cartes. Os cartes podem ser feitos antecipadamente
ou escritos na hora. Esta ltima forma permite que a complexidade do projeto seja
revelada aos poucos. Os cartes esto sendo usados como meio para contar a
histria do processamento. Os cartes permitem contar esta histria sem o recurso
da linguagem de programao, sua sintaxe ou idioma.(Beck,89)
Resumindo, a tcnica dos cartes CRC:
um mtodo eficiente para localizar objetos,
Favorecem ao entendimento do mtodo orientado a objetos,
uma ferramenta de anlise e projeto usada nas fases iniciais,
Que pode ser apresentada a usurios,
Incentiva a integrao com os usurios e especialistas na anlise,
simples e direta e no assusta os usurios
barato e portvel,
Pode ir de mo em mo como um prottipo e
Leva diretamente a um diagrama conceitual de classes.

4.4.

Estudo de Caso: Jogo da Forca

Para exemplificar a aplicao da tcnica dos cartes CRC desenvolve-se aqui o


modelo conceitual do jogo da forca. Este jogo tem a vantagem se ser bem conhecido
por todos, o que permite que qualquer um possa ser considerado um especialista do
assunto, propor e analisar as suas funcionalidades.
Segue uma breve descrio de um jogo da forca computadorizado, que serve como
um exemplo do que o analista receberia como uma primeira tentativa do cliente em
descrever seu negcio:
No jogo da forca em computador, o jogador desafiado a descobrir as letras que
formam uma palavra secreta, escolhida automaticamente pelo computador. A cada letra
errada, sugerida pelo jogador, ele perde uma parte do corpo: cabea, tronco e
membros, desenhada no boneco na forca. Ao se desenhar todas as partes deste boneco,
o jogador perde o jogo enforcado. Por outro lado, ao acertar todas as letras e descobrir
a palavra secreta, o jogador vence o jogo. Deseja-se desenvolver o modelo
conceitual orientado a objetos deste jogo para se construir um programa de
computador que seja executado na internet. A figura abaixo ilustra esta descrio:

Figura 49 - Esquema tpico do jogo da forca.


O desenvolvimento do modelo conceitual do jogo da forca dividido na fase de
brainstorm, na seleo de classes, e distribuio de responsabilidades entre o conjunto

de cartes. O modelo conceitual do jogo da forca, representado pelo diagrama de


classes, obtido traduzindo-se os cartes em classes na notao da UML.

4.4.1.

Modelo de Contexto

O modelo de contexto objetiva organizar em um modelo a descrio


informal apresentada anteriormente. Neste exemplo, apenas o jogador um ator, que
possui como grande objetivo o de jogar a forca. O jogo da forca representado por um
sistema, que interage com este ator, como mostra a figura:

Figura 50 - Representao do sistema de forca com uso de um pacote

Diagrama de Casos de Uso


O modelo de contexto do jogo da forca representado pelo diagrama de casos de
uso e pela descrio textual de cada caso de uso. Para aumentar o detalhamento do
modelo, divide-se o objetio de jogar a forca contra o computador em dois objetivos no
sistema: iniciar um novo jogo e chutar letras para adivinhar a palavra secreta. Optou-se
por representar a lista de palavras como um ator, porque ela pode ser considerada
como um elemento imutvel, externo ao sistema. Esta situao representada pelo
diagrama:

Figura 51 - Diagrama de Casos de Usodo Jogo da Forca

Ator: Jogador
representa os jogadores (usurios) do sistema de jogo da forca.

Ator: Lista de Palavras


representa a lista de palavras armazenadas para alimentar o jogo. um ator
passivo, imutvel, que s fornece informaes.

Casos de Uso: Novo Jogo


Objetivo principal
Um novo jogo da forca em computador,exige que se selecione uma palavra secreta
escolhida automaticamente de uma lista de palavras j existente.
Cenrio de exceo
A lista de palavras no existe ou no pode ser encontrada, impedindo a
continuidade do jogo.

Caso de Uso: Chutar Letras


Objetivo principal:
O jogador chuta letras para tentar acertar a palavra secreta.
Cenrio alternativo 1
A cada letra errada, ele perde uma parte do corpo do boneco. Ao completar todas
as partes do corpo do boneco o jogador perde.
Cenrio alternativo 2
A cada letra certa a palavra vai se desenhando na tela. Ao descobrir todas as
letras e descobrir a palavra secreta, o jogador vence o jogo.

4.4.2.

Modelo Conceitual

O desenvolvimento do modelo conceitual do jogo da forca segue a proposta dos


cartes CRC se divide na fase de brainstorm, na seleo de classes, e distribuio de
responsabilidades entre o conjunto de cartes CRC. Como resultado da aplicao desta
tcnica, tem-se um modelo conceitual do jogo, representado pelo diagrama de classes,
que obtido da traduo dos cartes em classes representadas pela UML.

Brainstorm
A obteno de uma listagem das funcionalidades previstas para o jogo da forca vem
de um estudo das diversas aes executadas durante uma partida. Pode-se considerar
que o jogo da forca uma disputa entre um jogador e uma palavra selecionada pelo seu
oponente, neste caso, o computador. Na lista de funcionalidades abaixo o computador
representado pela classe Forca. As aes que se seguem reproduzem um jogo tpico,
entre a forca e o jogador.
O jogo da forca possui uma lista 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 letra da palavra,
O jogador deve saber as letras que j foram chutadas,
Se a palavra possuir a letra estiver a letra desenhada,
Se a palavra no possuir a letra, uma parte do boneco desenhada,
Se a letra a crescentada na lista de letras erradas se no estiver 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 funcionalidades acima mostra que as aes so comandadas
pelos seguintes elementos:
Forca
Jogador
Palavra

Boneco
E que por isso so candidatos a classes deste sistema. Estas escolhas se
confirmaro com a distribuio das responsabilidades, realizada a seguir.

Distribuio das Responsabildiades


Cria-se um carto para cada classe e passa-se a analisar as funcionalidades
identificadas, uma a uma:
O jogo da forca possui uma lista de palavras secretas armazenda,
Esta funcionalidade identifica que o jogo da forca possui, internamente, uma lista
de palavras que usa para desafiar o jogador. Escolhe-se a classe Palavra para ter como
responsabilidade guardar esta lista de palavras:
O jogador inicia um novo jogo,
A Forca escolhe uma palavra da lista
Uma Forca vazia desenhada
A responsabilidade de iniciar um novo jogo, que solicitada pelo jogador humano,
atribuda Forca, que faz a interface com o usurio e controla o incio do jogo.
Iniciado o jogo, a forca seleciona, automaticamente, uma palavra da lista, e desenha a
forca vazia e o nmero de letras da palavra onde o jogo ser desenvolvido. A palavra
desenhada com espaos indicando as letras. Para desenhar a palavra e o boneco a
Forca usa mtodos apropriados das classes Palavra e Boneco. Este mtodos so
dependentes da tecnologia empregada para a interface.
O jogador chuta uma letra da palavra
A classe Forca faz a interface com o usurio recebendo a letra sugerida pelo usurio
que ir process-la. A classe jogador tem a responsabilidade de avaliar a letra chutada
e para isso usa a classe Palavra para ajud-la, j que s a classe Palavra conhece os
detalhes da palavra escolhida.

Figura 52 - Exemplo do incio da definio do carto Forca


A figura acima mostra o carto da Forca at este momento do estudo. A seguir d-se
prosseguimento ao processo de distribuio das responsabilidades:
O jogador deve saber as letras que j foram chutadas
A responsabilidade de chutar uma letra atribuda ao Jogador, que tambm guarda
as letras j chutadas.
Se a palavra possuir a letra estiver a letra desenhada
Aqui temos duas responsabilidades: a de verificar se a letra est na palavra e a
desenhar a letra, que podem ser atribudas palavra, j que esta possui conhecimento
das suas prprias letras.
Se a palavra no possuir a letra, uma parte do boneco desenhada
Nesta responsabilidade vemos que quando a palavra verifica que a letra no est na
palavra ela precisa da ajuda do boneco, porque ser desenhada uma parte do boneco.
Assim atribui-se uma colaborao do boneco na palavra e a responsabilidade de
desenhar uma parte para o boneco. As partes do boneco devem ser guardadas na
prpria classe boneco, que deve sabe qual a parte (Cabea, tronco ou membros que ir
desenhar em seguida)

Se a letra a crescentada na lista de letras erradas se no estiver na


palavra
A lista de palavras erradas mantida pelo Jogador
Quando a palavra estiver completa o jogador ganhou
Quando o boneco estiver completo o computador ganhou
Aqui vemos que a classe palavra deve ter uma responsabilidade para saber se ela
est completa, assim como o boneco, que deve saber se ele est completo. Associadas
estas responsabilidades temos a funcionalidade do jogador em ganhar ou perder,
respectivamente. Representam-se as responsabilidades de ganhar e perder no carto da
classe Jogador, com a ajuda das classes Palavra e Boneco.

4.4.3.

Cartes CRC

Abaixo esto os cartes CRC resultantes da distribuio de responsabilidades.


Optou-se por manter o nome das responsabilidades prximo da descrio da
funcionalidade levantada na fase de brainstorm. Posteriormente, o nome das
responsabilidades sero traduzidos em nomes de operaes e atributos das classes e
podem se alterar.

4.4.4.

Traduo dos Cartes em Classes

Para construir o modelo conceitual, utilizando a notao da UML, deve-se traduzir


cada carto em uma classe, onde o nome do carto ser o nome da classe. Assim, para
o carto Boneco cria-se a classe Boneco, como mostrado na figura abaixo. As
responsabilidades descritas no carto so traduzidas em atributos e operao. Observase que a responsabilidade que corresponde a guardar as partes do boneco um atributo
(um dado) armazenado pela classe, assim cria-se o atributo parte na classe Boneco. As
outras duas responsabilidades correspondem a aes que a classe boneco tem que
executar: Verificar se o boneco est completo e Desenhar uma parte do boneco. Para
estas duas responsabilidades criam-se as operaes na classe Boneco:
bonecoCompleto e desenha, respectivamente. A figura abaixo compara o carto da
classe Boneco com a classe representada na UML.

Analogamente, so traduzidas as classes Forca, Jogador e Palavra. Nesta so


identificadas as responsabilidades que se transformam em atributos e as que se tornam
operaes. Ao dar os nomes para as operaes e atributos procura-se seguir as
restries das linguagens de programao evitando acentuao nas palavras, caracteres
especiais e espaos em branco na formao dos nomes. A tabela que se segue mostra a
correspondncia entre a responsabilidade descrita no carto e os atributos e operaes
nas classes:

O diagrama de classes deve refletir a comunicao entre os objetos. Deve-se


observar que de posse do diagrama de classes e da especificao das classes, descrita
no verso dos cartes, possvel se construir o sistema. Como este um sistema
simples, o modelo conceitual quase auto-suficiente. No entanto o programador dever
ainda tomar uma srie de decises de projeto na fase de implementao. O
programador deve decidir sobre uma srie de objetos auxiliares, em como ser
implementada a interface e como sero implementadas as comunicaes entre as
classes. O modelo detalhado, estudado no prximo captulo, ser utilizado para definir
mais precisamente os detalhes da implementao dos sistemas. No captulo 6 retoma-se
o jogo da forca, l se desenvolve o modelo detalhado que conduz implementao.

Figura 53 Diagrama de Classes Conceitual do Jogo da Forca

5. O Modelo Detalhado
Este captulo descreve tcnicas para construo dos modelos orientados a
objetos. Nele so descritos, em detalhe,os seguintes diagramas da UML: classes,
seqncia, colaborao, estados, atividades, componentes e distribuio. Estes
diagramas so apresentados como formas de descrever os detalhes da estrutura, da
dinmica interna e da construo de um sistema em componentes de software.

5.1.

Introduo aos modelos detalhados da UML

O desenvolvimento de sistemas de software apoiado em vises que evoluem com


o entendimento do problema e com a aproximao da fase de construo. Este captulo
leva o modelo do sistema ao seu nvel mais alto de detalhes. Apresenta-se aqui como
criar, a partir do modelo de contexto e do modelo conceitual das classes, uma viso
mais rica em detalhes e integrada do sistema de software com os diagramas da UML.
[7]

A OMG (2001) define a UML como Uma linguagem padronizada para


especificar, visualizar, construir e documentar todos os artefatos de um sistema de
software. uma proposta para unificar, em torno de uma notao padronizada, as
diversas representaes grficas dos sistemas de software. A ampla aceitao da UML
pela comunidade de desenvolvedores, e pela prpria indstria de software, uma
prova da sua fora e uma avaliao da sua importncia.Segue um breve histrico da
evoluo da notao, que til para compreeender o seu estgio atual de evoluo.

5.1.1.

Histrico da UML

Atualmente, qualquer projeto de software que decida pela orientao a objetos


como paradigma de desenvolvimento, dever ser representado pela UML assim
encontrar apoio em um grande nmero de ferramentas CASE disponveis no mercado.
A adoo de uma notao padronizada permite, entre outras vantagens, a separao
entre a anlise, o design e a construo. O contingente de pessoal tcnico treinado
cada dia mais numeroso, e a capacidade de se especificar, 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 anos 80, apesar da tecnologia a orientao a objetos
j ser bem conhecida, uma diversidade de metodologias e notaes procuravam
representar os sistemas de software orientados a objetos de diferentes formas. Ao se
iniciar um novo projeto de software era preciso selecionar um mtodo e, quase sempre
treinar uma equipe para utilizar aquela notao e poder desenvolver os modelos. A
falta de um padro criava um problema adicional para a difuso da tecnologia de
orientao a objetos. Dentre as muitas metodologias existentes, datacaram-se o OOSE
de Jacobson (1992), o OMT de Rumbaugh (1994) e o mtodo de Booch (1994).
Em 1993, Booch j estudava uma aproximao com o trabalho de Rumbaugh e
juntos, na empresa Rational, iniciam o esforo de unificao das duas metodologias. No
final de 1995, introduziram o conceito do UM -Unified Method - que se tornou em
seguida, aps a entrada de Jacobson na equipe, na UML - Unified Modeling Language
- com a separao entre a linguagem de modelagem e o processo de desenvolvimento.
Os esforos de Booch, Rumbaugh, e Jacobson resultaram, em 1996, na emisso da
verso UML 0.9 quando os autores convidaram a comunidade em geral para opinar. A
lista de tecnologia de objetos patrocinada pela Rational, a OTUG Object Technology
Users Group - foi um ambiente de aprendizado colaborativo e um grande motivador da
ampla adoo atual da UML. Os subsdios da discusso pblica pela internet criaram
as revises UML 1.0, e a 1.1 que, finalmente, foi submetida e aprovada pela OMG em
1997. A UML torna-se assim a linguagem oficial para modelar sistemas orientados a
objetos, e passa a ser gerenciada pela OMG, que a incorporou na sua sistemtica de
padronizao e revises.
A UML essencialmente uma linguagem de modelagem, definida por uma meta
linguagem, isto , a partir da UML podem ser geradas outras linguages coerentes com o
objetivo original de descrever um sistema orientado a objetos. A notao da UML
padronizada, e deve ser assim para poder descrever com preciso cada parte do
software, de forma nica e de um modo onde qualquer um, que conhea a UML, possa

ler o mesmo software. Por outro lado, o software uma tecnologia em evoluo, uma
notao que resistisse esta evoluo, estaria fadada ao insucesso. A dificuldade em
conciliar uma notao precisa, rigorosa e padronizada com uma notao que possa
evoluir com a tecnologia foram os maiores desafios enfrentados pela equipe de
desenvolvimento desta linguagem.
A UML o resultado de um processo de convergncia dos principais mtodos para
desenvolvimento de sistemas orientados a objeto existentes na primeira metade da
dcada de 90. Cada mtodo deu a sua contribuio para a formao da UML, sendo que
o resultado mais preciso e mais homogneo que as linguagens anteriores. Ela
consegue descrever os sistemas de forma mais abrangente, levando a modelagem mais
prxima da implementao. Possui elementos de expanso que permitem acomodar
novos sistemas, assim como novos elementos na modelagem.
Os objetivos inicias da UML, descritos pela OMG (2001), so:
Fornecer aos desenvolvedores uma linguagem de modelagem visual,
pronta para o uso no desenvolvimento e comunicao de modelos ricos em
significados.
Oferecer mecanismos de extensibilidade e especializao para ampliar os
conceitos principais.
Dar suporte especificaes de projeto independentes da linguagens de
programao e do processo de desenvolvimento.
Prover uma base formal para o entendimento de uma linguagem de
modelagem
Encorajar o crescimento do mercado de ferramentas de software
orientadas a objeto.
Dar suporte aos conceitos de desenvolvimento de alto nvel como
componentes, colaborao, frameworks e padres.
Integrar as boas prticas de projeto.
A UML especifica uma linguagem de modelagem que conseguiu o consenso da
comunidade de especialistas em orientao a objetos nos conceitos chave da
modelagem. Com a UML se capaz de atender os mais variados problemas de
modelagem atuais, de uma forma direta e econmica. Alguns problemas futuros
esperados, especialmente os relacionados com a tecnologia de componentes,
computao distribuda, frameworks e executabilidade j so abordados pela notao.
Com a UML, possvel a troca de modelos entre uma variedade de ferramentas, alm
da criao de repositrios para armazenagem e troca de modelos.
A notao da UML uma notao grfica, onde a descrio de um software feita

com smbolos grficos padronizados que se relacionam formando diagramas. Cada


diagrama apresenta uma viso parcial do sistema de software, e a unio dos diagramas
deve representar um nico sistema de software. Os diagramas so descritos por nomes
e termos padronizados, que compem um glossrio prprio de termos que tambm faz
parte da UML.

5.1.2.

Os diagramas da UML

Os modelos detalhados descrevem mais precisamente os fenmenos observados no


problema, assim como pemitem, encaminhar o sistema sua implementao em uma
linguagem de programao. Algumas metodologias preferem distinguir os modelos
desenvolvidos nas diversas fases, como modelo de anlise, modelo de projeto, modelo
de implementao e assim por diante. Aqui eles sero chamados apenas de modelos
detalhados, independentemente da sua finalidade.
O diagrama de classes, desenvolvido como modelo conceitual do sistema,
insuficiente para descrever todos os detalhes do projeto. Os cartes CRC mostram que
para se ter um sistema importante definir como as classes iro colaborar. Entretanto, a
colaborao, ainda pouco explorada neste modelo, e precisa ser detalhada para
considerar outros fenmenos presentes no sistema, descrever mais precisamente a troca
de mensagens entre as classes, assim como para acrescentar elementos importantes da
implementao.
O diagrama de classes traduz uma viso esttica, sem movimento, equivalente uma
foto do sistema, e por isso no permite avaliar caracterssticas dinmicas do
comportamento interno e externo da classe. Assim, necessrio desenvolver outras
vises da dinmica do problema, para descrev-lo com preciso. As vises dinmicas
e estticas do problema devem se integrar, e se complementar, para representar um
sistema passvel de ser contrudo.
O modelo detalhado de objetos, descrito neste captulo, formado pela reunio
destes diversos diagramas, que permitem observar o problema sob ngulos
particulares, e que exploram caractersticas importantes do problema estudado. As
vises utilizadas no modelo detalhado de objetos, so listadas a seguir e podem ser
organizadas como mostra a figura:

Figura 54 - Exemplo de navegao entre os diagramas da UML

A viso da estrutura de um modelo detalhado dado pelo diagrama de classes. As


classes, identificadas no modelo conceitual, formam a base sobre a qual so erguidos
os componentes do sistema. As classes mostram apenas uma viso esttica do sistema.
A viso dinmica complementar oferecida por um conjunto de diagramas de
interao entre as classes e pelo diagrama de estados. A interao entre as classes de
um sistema mostrada pelos diagramas de seqncia e diagrama de colaborao, que
representam as mensagens trocadas entre as classes. Os diagramas de estado mostram
o ciclo de vida de uma classe, representando a sua dinmica interna. Para serem
construdas, as classes podem ser agrupadas em componentes de software que so ento
distribudos pelos servidores. Estas situaes so descritas pelos diagramas de
componentes e de distribuio.
O modelo de contexto define o comportamento externo do sistema, que distribudo,
na modelagem conceitual, para as classes do sistema. Estas classes participam de
processos que podem ser modelados pelos diagramas de seqncia, atividades ou de
colaborao. Internamente, as classes tem seus ciclos de vida modelados pelo
diagrama de estados. Assim, o comportamento interno do sistema implementado nas
classes por suas operaes, forma a base das mensagens trocadas entre as classes,
assim como implementam as transies de estado em uma classe. A coerncia entre as
classes e suas operaes garantem a coerncia do modelo e do sistema como um todo.

Figura 55 - O analista e o modelo conceitual

Nos modelos de contexto e no modelo conceitual o analista se coloca em uma


posio de alguma distncia com relao ao sistema, para no perder a viso do todo.
J nos modelos detalhados, o analista deve se aproximar muito mais do sistema e das
suas partes para ver todos os detalhes. Estes detalhes so separados em caractersticas
estruturais, que so representadas nos diagramas de classes, caractersticas dinmicas
que podem ser representadas nos diagramas de interao e de estado, ou caractersticas
de implementao que so representadas nos diagramas de componentes ou de
distribuio.

5.2.

Diagrama de classes

O diagrama de classes, j introduzido no modelo conceitual, deve agora ser


detalhado para poder descrever com preciso o sistema a ser construdo. Os sistemas
orientados a objetos organizam-se ao redor de classes de objetos, que representam
tanto os elementos do domnio do problema, incorporados ao modelo, como os
elementos propostos para a implementao da soluo. O diagrama de classes
representa a planta baixa do sistema, estabelecendo uma relao entre os elementos do
problema e o cdigo que os implementa. Para implementar um diagrama de classes
necessrio que a linguagem de programao d pleno suporte orientao a objetos,
como a linguagem de programao Java, que ser utilizada como exemplo neste estudo.
As classes formam uma unidade que encapsula atributos e operaes. Uma classe
define um conceito importante para o problema e pode se relacionar com as outras. Mas
so os objetos, instncias das classes, que interagem nos programas, disparam
mensagens, podem at ser transmitidos em uma mensagem pela rede ou mesmo
armazendos em bancos de dados. A identificao das classes do sistema, sua
constituio e relacionamentos a essncia da modelagem orientada a objetos, e j foi
desenvolvida, em grande parte, com a modelagem conceitual no captulo anterior. Este
captulo detalha o diagrama de classes e todos as suas nuanas e o relaciona com os
diagramas dinmicos e de implementao, criando uma viso detalhada do sistema de
software.
Uma classe representada por um retngulo dividido em 3 partes onde se representa
o nome, seus atributos e suas operaes. Estas partes so apresentadas nos teros do
retngulo com maior ou menor quantidade de detalhes, em funo do grau de
abstrao desejado ou da fase de detalhamento do modelo, como mostram os exemplos
da figura:

Figura 56 - Exemplos de representao de classes

5.2.1.

Nomes

Dar nomes aos componentes de um modelo, como j foi dito, umas atividades mais
importantes da modelagem. Em um diagrama de classes devem ser escolhidos nomes
para as classes, atributos, operaes e tambm para as relaes. A escolha de um nome
adequado pode facilitar muito o entendimento do problema, enquanto uma escolha
incorreta de um nome pode tornar o modelo incompreensvel. Os nomes devem ter
significado para o domnio do problema em questo, descrevendo elementos
importantes do sistema e aproximando o modelo do problema real.
As classes devem ser nomeadas com expresses substantivas breves, iniciadas por
uma letra maiscula para que representem um nome prprio do vocabulrio do
problema em estudo. O nome da classe deve ser nico no mbito do subsistema que a
contm. O nome da classe deve ser escolhido de modo a ter um significado relacionado
com a sua responsabilidade do sistema. Assim, Funcionario, Livro, CartaoDePonto e
[8]

ProntuarioMedico so nomes adequados para classes.

Os atributos so nomeados da mesma forma que as classes. Com a diferena que os


atributos so iniciados por letras minsculas e representam propriedades das classes.
So bons nomes para as classes outros substantivos associados s classes, frases
adjetivas curtas ou adjetivos substantivados que podem qualificar as classes, por
exemplo: cor, nome, baixo, tamanho, tempoDeEspera, dataDeAniversario, menorIndice
e maiorValor.
As operaes indicam aes que a classe pode executar. As operaes devem ser
nomeadas com nomes relativos s responsabilidades que a classe assume para o
sistema. Verbos ou frases verbais curtas so bons exemplos de operaes. As
operaes assim como os atributos so iniciadas por letras minsculas, como por
exemplo: calcularValor, fazerPedido, vender, investir e comprar. Analogamente aos
atributos, a classe ou o objeto que criado a partir dela, ser o sujeito das operaes
Com exceo da herana, todos os relacionamentos entre as classes de um sistema
podem ser nomeados. Os detalhes da representao de cada tipo de relacionamento so
apresentados juntamente com os adornos disponveis para um relacionamento.

5.2.2.

Visibilidade

Uma das caractersticas das classes a capacidade de envolver em uma cpsula


atributos e operaes e poder, a seu critrio, ocultar estas informaes de outras
classes. Para controlar quais atributos e operaes de uma classe podem ser vistos fora
dela deve-se estabecer a visibilidade de cada um destes elementos. No diagrama de
classes a visibilidade que pode ser: pblica, privada ou protegida, indicada por um
smbolo na frente do nome do atributo ou da operao, como mostra a tabela.
Como uma boa prtica de projeto, uma classe s deve oferecer ao sistema suas
operaes pblicas. Assim, oas outras classes s podem invocar as mensagens
relacionadas s operaes pblicas e apenas estas operaes podem ser herdadas. As
operaes privadas e os atributos servem para atender as necessidades internas da
classe, so visveis por toda a classe mas no so visveis externamente.

Esta boa prtica de projeto evita que outras classes tenha acesso direto, e
descontrolado, aos valores dos atributos da classe. Se uma classe oferece atributos
pblicos ela permite que seu estado seja alterado sem que ela possa tomar uma ao a
esse respeito. Dando acesso aos atributos unicamente por intermdio de operaes de
acesso, a classe pode controlar o que ocorre quando um atributo seu se modifica
alterando, por exemplo, o seu estado.
Para dar acesso aos atributos privados so criadas as chamadas de operaes de
acesso. Os nomes destas operaes de acesso devem ser padronizados para facilitar a
sua construo por ferramentas automatizadas, e para dar um acesso padronizado por
outras classes. A tabela abaixo exemplifica as operaes padro de acesso em uma
classe de Produto mostrada na figura:

Figura 57 - Exemplo de operaes de acesso


A classe Produto, do exemplo, possui os atributos privados: nome do tipo texto
(String), qtd do tipo inteiro (int) e outro chamado disponvel do tipo boolean (falso ou
verdadeiro). A tabela descreve algumas operaes

Como o atributo disponvel um atributo booleano usa-se a operao isDisponvel


no lugar do getDisponvel como forma padronizada de acesso. Supondo que a
disponibilidade do produto depende da quantidade do produto, podemos definir o valor
do atributo se ele est disponvel ou no com base na quantidade atribuda ao Produto.
Assim o pseudocdigo do mtodo setQtd pode ser:
metodo setQtd( pQtd:int)
qtd <- pQtd
se (qtd > 0)
entao disponivel <- verdadeito
senao disponivel <- falso
fim do se
fim do setQtd

Assim, se os atributos qdt ou disponvel forem pblicos, possvel modificar os


seus valores direta e independentemente, e ter-se a quantidade zero (qtd=0) e valor

disponvel ainda verdadeiro (diponivel="true"), criando uma condio inconsistente


para o produto. O parmetro disponvel alterado alterando-se a quantidade, por esta
razo, no faz sentido ter-se a operao setDisponivel. Confirma-se assim a boa prtica
de adotar usar mtodos de acesso pblicos e atributos privados. Uma exceo a esta
regra so as constantes globais, que por serem constantes sero lidas e no podem ser
modificadas, no necessitando de um mtodo de acesso. Outra operao muito til a
operao que gera uma seqncia de caracteres para testar a classe e apresentado o seu
contedo impresso, por exemplo. Cria-se assim a operao toString() que retorna um
texto que descreve o objeto.

5.2.3.

Instanciamento de Classes em Objetos

Uma classe pode ser instanciada em um objeto, como mostra a figura. Com os
objetos pode-se construir um diagrama de objetos, relacionando os objetos como se
relacionam as classes que os formam.

Figura 58 - Exemplo de um objeto


Para instanciar o produto lampada, por exemplo, deve-se criar um objeto com base
na classe EquipEletrico, que traduzido em cdigo por mtodos chamados de
construtores:
lampada= new EquipEletrico(110, 5.00)

Neste exemplo, escrito em Java, o mtodo EquipEletrico(tensao, valor) um


mtodo constutor da classe EquipEletrico, e um executado em associao ao comando
new para criar o objeto livro com base na classe.

5.2.4.

Classes concretas, abstratas e interfaces

As classes so instanciadas em objetos, dos quais se pode invocar as operaes


pblicas na forma de mensagens. No entanto, nem todas as classes permitem a sua
instanciao direta em objetos, as classes que permitem a sua instanciao em objetos
so chamadas classes concretas. Em muitos casos, pode ser necessria a criao de
classes que apenas descrevem conceitos abstratos e que no so transformados em
objetos diretamente, as chamadas de classes abstratas. Estas classes devem ser
herdadas por outras classes concretas, que iro implementar os conceitos abstratos
criando uma classe concreta que pode ser instanciada.
As classes abstratas so muito teis nas primeiras etapas da modelagem, na fase da
modelagem conceitual e na criao de famlias de classes reutilizveis. As classes
abstratas no podem ser instanciadas porque alguns de seus mtodos so abstratos, isto
, existe ainda algo na classe abstrata que no foi definido. Um mtodo abstrato um
mtodo do qual se conhece apenas a sua chamada, a sua assinatura, e que ainda no foi
construdo. Isto , uma classe abstrata tem pelo menos um dos mtodos da classe apenas
declarado, e ainda no existe sua implementao concreta para ele. Nas primeiras fases
da modelagem de um sistema possvel que alguns mtodos de uma classe ainda no
tenham sido completamente definidos o que a caracterizaria como abstrata.
A assinatura de uma operao ou mtodo o nome da operao e seu conjunto de
parmetros. Um mtodo abstrato no possui o corpo do mtodo onde se encontra o
algoritmo que o implementa. Uma classe abstrata pode possuir mtodos concretos, mas
deve ter pelo menos um mtodo abstrato. Para uma classe abstrada se tornar concreta
ela deve ser herdada por outra que ir sobrescrever os mtodos abstratos com mtodos
concretos.
A UML representa uma classe abstrata com linhas pontilhadas. No exemplo a seguir,
tem-se a classe abstrata PessoaJuridica representando o conceito de pessoa jurdica,
que implementado pelas classes concretas de empresa cliente (EmpresaCliente) e de
empresa fornecedora (EmpresaFornecedora). O mtodo criarEmpresa um mtodo
abstrato de deve ser implementado pelas classes filhas para que estas sejam concretas.

Figura 59 - Exemplo de classe abstrata


Um tipo de classe abstrata muito til na modelagem a interface. Uma interface
uma classe formada apenas por mtodos abstratos. Ela serve para se definir uma forma
de comunicao entre as classes de um modelo, porque descreve apenas um conjunto de
mensagens que as classes que a implementam devem obedecer. Ela define um padro de
comunicao, e se posiciona entre classes, por isso chamada de interface.
No exemplo abaixo temos a definio de uma Obra em uma biblioteca, que a
definio abstrata de um conceito que serve para se comunicar com o sistema da
biblioteca. A herana de uma interface chamada de implementao porque a classe
concreta devem implementar todos os mtodos da classe de interface. Esta herana
representada tambm por uma linha pontilhada porque no uma herana verdadeira,
uma vez que no h mtodos concretos para serem herdados. A herana em uma
interface uma implementao. O uso de interfaces bastante difundido na criao de
classes reutilizveis e no desenvolvimento de componentes de software portveis.

Figura 60 - Exemplo de Interface e Implementao

5.2.5.

Adorno dos relacionamentos

Os relacionamentos podem receber elementos grficos para descrever, com maior


preciso, a ligao existente entre duas classes. A base para o relacionamento entre
duas classes a associao que representa uma unio conceitual entre as duas classes.
Na associao pode-se incluir uma seta para aumentar a navegabilidade da associao,
um losango para indicar uma agregao e uma multiplicidade nas extremidades.
Uma seta na associao mostra a navegao do relacionamento, ou seja, a direo
do relacionamento identificando quem a classe dependente (origem da seta) e quem
a classe independente (ponta da seta). Um losango em uma das extremidades da seta
transforma uma relao em uma composio, istop , transforma a associao em um
relacionamento de agragao todo-parte, onde o losando identifica a classe que o
todo. Uma associao pode ter um nome indicando o tipo de relacionamento que existe
entre as classes. O nome mostra qual o conceito que une as classes. Estes adornos
podem ser observados no exemplo abaixo, onde uma empresa possui uma srie de
produtos que so as suas vendas.

Figura 61 - Exemplo de adornos em relacionamento


O adorno mais importante em um relacionamento a multiplicidade da relao. Ela
descreve quantos objetos participam desta relao e indicada por um smbolo nas
extremidades da relao. O exemplo da figura mostra que uma empresa realiza vendas
de muitos (*) produtos, nesta relao a navegao indica que a empresa quem vende
os produtos. A tabela abaixo mostra os smbolos utilizados na representao.

Em um sistema esta relao vai indicar que cada um dos objetos que forem
instanciados a partir da classe Empresa podero ter um vnculo com vrios objetos da

classe Produto. O nome deste vnculo vendas. Na fase de implementao este


relacionamento pode, por exemplo, ser traduzido em um vetor de produtos criado na
classe Empresa. A composio indica ainda a existncia dos produtos destas vendas
(partes) est condicionada existncia da classe Empresa, o todo na relao.
Os vnculos entre as classe formam os caminhos pelos quais so enviadas as
mensagens que criam a dinmica de um sistema orientado a objetos. Supondo-se, no
exemplo, que os objetos da classe Produto tenham um mtodo pblico getPreco(), que
informa o preo de cada produto, possivel aos objetos da classe Empresa perguntar o
preo de um produto do vetor de vendas com a mensagem:

vendas[i].getPreco();

que informaria o preo do produto de ndice i do vetor. A modelagem da troca de


mensagens entre os objetos modelado pelos diagramas de interao, que so
estudados a seguir.

5.3.

Diagramas de Interao

As mensagens formam a base da dinmica de um sistema orientado a objetos. A


partir da modelagem conceitual procurou-se identificar e representar as
responsabilidades das classes na forma de mensagens que a classe seria capaz de
responder. Os diagramas de interao objetivam descrever, de maneira mais detalhada,
a troca de mensagens que ocorre entre os objetos de um sistema.
Para poder compreender claramente o conceito de mensagens importante rever
alguns termos que sero utilizados amplamente nesta seo e nas seguintes. Um sistema
constitudo por um conjunto de classes, que dividem entre si uma srie de
funcionalidades implementadas em mtodos e atributos. A integrao destas
funcionalidades garante o cumprimento da totalidade dos objetivos previstos para o
sistema orientado a objetos que foram levantados das descries dos casos de uso no
modelo de contexto. No modelo de contexto obseva-se tambm que so os atores a real
origem das mensagens, uma vez que as classes respondem a estmulos vindos dos
objetivos dos atores. Na modelagem conceitual ficou claro que uma classe isoalada
incapaz de atender totalidade de funcionalidades existentes em um sistem, e para isso
depende das funcionalidades das outras classes do sistema. Para utilizar uma
funcionalidade do objeto de uma classe envia-se uma mensagem para ele, que
implementada em uma operao pblica do objeto de destino. Assim, a operao de um
sistema orientado a objetos se traduz em uma intensa troca de mensagens entre os
objetos, estimulados por eventos externos vindos dos atores do sistema.
Os objetos que participam da interao formam um contexto, que a reunio dos
objetos e dos vnculos que unem os participantes da interao. A figura, que representa
uma interao, esquematiza os conceitos de vnculo, mensagem e contexto e suas
relaes :

Figura 62 - Componentes de uma interao


A colaborao entre objetos, para atingir um determinado objetivo, realizada pela
requisio de um servio que um objeto necessita de outro objeto, que est capacitado a
prestar este servio. Uma mensagem geralmente iniciada por um ator em um objteo.
Este estmulo pode dar origem outra mensagem, e a esta por sua vez a outra,
seqencialmente, at que o objetivo inicial seja cumprido. A modelagem dinmica das
interaes entre as classes feita na UML por um conjunto de dois diagramas chamados
de diagramas de interao:
Diagramas de Seqncia
Diagrama de Colaborao
O diagrama de seqncia descreve a organizao das mensagens trocadas entre
objetos no tempo em um cenrio de uso do sistema. sabido que a colaborao entre
os objetos se d entre objetos que se relacionam, e principalmente, por meio destes
relacionamentos. O diagrama de seqncia no mostra este relacionamento. Para
descrever a troca de mensagens que ocorre nos relacionamentos entre os objetos usa-se
o diagrama de colaborao. Na modelagem das interaes o olhar do modelador deve
estar suficientemente distante das classes para no perceber os detalhes dos objetos,
mas prximo o bastante para perceber as mensagens entre eles. O colaborao e a
seqncia de mensagens representam a mesma informao sobre o sistema, sendo
possvel traar um diagrama a partir do outro.

5.3.1.

Mensagens

As mensagens so instncias do comportamento dinmico externado pelos objetos.


Elas surgem, quase naturalmente, ao se analisar um caso de uso ou, ao se projetar a
distribuio de responsabilidades de um problema entre os objetos de um sistema.
Quando um objeto, o emissor, envia uma mensagem para outro objeto, o destinatrio,
ele est solicitando que o destinatrio execute uma operao da sua coleo.
Estabelece-se, a priori, que o objeto que recebe a mensagem capaz de atender esta
solicitao, devendo possuir uma operao pblica preparada para isto.
So igualmente consideradas como mensagens os estmulos externos recebidos pelo
sistema. Um usurio, ao solicitar uma ao de um sistema, nada mais est fazendo do
que emitir uma mensagem a um objeto deste sistema. Uma mensagem tem a mesma
estrutura de uma operao e , essencialmente, uma instncia desta operao. Como as
operaes, uma mensagem possui um nome, parmetros e um valor de retorno. O
retorno a resposta da mensagem e est implcito na maioria das mensagens. Se um
objeto faz uma pergunta porque, provavelmente, espera uma resposta. No entanto,
podem existir mensagens assnronas, que no aguardam a resposta, e mensagens como a
emisso de sinais, que no tem um retorno implcito. A tabela mostra os diversos tipos
de mensagens:

5.3.2.

Diagrama de Seqncia

Os diagramas de seqncia descrevem o comportamento dos objetos do sistema,


que se relacionam pela troca de mensagens em interaes seqencializadas no tempo.
Cada diagrama mostra um cenrio, isto , um conjunto de mensagens, ordenadas no
tempo, com um determinado objetivo. Assim, para a elaborar um diagrama de
seqncia importante que os objetivos do sistema j tenham sido levantados pela
modelagem de contexto, e que se encontrem descritos nos cenrios dos casos de uso.
Por exemplo, o caso de uso Emitir fatura, abaixo, pode ser um objetivo do gerente
de contas de uma empresa, ao automatizar o seu sistema de vendas:

Figura 63 - Exemplo de um Caso de Uso


A descrio do caso de uso Emitir Fatura, neste sistema poderia ser:
A fatura emitida com a soma dos preos dos itens do pedido e endereada ao
cliente.
Na viso de uma troca de mensagens entre os objetos: fatura, pedido, item e cliente,
a descrio deste caso de uso fica:
A pedido do Gerente de Contas, a fatura inicia a sua emisso perguntando ao
pedido quais so os itens e segue enviando uma mensagem aos itens da fatura,
perguntando qual o seu preo unitrio, uma informao que prpria de cada item.
A seguir, a fatura pergunta ao cliente qual o seu endereo e, finalmente, retorna ao
gerente para a aprovao.
Este processo representado pelo diagrama de seqncia abaixo

Figura 64 - Exemplo de Diagrama de Seqncia


Enquanto o diagrama de casos de uso mostra a viso funcional, o de classes
apresenta uma viso esttica da estrutura das operaes, j o diagrama de seqncia
oferece uma viso dinmica, onde a presena da varivel tempo pode ser facilmente
observada. O tempo corre de cima para baixo no diagrama de seqncia, o que quer
dizer que os eventos inferiores ocorrem aps os eventos superiores no diagrama. As
linhas verticais representam os objetos e as horizontais as mensagens trocadas entre
eles. O diagrama de seqncia o diagrama ideal para especificaes de sistemas de
tempo real, pois o tempo aparece de forma explcita e as mensagens podem ter tempos e
intervalos bem definidos.
Algumas recomendaes so teis para se elaborar um diagrama de seqncia mais
claro e preciso. comum, por exemplo, que ao lado das mensagens se tenha uma
descrio textual do processo, com notas explicativas. tambm comum que um ator
inicie o diagrama, porque como o diagrama se prope a descrever a seqncia de
mensagens que leva a um objetivo, de se esperar que a primeira mensagem seja
aquela que solicita este objetivo ao sistema, normalmente, partindo de um ator.
No sempre necessrio representar no diagrama de seqncia a resposta s
mensagens, porque elas existem implicitamente. Entretanto, muitas vezes trata-se de
mensagens assncronas e o retorno s vir aps outras mensagens terem sido
executadas. Dai, importante identificar quando isso ocorre usando, explicitamente, a
mensagem de retorno. As mensagens de retorno so representadas no diagrama com
setas tracejadas, ao contrrio das outras mensagens que so linhas contnuas.
Uma outra caracaterstica do diagrama de seqncia a capacidade de representar a
linha da vida dos objetos que mantem o foco da ao a cada momento. Esta anotao
feita tornando a linha vertical que representa objeto mais espessa, quando este est em
foco no processamento. O foco ocorre entre o recebimento de uma mensagem e o

respectivo retorno. Fora de foco o objeto poderia estar fora da memria do


processador, porque no participa, naquele momento do processamento.
A figura que se segue mostra um diagrama com o foco de controle dos objetos para
exemplificar este recurso. O gerente solicita a emisso de uma fatura que mantm-se em
foco enquanto solicita aos pedido a lista de Itens e para cada item da lista o seu preco,
e finalmente o endereo ao cliente da fatura. Terminada esta tarefa a fatura retorna ao
gerente que a aprova.

Figura 65 - Exemplo do diagrama de seqncia do sistema da loja

5.3.3.

Diagrama de Colaborao

Analogamente aos diagramas de seqncia, os diagramas de colaborao


representam as interaes entre objetos na forma de troca de mensagens. A diferena
entre os dois diagramas que o diagrama de seqncia no mostra a estrutura de
vnculos entre os objetos que do apoio comunicao, enquanto o diagrama de
colaborao mostra os vnculos entre as classes, pelos quais fluem as mensagens. Outra
diferena est no fato que no diagrama de colaborao o eixo dos tempos no
apresentado explicitamente. Estas pequenas diferenas no impedem que se faa uma
transformao direta do diagrama de seqncia no diagrama de colaborao. A figura
abaixo mostra o diagrama de colaborao referente ao processo de emisso de fatura,
descrito no item anterior.
Os nomes das mensagens, assim como no diagrama de seqncia devem ser bem
escolhidos para refletir as operaes presentes na classe de destino. Uma seta ()
associada mensagem facilita a leitura e indica a sua direo. As mensagens, no
diagrama de colaborao, podem ser numeradas, o que d ao diagrama uma orden na
seqncia das mensagens no tempo, refletindo a ordenao apresentada no diagrama de
seqncia. O diagrama de colaborao pode ser utilizado como uma opo ao diagrama
de seqncia.

Figura 66 - Exemplo de diagrama de colaborao


A existncia de um vnculo entre os objetos do diagrama de colaborao indica uma
possibilidade de um relacionamento, mas, necessariamente, no o representa. Os

vnculos servem de meio para que as mensagens fluam e para a navegabilidade no


diagrama. Havendo um vnculo as classes podem colaborar, porque h um caminho por
onde a mensagem pode ser enviada.Os vnculos entre os objetos podem ser dos tipos:

Concluindo, os diagramas de interao representam a viso da dinmica presente


entre as classes de um sistema. Eles se caracterizam por descrever uma troca intensa de
mensagens, seqencializadas no tempo, relativas a um objetivo do sistema. Enquanto no
diagrama de seqncia o eixo dos tempos est presente, no est representada a
estrutura das classes. J no diagrama de colaborao encontra-se a estrutura, mas no
se encontra o eixo dos tempos. Ao final da elaborao dos diagramas de interao, temse representada nas mensagens, as operaes necessrias s classes para cumprir todos
as responsabilidades do sistema. As operaes so descobertas porque as mensagens
so instncias das operaes.
Tendo modelado todos os cenrios previstos no modelo de contexto para um
sistema, as classes devem ter recebido todos as operaes necessrias para responder
s mensagens trocadas no desenvolvimento dos cenrios. Resta agora verificar se
internamente as classes possuem a dinmica e coerncia necessria, papel este
desempenhado pelo diagrama de estados.

5.4.

Diagrama de Estados

A descrio da dinmica interna de uma classe feita pelo diagrama de estados, ele
reflete o ciclo de vida dos objetos da classe, desde o momento em que este objeto
criado at o seu trmino quando ele no mais utilizado pelo sistema, passando por
todas as situaes em que o objeto poderia se encontrar. Cada classe do sistema
modelada por uma mquina de estados finita, onde o olhar do modelador deve se
posicionar bem prximo aos mecanismos internos da classe, dentro at dos limites da
prpria classe. A proximidade deve ser o suficiente para poder observar, isoladamente,
cada detalhe interno dos estados e das suas transies.
O diagrama de estados representa a dinmica interna de uma classe como sendo
formada por estados e eventos. Estados caracterizam condies, situaes, onde o
objeto daquela classe pode ser encontrado. Eventos so aes que provocam a
mudana nestas condies. O estado uma atividade da classe de carter lento (estado
de ao), e s vezes at esttico (estado de espera). Por ter este carter lento, pode ser
interrompido por um evento. O evento, por sua vez, retrata uma atividade rpida e que
no pode ser interrompida, uma vez iniciado ir levar, necessriamente, ao novo
estado. Sempre ocorre um evento entre dois estados, assim como um estado possui pelo
menos um evento associado.

Figura 67 - Estrutura de uma transio de estados

5.4.1.

Evento

Um evento na dinmica de uma classe est associado s mensagens que a classe


recebe, e consequentemente, s suas operaes internas. So as operaes das classes
que permitem a mudana das suas caractersticas internas, ou seja, so as operaes
que provocam as alteraes no estado.
A simbologia adotada pela UML para dar nome a um evento :

evento[condio]/ao
onde :

A condio de disparo uma expresso booleana que quando verdadeira permite o


disparo do evento. A expresso avaliada apenas na ocorrncia do evento e permite
que um mesmo evento provoque diferentes mudanas de estado, conforme as diferentes
condies de disparo a ele associadas. No exemplo que se segue analisa-se o evento
retirarMaterial da classe itemEstoque, que simula um possvel sistema para controle de
estoque de materiais.

Figura 68 - Diagrama de Classes do Exemplo


Supondo que o itemEstoque esteja na sua condio de estoqueNormal, isto , a
quantidade de itens (qtd) est acima do estoque mnimo (estoqueMinimo), a ocorrncia
do evento retirarMaterial pode provocar a mudana para a condio estoque baixo, se
qtd, varivel que controla a quantidade de material, ficar inferior ao estoqueMnimo.
Caso contrrio o itemEstoque ainda mantido no estado de estoqueNormal.
Pode-se associar aes com o disparo de eventos, estas aes so mensagens
enviadas pela classe onde ocorre o evento para outras classes que iro provocar novas
mudanas de estados. Esta reao em cadeia que ocorre nas classes a operao tpica
de um sistema orientado a objetos. No exemplo, na ocorrncia da mudana de estado de
estoqueNormal para o estoqueBaixo diparada uma ao, na forma da mensagem emitir
para o objeto comprador da classe Compras, passando como parmetro a varivel
qtdReposicao, que indica a quantidade que deve ser reposta sempre que o estoque fica
abaixo do mnimo. A figura mostra o diagrama de estado que descreve estes processos:

Figura 69 - Exemplo de um diagrama de estado

5.4.2.

Estados

Um estado uma situao em que um objeto pode se encontrar no decorrer da seu


ciclo de vida. Esta situao pode ser caracterizada por um conjunto de valores dos
atributos, isto , analisando os valores dos atributos deve ser possvel dizer qual o
estado da classe. Existem diferentes tipos de estado, que possuem diferentes
representaes segundo a UML. A tabela abaixo mostra estas representaes que so
descritas a seguir:

O estado inicial e estado final representam a situao da classe antes do incio e


aps o trmino do seu ciclo de vida. O evento que parte de um estado inicial um
evento de criao (Construtor) de uma classe, assim como o evento que leva a um
estado final um evento de extino da classe (Destrutor).
O estado de espera e o estado de ao so estados em que a classe podem se
encontrar e diferem pela ao que a classes pode estar executando nesta.
O estado de deciso um estado que utilizado para definir uma transio com
base em uma condio. A diferena entre um estado de deciso e uma condio de
disparo associada a um evento , que no estado de deciso, a condio avaliada antes
da ocorrncia de um evento, e se executa uma transio em decorrncia apenas desta
deciso. Na condio de disparo a condio avaliada apenas quando da ocorrncia
do evento, e apenas condiciona uma transio, no provoca a transio.

O estado de sincronismo permite a paralelizao ou o sincronismo de eventos.


um estado auxiliar na construo de diagramas de estado porque permite que um mesmo
evento seja paralelizado em outros eventos, que sob novas condies de disparo, pode
provocar outras mudanas de estado e aes. De outro lado o estado de sincronismo
pode sincronizar dois ou mais eventos. Os eventos chegam ao estado de sincronismo de
forma assncrona, e provocam um outro evento agora sncrono. No exemplo que se
segue , o eventoSada s ocorre quando ocorrerem os eventos eventoA e eventoB:

Figura 70 - Exemplo de estados de sincronismo

5.4.3.

Superestados

Os superestados representam o agrupamento de estados e eventos associados a


eles. O agrupamento, alm de facilitar o entendimento do diagrama, identifica grupos de
eventos que possuem um comportamento em comum. Um evento que parte ou age sobre
um superestado, representa um evento que parte ou chega a cada um dos estados do seu
interior em particular.
A integrao de superestados, estados de sicronismo e deciso permite a criao de
transies complexas e permite representar um sem nmero de mquinas de estado. Um
superestado facilita o entendimento do diagrama de estados porque permite estruturar o
diagrama em diagramas menores.

Figura 71 - Exemplo de superestado

5.4.4.

Eventos e operaes, estados e atributos

Enquanto os eventos esto associados s operaes que uma classe pode executar,
os estados esto associados aos valores que os atributos assumem. Um estado de uma
classe pode ser preservado, e at armazenado, pela definio, e armazenamento, dos
valores dos atributos, assim como a mudana de um valor em um atributo pode
provocar a mudana de um estado da classe.
comum, em muitos casos, definir um atributo chamado estado, com a
responsabilidade de indicar o estado atual da classe. Esta prtica deve assegurar,
entretanto, que a mudana do valor deste atributo acompanha fielmente a mudana de
estados da classe. A inobservncia deste acompanhamento pode provocar situaes
incoerente, onde o atributo estado indica um estado e a classe est efetivamente em
outro, com conseqncias imprevisveis para a operao do sistema. Uma outra
possibilidade de implementao criar uma operao getEstado, que devolve o estado
da classe consultando uma srie de outras operaes e atributos.
Os eventos, internamente s classes, assim como as mensagens, externamente s
classes, so considerados instncias das operaes, isto , uma operao pode ser
utilizada em diversos eventos e mensagens, simplesmente alterando os parmetros ou a
condio de disparo. Co j foi visto anteriormente, uma boa prtica de projeto evitar
que as classes alterem diretamente atributos de outras classes. Esta providncia evita
que a classe perca o controle do seu estado. Fazendo com que toda mudana de atributo
seja feita por uma operao possvel se controlar os estados, as mensagens que
devem ser enviadas e os prprios atributos.

5.4.5.

Diagrama de estado de uma interface

Uma aplicao importante dos diagramas de estado pode ser encontrada na


[9]

descrio da operao das GUI interfaces grficas dos programas. Uma interface
grfica , em geral uma classe da camada de apresentao do sistema que deve receber
os eventos do usurio externo. Em princpio, o usurio livre para interagir com a
interface acionando qualquer tipo de evento, a qualquer instante. Esta liberdade pode,
se no for devidamente controlada, gerar situaes perigosas para a integridade de uma
aplicao. Operaes delicadas como as de excluir um dado, criar um registro ou
transmitir uma informao, devem ser cercadas de condies que as restringam. Criar
um diagrama de estados da interface ajuda a definir os eventos e estados possveis na
interface e limita as condies de risco.
O exemplo que se segue uma interface simples, que permite a edio do campos
Parmetro e Valor. A interface tem, em resumo dois estados: o estado onde se edita os
campos, e um estado onde estes campos so gravados. O diagrama de estado da
interface mostra as possveis transies de estado presentes nesta interface: a limpeza,
a gravao e a sada da interface. Os eventos gravar, limpar e sair esto associados aos
botes da interface, e aos eventos que o usurio provoca ao clic-los.

Figura 72 - Modelagem dos estados da interface


(a) exemplo da interface e (b) diagrama de estados correspondente

Analisando este diagrama pode-se incorporar restries como a de impedir a


gravao se os campos no forem preenchidos, alterando o evento gravar com uma
condio de disparo expressa pelo pseudocdigo
gravar[(parametro<>nulo) e (valor<>nulo)]
que limita a gravao quando um dos campos estiver nulo.

5.5.

Diagrama de Atividades

A dinmica de um sistema pode ser representada internamente uma classe pelo


diagrama de estados, e externamente, entre as classes pelo diagrama de seqncia. A
UML oferece ainda, no diagrama de atividades, uma outra alternativa que combina as
mensagens externas e internas s classes. O diagrama de atividades mostra uma
seqncia de estados e evento, muito semelhante de um fluxograma, e se aplica na
descrio de um processo que transcende a uma classe, e envolvendo estados de outras
classes.
O diagrama de atividades uma alternativa para representar um processo descrito
por um caso de uso. Para isso o diagrama de atividades dispe dos mesmos elementos
dos diagramas de estado: eventos e estados, mas que no se restringem a um nico
objeto.
Como exemplo de uso do diagrama de atividades pode-se desenvolver o diagrama
de atividades da operao de vendas do sistema da loja, apresentado no captulo 2.
Neste exemplo o caixa deve entrar com o cdigo do produto , o CGC do cliente e o
nmero de parcelas para verificar se a venda est aprovada ou no. O diagrama de
atividades abaixo mostra a seqncia de comandos que executam estas operaes:

Figura 73 - Exemplo de um diagrama de atividades

5.5.1.

Trilhas de Responsabilidades

O diagrama de atividades pode ser organizado para agrupar os estados relativos a


um objeto em uma mesma vertical. Assim, cria-se para cada objeto as chamadas raias
de responsabilidade (swimlanes). A idia agupar os estados relativos aos objeto de
uma classe em verticais. Desta forma o diagrama de atividades permite mostrar a
responsabilidade de objeto e criar uma relao entre o diagrama de atividades com o
diagrama de classes.
interessante observar que associando os estados de um objeto em uma vertica, os
eventos que partem desta vertical para outra vertica so equivalentes s mensagens em
um diagrama de seqncia.
Em nosso exemplo, pode-se agrupar os estados mostrados na execuo da operao
de verificao de vendas no objetos do POS, Loja, cliente e produto. Deve-se observar,
comparando a prxima figura com a figura anterior, que os estados so os mesmos, mas
a organizao permite identificar, claramente, a responsabilidade de cada objeto no
processo.

Figura 74 - Exemplo das atiividades com as trilhas de responsabilidade

5.6.

Diagramas de Implementao

Os diagramas de implementao ajudam os analistas no projeto da implementao


do sistema. Nesta fase so definidos os componentes de software e a sua distribuio
entre os processadores e servidores. Para a elaborao dos diagramas de
implementao, o projetista deve se posicionar a uma distncia tal do sistema, de modo
a deixar de lado os detalhes construtivos da classes e observar apenas o conjunto do
componente e os servidores.

Figura 75 - O analista v as classes e componentes de longe


A representao da implementao na UML realizada com dois diagramas:
Diagramas de Componentes
Diagramas de Distribuio
que sero detalhados a seguir.

5.6.1.

Diagrama de Componentes

Componentes so unidades que armazenam software. A idia agrupar em uma


unidade uma parcela do cdigo do software para facilitar a integrao para formao
do sistema. Os componentes podem ser associados aos arquivos onde os cdigos
podem residir. Os cdigos fonte ou cdigos executveis podem ser agrupados em
componentes. O critrio para criao de um componente pode ser as necessidades da
linguagem de programao, ou o compilador, mas tambm pode-se criar componentes
de software para atender os requisitos de distribuio do projeto e de reutilizao.
Um dos critrios usado para projetar um componente otimizar a performance do
sistema . O componente de software a unidade que utilizada para se distribuir o
processamento do sistema. O uso de diferentes processadores pode aumentar a
performance total, uma vez que possvel utilizar, mais adequadamente, o poder de
processamento distribudo em uma rede de computadores. O projeto de distribuio das
classes em componentes objetiva transferir para os componentes as relaes presentes
nas classe de modo a balancear a comunicao presente nas classes e transferida para
os componentes. Um balanceamento adequado das comunicaes entre os componetes
promove o balanceamento da comunicao entre os processadores na rede, e com isso
possvel maximizar o desempenho total do sistema.
Outro critrio para se projetar os componentes a reutilizao. Os componentes
so unidades que podem ser armazenadas e reaproveitadas em vrios projetos. Este
reaproveitamento pode ser maximizado no projeto de componentes, isolando os
elementos de um componente de modo a que seja mantido o encapsulamento e uma
interface pblica padronizada. O sistema integrado pela unio de componentes nos
processadores.
Um componente representado, na UML, pelo smbolo apresentado na figura. A
figura representa o encapulamento pelo retngulo com uma interface pblica,
identificad pelos smbolos na borda do retngulo:

Figura 76 - Notao de um componente

Um componente formado por um conjunto de classes relacionadas. A intenso


isolar o grupo de classes que possam ser reutilizadas. Assim, o componente se
comporta como no caso do encapsulamento de um objeto. O componente depende das
classes que o forma. Esta dependncia pode ser mostrada em um diagrama. A notao
indica a composio de um componente em dependncia das classes que o compe,
como mostra a figura:

Figura 77 - Um componente e as classes que o compe


Definidos os componentes, pode-se criar um diagrama de componentes descrevendo
como eles dependem entre si. A dependncia tambm a principal relao entre os
componentes, como mostrado a seguir:

Figura 78 - Exemplo de um Diagrama de Componentes


O diagrama de componentes representa a configurao do software, isto , como as
diversas partes do sistema se relaciona. Cada parte, identificada por um componente,
ligada s demais formando o sistema. Com o diagrama de componentes o integrador
capaz de criar uma verso do sistema de software. Para concluir a implementao
necessrio ainda a distribuio dos componentes pelos servidores, que o assunto dos

diagramas de distribuio, apresentados a seguir:

5.6.2.

Diagramas de Distribuio

Os diagramas de distribuio descrevem a configurao do hardware, e a integrao


dele com o sofware. Os equipamentos so representados por ns que podem estar
associados tanto aos processadores como aos servidores reais ou virtuais disponveis
para a aplicao. Os ns se relacionam entre si formando uma rede de processamento
de dados. As ligaes entre os ns representam as associaes fsicas e lgicas
existentes entre os equipamentos e servidores.
A UML representa de um n a representao de um cubo, que caracteriza um
equipamento processador, e seu tipo.

Figura 79 - Exemplo da Notao de um n


Os ns recebem os componentes de software, em um diagrama que descreve a
configurao do sistema, mostrando a dependncia do com aos componetes que a ele
so destinados.

Figura 80 - Composio de um servidor com seus componentes


O diagramas de distribuio representam a ponte que liga o software e o
hardware que ir process-lo. Assim, deve-se decidir quais os processadores sero
utilizados, e como distribuir os componentes de software entre eles. Os
relacionamentos presentes em um diagrama de distribuio formam as redes de

processamento de dados.

Figura 81 - Exemplo de um Diagrama de Distribuio

5.7.

Integrao entre os Diagramas

Os diagramas da UML no existem isoladamente, eles fornecem vises


complementares de um mesmo sistema e por este motivo devem ser coerentes entre si.
Os diagramas dos modelos orientados a objetos so baseados nos mesmos princpios
fundamentais, ou seja: classes, heranas, mensagens, estados e eventos. Estes
fundamentos garantem que os diagramas se integrem completamente, mostrando uma
viso prpria do mesmo sistema.
A base que define a estrutura do sistema so as classes, que formam a base para
todo o modelo. A implementao do sistema em cdigo executvel, parte da criao
das classes. A partir delas so criados os objetos que participam dos diagramas de
seqncias e colaborao. Os diagramas de estado e atividades partem dos estados das
mesmas classes, que formam, tambm, as bases para criar os componentes nos
diagramas de implementao.
Na estrutura das classes so as mensagens, implementadas nas operaes, que
permitem a integrao entre as diversas vises dos diagramas. Como as mensagens
so baseadas nas operaes das classes, elas permitem que se integre o diagrama de
classes com os diagramas de interao. Como so as operaes que controlam os
atributos e permitem s classes alterar os seus estados, temos a integrao entre o
diagrama de classes e o diagrama de estados tambm atravs das operaes.
Para exemplificar a integrao que as mensagens proporcionam entre os diagramas,
apresenta-se a seguir a integrao que existe entre os diagramas de classes e os
diagramas de seqncia, e a integrao entre o diagrama de estado e as operaes de
uma classe.

5.7.1.

Integrao entre os diagramas de classes e seqncia

Os diagramas de seqncia mostram uma troca de mensagens entre objetos de uma


classe. Cada mensagem se refere a um servio que a classe do objeto de destino pode
oferecer. Assim, para poder oferecer este servio deve existir uma operao na classe
do objeto de destino para implementar esta mensagem, como mostra o exemplo da
figura:

Figura 82 - Relao entre mensagens e operaes nas classes


Na integrao entre os diagramas deve-se garantir que as mensagens presentes nos
diagrams de seqncia, correspondam s operaes nas classes de destino. No exemplo
existe uma mensagem sendo trocada entre as classes de origem e destino, o que indica
que existe uma operao correspondente na classe de destino.
Em um processo de desenvolvimento pode-se detalhar os processos descritos nos
casos de uso em diagramas de seqncia. Neste processo a modelagem da interao
serve para complementar a distribuio de responsabilidade entre as classes, porque
toda vez que se determina uma mensagem para uma classe, se est distribuindo as
operaes pelas classes. A criao dos diagramas de seqncia serve para povoar as
classes do sistema de operaes.

5.7.2.

Integrao entre os diagramas de classes e estados

O diagrama de estados representa a dinmica interna de uma classe. Ele expe como
a classe reage aos estmulos externos que recebe. Estes estmulos, eventos no
diagramas de estados, devem ser operaes internas da classe que so acionadas pelas
classes externas. Podem ser operaes pblicas ou privadas. As operaes pblicas
permitem que eventos externos estimulem as classes. As operaes privadas podem ser
utilizadas para implementar eventos internos, estados de ao, condies e outras
situes onde necessrio ocultar do mundo exterior uma operao. O exemplo do item
de estoque, apresentado no item 5.4.1, um bom exemplo desta integrao.

6. Estudo de Casos
Este captulo reapresenta os exemplos desenvolvidos nos captulos anteriores
aplicando, de modo prtico, os conceitos da modelagem orientada a objetos.
Objetiva-se a reviso dos diagramas e modelos propostos aplicados em exemplos
simples que so levados implementao em prottipos executveis.

6.1.

Introduo

Este livro prope um conjunto de modelos que descrevem sistemas orientados a


objeto. Em conjunto com a introduo de cada modelo foram apresentados diversos
estudos de casos, que serviram de exemplo para a aplicao prtica das tcnicas e das
notaes propostas no texto. Este captulo retoma cada um destes exemplos,
apresentando os modelos detalhados que levam estes exemplos sua implementao na
linguagem Java de programao. As implementaes destes exemplos foram
desenvolvidas com uma finalidade didtica e no o desenvolvimento comercial dos
sistemas, ou mesmo resolver integralmente os problemas propostos. Para tornar os
sistemas mais simples, no se pretende apresentar a integrao com bancos de dados,
nem interfaces grficas sofisticadas que seriam exigncias naturais em sistemas deste
tipo.
Os sistemas desenvolvidos so:

Os diagramas da UML apresentados neste livro foram obtidos com a ajuda de uma
ferramenta CASE, e os cdigos dos programas foram escritos na linguagem Java com
uma IDE apropriada. Os exemplos desenvolvidos para este livro encontram-se
disponveis para serem executados on-line, pela internet como descreve o apndice,
onde tambm se encontram os cdigos destas aplicaes.

6.1.1.

Estrutura de camadas dos sistema

Os sistemas computacionais podem ser divididos em 3 camadas: apresentao,


negcio e persistncia. Em geral, a modelagem conceitual indica a vocao da classe.
Usando a notao da UML , podemos organizar as camadas em pacotes de classes:

Figura 83 - Estrutura de camadas de um sistema,


(a) notao da UML para as camadas de um sistema
A implementao de um modelo orientados a objetos depende de uma estratgia
para definir as camadas de apresentao e camada de persistncia. A camada de
negcios est, em geral, descrita pelo modelo. Mas as camadas de apresentao e de
persistncia precisam ser projetadas. A UML pode ser utilzada para definir alguns
elementos presentes na interface, como os exemplos desenvolvidos aqui puderam
mostrar. Entretanto, a UML sozinha no suficiente para modelar um sistema
completamente, outros diagramas podem ser utilizados para descrever as interfaces e o
modelo de dados (Ambler, 2001).

6.2.

Estudo de Caso: Sistema de Vendas de Loja

Os captulos 2 e 3 apresentam o exemplo de um sistema de apoio s vendas de uma


loja. Este sistema informa ao caixa se um produto pode ser vendido crdito para um
cliente, em funo do preo do produto e do crdito do cliente, obedecendo as regras
de negcio da loja. Este exemplo hipottico usado para mostrar os fundamentos da
orientao a objetos, como a comunicao entre classes por meio de troca de
mensagens e o polimorfismo. No captulo 2 so desenvolvidas as regras de negcio e
modelado o sistema sem o formalismo da UML, que introduzido no captulo 3
juntamente com o diagrama de casos de uso e o modelo de contexto. Neste captulo so
apresentados os modelos conceitual e detalhado da implementao deste sistema.

6.2.1.

Modelo Conceitual

O modelo conceitual do sistema de vendas da loja resulta da anlise dos casos de


uso e dos processos ali descritos. Desta anlise identificam-se os principais
personagens do sistema, mostrados na figura abaixo, que uma representao formal
das classes e dos seus relacionamentos:
As classes identificadas no sistema de vendas da loja so:

POS

que representa a interface entre o usurio (Caixa) e o sistema,


tipicamente uma classe de apresentao

Produto

representam os produtos comercializados pela loja, uma classe de


negcio

Cliente

representam os clientes cadastrados pela loja, uma classe de negcio

Loja

representa a loja, com um lista de produtos e clientes, uma classe de


negocio

BDLoja

auxilia loja para armazenar a lista de clientes e produtos, exemplo de


uma classe de persistncia.

No POS o caixa pode se comunicar com a loja que identifica para o caixa o Produto
que o cliente deseja comprar. Com base no preo do produto e no crdito do cliente, o
sistema pode autorizar a venda parcelada. A loja possui as informaes de crdito e do
preo armazenadas em um banco de dados, representado pela classe BDLoja, que
acionada pela LOJA ao ser criada construindo a lista de produtos (listaP) e a lista de
clientes (listaC).

Figura 84 - Modelo conceitual do sistema da loja

6.2.2.

Modelo Detalhado

O modelo detalhado do sistema de vendas da loja conseguido pela anlise


detalhada da dinmica dos processos que esto envolvidos nas vendas. A anlise se
realiza com os diagramas de interao, que permitem distribuir, ou verificar a
distribuio, das funcionalidades do sistema pelas classes. Terminada a modelagem, as
classes possuem todas as operaes necessrias para atender os objetivos do sistema.

Diagramas de Interao
A partir do modelo conceitual possvel simular os processos dinmicos
envolvidos no sistema, para distribuir as operaes pelas classes. O diagrama de
seqncia descreve a srie de mensagens que so trocadas entre os objetos do sistema
em um determinado cenrio. Seguem-se os cenrios de inicializao da Loja e de
autorizao das vendas.:

Figura 85 - Seqncia de autorizao de vendas da loja


O cenrio de inicializao da Loja descrito no diagrama de seqncia da figura
acima. Nele, a classe POS, representando o caixa da loja, cria uma instncia da Loja,
buscando na classe BDLoja, que representa o banco de dados as informaes da loja
para criar a lista de clientes e a lista de produtos. Estas listas so criadas a partir dos
dados de clientes e produtos armazenados na classe BDLoja, e das respostas aos

mtodos getListaC e getListaP desta mesma classe. Ao final deste cenrio, a loja est
pronta para iniciar as operaes de venda solicitadas pela rede de POS.
O cenrio mais importante no sistema da loja o cenrio de vendas, que envolve os
casos de uso: Identificar Cliente, Identificar Produto e Autorizar o Parcelamento. Estes
casos de uso podem ser representados por um nico diagrama de seqncia que mostra
a autorizao do parcelamento de uma venda. Nele, o caixa solicita Loja, pelo POS,
os dados do cliente, informando o nmero do seu CGC. A loja busca este nome na lista
de clientes e retorna ao POS. De posse do cliente, o POS recupera o nome do cliente e
exibe na interface. O POS solicita agora os dados do produto para a loja, com base no
cdigo deste produto, por meio da mensagem getProduto(codigo) emitida do POS para
aLoja. A loja busca na lista de clientes e retorna ao POS, que recupera a descrio do
produto. Identificado o cliente e o produto, o POS informa o nmero de parcelas
desejadas e pergunta para o produto se a venda est aprovada. O Produto faz as
consideraes com base nas regras de negcio da loja, envolvendo o crdito do cliente
e o preo do produto, para aprovar, ou no, a venda.

Figura 86 - Diagrama de Seqncia da autorizao da venda

Diagrama de Classes Detalhado


O diagrama de classes, no modelo detalhado, integra os diagramas de interao dos
processos e serve de base para a construo do software. As classes podem ser

traduzidas, diretamente no cdigo correspondente, adotando uma linguagem de


programao orientada a objetos. A montagem do diagrama de classes, alm da
distribuio das funcionalidades, estabelece o relacionamento existente entre as
classes. O relacionamento segue, aproximadamente, o que foi proposto pelo modelo
conceitual, mas com alteraes que permitam a implementao.
Neste ponto do detalhamento so inseridas operaes de acesso para todos os
atributos privados da classe. Usando-se o prefixo get seguido do nome do atributo para
as operaes de recuperao dos dados , e o prefixo set para as operaes de
atribuio.
A Loja composta de uma lista de objetos da classe Cliente chamada listaC e de
uma lista de objetos da classe produto chamada listaP. Tambm compe a classe Loja a
classe BDLoja que uma classe auxiliar, criada para recuperar os dados destas listas
arquivados de um modo persistente, a cada execuo do sistema. A Loja, como mostra
a figura, usa uma composio para representar a associao com as listas e com a
classe auxiliar, para representar uma forte dependncia entre estas classes.
Analisando as regras do negcio estabelecidas pela Loja no caso de uso Identificar
Cliente, criou-se uma nova classe chamada ClienteVIP. No diagrama de classes esta
relao representada por uma herana da classe ClienteVIP da classe me Cliente. A
classe filha possui uma condio de crdito diferenciada, implementada na operao
getCredito, que retorna o dobro do crdito atribudo para esta classe. A operao
getCredito da classe Cliente sobreposta pela classe ClienteVIP em um exemplo de
polimorfismo.

Figura 87 - Diagrama de classes de negcio do sistema

Projeto da Interface
As classes de negcio so projetadas pela anlise do processo de negcio, e os
diagramas da UML servem bem para este fim. No entanto, as classes de apresentao
necessitam de um projeto diferenciado. Neste tipo de classe a caracterstica mais
importante manter o controle do processo de comunicao entre o usurio e o sistema.
A classe de apresentao deve apresentar as informaes que o usurio precisa e os
meios para ele agir sobre o sistema. No exemplo da loja, o usurio precisa informar o
cdigo do produto e o CGC do cliente para recuperar da loja o cadastro do produto e
do cliente. Para conseguir a aprovao da venda, depois de identificado o produto e o
cliente, o usurio precisa informar o nmero de parcelas.
A interface, descrita a seguir, apresenta os campos de texto para a entrada do
cdigo, do CGC e do nmero de parcelas e os botes (PRODUTO, CLIENTE e
PARCELAS) para que o usurio possa acionar o sistema e processar os dados de
entrada. Para que o usurio verifique que a operao foi um sucesso, ele dispe de
campos de sada com a descrio do produto, nome do cliente e, finalmente, se a venda
foi aprovada ou no.

Figura 88 - Interface POS do sistema de vendas da loja


Adicionalmente, foi inserido um boo Limpar para limpar os campos de dados de
entrada e facilitar uma nova entrada.

Figura 89 - Diagrama de Estado da Interface POS


Uma forma de modelar o controle da comunicao representar os possveis
eventos que ocorrem na interface na mquina de estado de um diagrama de eventos.
Cada estado do diagrama representa uma situao em qua a classe se encontra, e cada
evento representa uma ao, promovida pelo usurio, para mudar o estado. A figura do
diagrama de estado da interface POS mostra que ela criada em um estado de
espera dos dados permanente. O usurio pode realizar 3 eventos neste estado,
correspondente aos 3 botes disponveis na interface. Cada boto depende que uma
informao seja fornecida, para provocar a mudana de estado, que passa para um
estado de ao onde a classe de negcio chamada e volta para o estado de espera.
Comparando-se o diagrama de estados acima, como a interface proposta possvel
analisar se a interface serve bem finalidade desejada de acionar o sistema, ao mesmo
tempo que se analisa as sua preciso por meio do diagrama.

Figura 90 - Diagrama de classes detalhado do sistema da loja


A interface POS pode ser includa no modelo de classes, agregando ela, alm da
classe Loja, um objeto da classe Produto: oProduto e um objeto da classe Cliente:
oCliente que representam, respectivamente, o produto e o cliente presentes na transao
de venda. A integrao da classe POS com as classes de negcio permite a criao de
um diagrama de classe completo do sistema, representado na figura.

Expanso do sistema
Para demonstrar a vantagens de manuteno e expanso dos sistemas orientados a
objeto, pode-se propor uma expanso no sistema da loja, implantando uma nova regra
de negcios ao sistema. Pode-se partir de uma necessidade do departamento de
marketing desta loja, que decidiu colocar um produto em oferta. A regra para esta
situao a seguinte:
Colocar um produto, da lista de produtos da loja, em oferta quer dizer que ele
pode ser vendido em at 3 parcela fixas, independentemente do crdito do seu
comprador.
Analisando o modelo de objeto do sistema, observa-se que esta regra ir implicar

que a verificao da aprovao do parcelamento da venda ser diferente se o produto


for um produto normal ou for uma oferta. Assim pode-se criar uma nova classe de
produtos, que herda as caractersticas da classe produto e chamada de Oferta, como
mostra o diagrama

Figura 91 - Detalhe do diagrama da classe Oferta


Na classe Oferta a aprovao da venda reformulada para acomodar esta nova
regra. Na classe Oferta tambm so criadas uma operao construtor Oferta() e uma
operao de sada toString() reformulada.
A nova operao de aprovao isAprovado() possui os mesmos parmetros de
entrada da operao anterior, de modo que ela substitui integralmente a operao
anterior quando a classe uma Oferta. Assim, quando se chama a operao de
aprovao em um objeto da classe Oferta a sua forma alterada acionada.
A nova operao, descrita a seguir, mostra que caso o nmero de parcelas de venda
(n) for maior do que 3, em um produto em oferta, a regra que est valendo a de um
produto comum e para isso se aciona o mtodo super.isAprovado da classe
me (super). No caso de um produto em oferta, se com um nmero de parcelas (n) for
menor ou igual a 3, a operao aprova a venda. Assim a nova operao de aprovao
de venda, escrita na linguagem Java, fica:
public boolean isAprovado(int n, 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 criao deste produto na classe de acesso ao banco de


dados: BDLoja, como a Oferta tambm um Produto, devido herana, ela pode ser
armazenada na lista de Produtos (listaP), pelo comando:

listaP[4] = new Oferta(104,"Piano de Cauda",5000);


se o produto no esivesse em oferta, o cliente de cdigo 5000, que possui um
crdito de R$ 300,00 no poderia adquir-lo em 3 parcelas, porque o saldo da compra
certamente seria superior ao seu crdito:

5000 Miles Davis R$ 300,00

Mas com a oferta o sistema de vendas autoriza o parcelamento, como mostra a


interface com o exemplo desta operao :

Figura 92 - Exemplo da interface do sistema com venda de oferta

6.3.

Estudo de Caso: Jogo da Forca

Este sistema descreve uma aplicao completa, com uma interface grfica, apoiada
nas classes de negcio identificadas na modelagem conceitual desenvolvida no item
4.4. Utiliza-se este exemplo para demonstrar a importncia da separao das camadas
de negcio, de apresentao e da camada de persistncia em um projeto de software e
as possibilidades da modelagem nestes casos. O sistema detalhado em duas
implementaes, uma implementao bsica, onde gerada uma aplicao local para
testes das classes de negcio, e uma implementao web onde a aplicao
expandida para operar no ambiente da internet.
No exemplo desenvolvido no captulo 4, foram identificadas as classes de negcio:

6.3.1.

Modelo Detalhado da Implementao Bsica

Para detalhar a implementao bsica do jogo da forca, a qual ser usada para testar
as classes de negcio antes de se implementar o jogo em rede, necessrio fazer o
design da interface desta implementao com o usurio. Na implementao bsica do
jogo da forca no se utiliza recursos grficos. O boneco representado por uma figura
simples desenhada com caracteres em uma matriz de 3 x 3 como mostra o esquema
abaixo:

Tambm nesta implementao, as letras da palavra secreta que ainda no foram


identificadas so marcadas com traos do tipo : _. Por exemplo, se a palavra secreta
escolhida foi namorado, e j foram arriscadas as letras a,m e r, a palavra
descoberta fica sendo apresentada ao jogador como : _ a m _ r a _ _ , onde as letras
ainda no descobertas so substitudas pelo trao.

Diagramas de Seqncia
Os diagramas de seqncia so teis na definio detalhada das classes e na
definio de como se realiza a comunicao entre elas. Tomando os casos de uso:
Novo Jogo e Chutar Letra, pode-se analisar a seqncia de eventos que executada nos
cenrios principais destes casos de uso, identificando as operaes necessrias para se
completar cada processo, e que deve estar presentes nas classes.

Figura 93 - Diagrama de Seqncia do caso de uso: Novo Jogo


A cada vez que o usurio solicita Forca que crie um novo jogo, ela constri uma
instncia das classes Palavra e Boneco para iniciar o jogo. As operaes Jogador(),
Palavra() e Boneco() so os chamados mtodos contrutores, que instanciam as classes
na criao dos objetos. Solicita ento que a classe Palavra escolha uma palavra
secreta, que ela vai buscar na lista de palavras. A Forca ento cria uma instncia do
Jogador e prepara a interface do jogo, desenhando o boneco e a palavra secreta com
traos, para o jogador tentar descobrir as letras.

Figura 94 - Diagrama de Seqncia do Caso de Uso: Chutar Letras


O usurio do jogo sugere uma letra que capturada pela Forca e passada para a
classe Jogador, por meio da mensagem chutaLetra() enviada pela Forca. O jogador
ento acrescenta a letra na lista de letras j chutadas (addLetrasChutadas). O Jogador,
pergunta para a classe Palavra se a letra est na palavra (letraNaPalavra). A Palavra
incumbida de verificar de a letra est na palavra e, se estiver, acrescenta a letra nas
posies corretas da palavra secreta. Caso a letra no esteja na palavra, a classe
Palavra solicita ao objeto boneco que acrescente mais uma parte ao desenho
(addParte). importante verificar, ao se construir um diagrama de seqncia que todas
as mensagens trocadas entre as classes tenham uma operao correspondente na o
objeto de destino.
A Forca ao final de cada letra chutada, deve desenhar as letras chutadas

(getLetrasChutadas) a palavra (palavra.desenha) e o boneco (boneco.desenha), para


apresentar ao usurio que ir continuar o jogo. Antes porm, a Forca pergunta para o
jogador se ele perdeu, e o jogador pergunta para a palavra se ela est completa
(isCompleta). Neste momento, a Forca pergunta para o jogador se ele ganhou, e ele
pergunta para a palavra se ela est completa (isCompleta), finalizando o processo, que
repetido a cada letra chutada.

Diagrama de Classes Detalhado


O jogo da forca pode ser considerado um pacote, onde se encontram as classes de
negcio, e que utilizada pelo usurio externo para jogar com o computador. Este
sistema representado pela figura abaixo:

Figura 95 - Representao do jogo como um sistema


Os diagramas de seqncia ajudam a completar o diagrama de classes com as
operaes e as suas assinaturas, garantindo que as classes tenham todas as operaes
necessrias para executar os processos do sistema, definidos nos cenrios dos casos de
uso. O resultado, na implementao bsica do Jogo da Forca mostrado no diagrama
de classes detalhado a seguir.
O diagrama de classes detalhado serve para iniciar o desenvolvimento do sistema,
porque cada classe ser traduzida em um programa Java. Deve-se detalhar cada
operao e atributo definindo o seu tipo, valor inicial, tipo de retorno e parmetros dos
atributos.
Deve haver uma relao biunvoca entre o cdigo e o diagrama. Isto quer dizer que
o diagrama e o cdigo, no nvel das definies das classes, se equivalem. Chama-se de
engenharia de produo a gerao de cdigo, em linguagem de programao, a partir do
diagrama. Chama-se de engenharia reversa a produo do diagrama a partir do cdigo
em linguagem de programao. Estas converses so facilitadas pelo uso de uma
ferramenta CASE para automao do projeto de software.

Figura 96 - Diagrama de classes da implementao Bsica

Cdigo Java da classe Boneco


Para exemplificar a equivalncia entre o cdigo e o modelo, pode-se analisar o
cdigo de uma das classes do diagrama de classes. Este o cdigo, na linguagem 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 dinmica ajuda o projetista a definir como devem ser construdos os
mtodos, e a detalhar a troca de mensagem entre as classes. Os diagramas de estado
exibem as relaes entre as mensagens que a classe recebe e emite, e os seus processos
internos. Mostra-se o ciclo de vida das classes do sistema, que se integram para formar
o ciclo de vida do sistema como um todo.

Diagramas de Estado do Jogador


O jogador possui 3 estados bem definidos: ChutandoLetras, Ganhou ou Perdeu. O
jogador criado no estado ChutandoLetras. O evento que altera os estados o evento
chutaLetra, que recebe uma letra entrada pelo usurio para teste. Quando ocorre o
evento chutaLetra, o jogador continua no estado Chutandoletras, mas manda uma
mensagem para ele mesmo adicionar esta letra na lista de letrass chutadas
(addLetraChutada). Se a palavra estiver completa o jogador ganhou, se o boneco
estiver completo ele perdeu, estas situaes so estados verificados com os mtodos
ganhar() e perder(), respectivamente;

Figura 97 - Diagrama de estados da classe Jogador


Ao enviar a a mensagem perguntando se a letra est na palavra, o jogador faz com
que a palavra tome uma deciso: se a letraNaPalavra for verdadeira ela insere a letra
na palavra secreta. Se a letraNaPalavra for falsa ele manda o boneco acrescentar uma
parte.
possvel se detalhar um estado, em atividades ainda mais internas. Por exemplo, o
estado de chutandoLetras um estado de ao e pode ser expandido em um outro
diagrama de estados, como mostra a figura que se segue:

Figura 98 - Diagrama do superestado Chutando Letras


Neste diagrama observa-se que a entrada do evento chutaLetra aciona a ao interna

de adicionar letras na operao addLetrasChutadas e com base na definio se a letra


est na palavra, obtida pela mensagem letraNaPalavra enviada para a classe palavra,
toma-se a deciso de adicionar uma parte ao boneco, enviando a mensagem addParte ao
boneco, ou no. Terminadas estas aes internas, a classe Jogador permanece
esperando um novo evento chutaLetra, e pode enviar os sinais de ganhar ou perder. Este
diagrama de estado equivalente ao cdigo java reproduzido 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 bem definidos: um estado inicial, onde nada do
boneco foi desenhado na forca, um estado onde as partes do boneco esto sendo
desenhadas uma a uma, e finalmente outro estado, quando o boneco est completo, e o
Jogador perdeu o jogo. O atributo que controla este estado o nmero de partes do
Boneco que j foram desenhadas, representado pela varivel parte. O evento que
coloca o Boneco no estado inicial o evento de construir o objeto ou o evento
limpaForca. A troca de estados feita pelo mtodo addParte, que adiciona uma parte
do boneco cada vez que acionada. Estando o Boneco com mais de 6 partes ele
considerado completo, o diagrama abaixo mostra estas transies em um diagrama de
estado:

Figura 99 - Diagrama de estados da classe Boneco.

Detalhamento da classe Forca


A classe forca implementa o mtodo principal (main) acionado quando da execuo
do programa. Ao ser inicializada a Forca ela envia uma mensagem para a classe
palavra escolher uma palavra secreta. A partir dai, entra em um ciclo que termina
quando o jogador ganhar ou perder. A cada volta do ciclo executa o desenho do 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 incio do ciclo.
Este processo pode ser representado pelo diagrama de atividades que se segue:

Figura 100 - Diagramas de atividades do programa Forca

o extrato de programa Java abaixo apresenta uma possvel traduo deste diagrama,
onde se utiliza a classe JOptionPane do pacote javax.swing para implementar a
interface com o usurio, 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 pelo usuario
letra =JOptionPane.showInputDialog(tela).toCharArray()[0];
//
// Envia mensagem ao jogador para entrar com letra no jogo
jogador.chutaLetra(letra, palavra, boneco);
}while(!(jogador.ganhar(palavra)||jogador.perder(boneco)));

if (jogador.ganhar(palavra))
{tela = tela + "n Parabens! ganhou!"; };
if (jogador.perder(boneco))
{tela = tela + "n Que pena, perdeu!";};
JOptionPane.showMessageDialog(null,tela,
"Jogo da Forca",JOptionPane.INFORMATION_MESSAGE);

System.exit(0);
}

Executando-se o comando para executar o sistema:

C:Java Forca
Obtm-se uma interface para o jogo, com um pedido para chutar uma letra, de modo
semelhante interface mostrada na figura:

Figura 101 - Interface para jogar a forca

6.3.2.

Modelo Detalhado da Implementao WEB

Os modelos orientados a objeto tem como uma das grandes vantagens a


caractersticas de reusabilidade e a facilidade de expanso e manuteno. Este exemplo
demonstra a reusabilidade do cdigo orientado a objeto, criando uma verso para a
internet do jogo da forca reaproveitando grande parte do cdigo da verso bsica. A
nova verso web do jogo inclui duas novidades:
1.

Um interface grfica baseada na tecnologia de Java Applet, e

2.

Uma classe que permite ler as listas de palavra pela internet.

Estas modificaes servem para avaliar a facilidade em se dar manuteno em


sistemas desenvolvidos sob a orientao a objetos, e a grande reutilizao resultante do
encapsulamento das classes. O novo sistema chama-se de forcaWEBDB, como mostra
o diagrama abaixo, onde se observa a dependncia de um sistema e outro.

Figura 102 - Diagrama do sistema ForcaWEBDB e suas dependncias


Para criar uma verso grfica da forca necessrio criar uma nova classe Forca,
agora chamada de ForcaWEBDB, que implementa um Applet para ser processada pela
internet.

Implementar um acesso remoto lista de palavras


A primeira modificao na implementao bsica para levar o jogo para a internet
alterar a classe Palavra. Optou-se por criar uma nova classe, chamada de PalavraDB
para implementar a camada de persistncia da classe Palavra, onde o sufixo DB lembra
DataBase. Como foi visto comum isolar em camadas as funes de persistncia, que
so mais sujeitas a alteraes.

A idia re-escrever o mtodo da classe Palavra que faz acesso lista de palavras.
O mtodo que escolhe a palavra secreta l a lista de palavras de um arquivo texto e
seleciona, aleatoriamente, uma palavra. Esta leitura feita pela classe PalavraDB que
recebe como parmetro de entrada o endereo de localizao do arquivo na internet.
Este endereo parmetro de entrada da Applet, o que permite que o jogo possa
receber diferentes listas de palavras, implementando diferentes nveis de dificuldade,
ou jogos temticos como palavras ligadas a animais, pases, plantas, etc...
O diagrama abaixo mostra a dependncia que foi ento criada entre a classe Palavra
e a classe PalavraDB, implementada na operao escolheSecreta().

Figura 103 - Exemplo de implementao da camada de persistncia

Criar uma interface grfica


O que muda na classe que representa o boneco na implementao bsica, para o
boneco da implementao para internet apenas a sua aprentao grfica, as
propriedades de gerenciar o nmero de partes desenhadas, e verificar se est completo
deve ser o mesmo. Todo cdigo desenvolvido para a implementao bsica deve ser
reutilizado na nova implementao.

Figura 104 - Criao de uma classe de Boneco para web


Assim, para reutilizar o cdigo existente pode-se utilizar da capacitade de herana
das classes e criar uma nova classe, chamada de BonecoWeb, que filha da classe
Boneco. Esta nova classe i substituir a classe boneco na implementao da
forcaWEBDB, sobrescrevendo o mtodo desenha() que desenha o boneco na forca.

Exemplo da interface resultante


A nova implementao da classe Forca utiliza as mesmas classes Jogador e Boneco
da implementao anterior, acrescida das classes BonecoWEB e PalavraDB, com uma
pequena alterao na classe Palavra. O resultado final um novo diagrama de classes,
esquematizado a seguir, que implementa o novo Jogo da Forca com uma nova interface.
Nesta nova implementao as classe ForcaWEBDB e BonecoWEB formam a
camada de apresentao, a camada de negcios continua formada pelas classes
Jogador, Palavra e Boneco, e a camada de persistncia implementada pela classe
PalavraDB:

Figura 105 Classes da implementao web e diviso de camadas


Nesta nova implementao possvel se representar com um diagrama de
componentes a verso final do jogo, que para ser jogado na internet requer que um
servidor receba uma pgina no formato html (index.html) com o cdigo da Applet
(ForcaWEBDB.class) e que transferida para o processador do cliente pela internet.
Os componentes que implementam o jogo so representados no diagrama abaixo:

Figura 106 - Diagrama de componentes do jogo da forca


No diagrama de componentes esto relacionados os arquivos que fazem parte do
jogo e suas dependncias. Os arquivos possuem extenses que caracterizam os tipos de
componentes. Neste diagrama identificamos a pgina html, as classes java e o arquivo
texto da lista de palavras.
Estes componentes so recebidos por um servidor web (webserver) que permite que
clientes remotos, munidos de um navegador (browser) possam execut-los e jogar a
forca. Esta distribuio de componentes mostrada no diagrama de
distribuio abaixo:

Figura 107 - Diagrama de distribuio do jogo da forca


O servidor web, em nosso caso, foi implementado no endereo do em um website
que se encontra descrito no apndice. Neste endereo tem-se acesso pgina
index.html que implementa, a interface abaixo:

Figura 108 - Exemplo de interface para o Jogo da Forca na web

6.4.

Estudo de Caso: Modelo de um item de estoque

No item 5.4 foi apresentado um exemplo de aplicao do diagrama de estado na


gesto de um item de estoque. Este exemplo desenvolvido aqui nos seus modelos de
contexto, conceitual e detalhado, para tambm exemplificar uma aplicao da
modelagem orientada a objetos.

6.4.1.

Modelo de Contexto

O sistema em estudo representa um sistema de controle de estoque, comum em


almoxerifados de empresas de mdio e grande porte. Tais sistemas controlam a
quantidade de material em estoque com base nos parmetros de uso e reposio destes
materiais. O nmero de algoritmos e de tcnicas para se gerenciar estoque grande e
no faz parte do escopo deste trabalho analis-los. Como exemplo, toma-se uma regra
simples, que descrita em um modelo de objetos e implementada um um progama de
computador, no sistema itemDeEstoque.

Figura 109 - Sistema ItemDeEstoque e Diagrama de Casos de Uso

O diagrama descreve as funes do Almoxerife, responsvel pelo gerenciamento


dos itens de estoque e de compras responsvel pela aquisio dos itens no mercado,
para repor o estoque. Resumidamente, temos os casos de uso: Retrira Itens do Estoque
e Repoe Itens do Estoque, considerados em nosso exemplo como objetivos do ator
Almorexife no sistema de itemDeEstoque.:

Retira Itens do Estoque

O Almoxerife atende requisies de retirada de material do estoque. Se a retirada


deixar o estoque abaixo do estoque mnimo, o almoxerife cancela as prximas retiradas
e envia uma mensagem para o setor de compras para repor o material. Aps a
reposio do material, as retiradas podem ser realizadas novamente.

Repe Itens do Estoque


O Almorexerife recebe o material do setor de compras e aumenta a quantidade de
itens no estoque. Toda a reposio feita na quantidade de reposio, que definida
para cada item.

6.4.2.

Modelo Conceitual

Conceitualmente, existem 3 classes importantes neste sistema:

O diagrama de classes a seguir, representa conceitualmente o sistema


itemDeEstoque proposto. Nele a classe ItemEstoque possui os seguintes atributos e
operaes:

Figura 110 - Diagrama de classes do modelo conceitual

6.4.3.

Modelo Detalhado

Para levar este modelo conceitual a uma implementao deve-se detalhar os


processos internos da classe ItemEstoque e os eventos de retirar e repor material. Para
isso lana-se mo do diagrama de estados desta classe.
A classe itemEstoque possui dois estados claramente definidos, um estado de
estoque normal e outro estado quando o estoque est baixo. O estado definido
comparando a quantidade armazenada com um valor do estoque mnimo. Se a
quantidade for menor que o estoque mnimo o estoque est baixo. Estuda-se agora o que
os eventos de retirarMaterial e reporMaterial produzem quando a classe est em cada
um destes estados.

Figura 111 - Diagrams de estados da classe itemEstoque


A mudana do estoque normal para o estoque baixo ocorre quando h um evento de
retirada do estoque e a quantidade final inferior ao estoque mnimo, neste caso, o
comprador deve ser acionado para comprar o item. No so autorizadas retiradas
quando o estoque est baixo, e uma mensagem enviada ao comprador. A reposio do
material coloca o estoque novamente em uma condio normal. importante observar
que a quantidade de reposio deve ser superior ao estoque mnimo, para garantir que a
reposio ir sempre voltar o estoque ao normal.
Analisando diagrama acima possvel escrever um cdigo para os eventos
retirarMaterial e reporMaterial. Cada evento ser uma operao na classe ItemEstoque,
e ser capaz de atender as diferentes mudanas de estado que cada evento produz no
diagrama. Os eventos produzem diferentes mudanas de estado em funo do estado

original e das condies de disparo, que sero as condicionantes (if) no cdigo da


operao.
No exemplo, existem 3 eventos envolvidos com a retirada de material que podem
ser transcritos no cdigo, como mostra a operao retirarMaterial da classe
ItemEstoque, reproduzida abaixo. A operao isBaixo() caracateriza o estado da classe
quando o evento ocorre, e divide o processamento em dois eventos: um quando o
estado baixo (isbaixo==true) e outro quando no est baixo o estoque. No caso do
estoque no ser baixo h ainda duas opes, que so observadas no diagrama como
condies de disparo e reproduzidas no cdigo: se a quantidade existente maior que a
quantidade retirada (qtd>n) e se aps a retirada o estoque ficou baixo
(qtd<estoqueMinimo):

public boolean retirarMaterial(int n)


{
boolean ok="false;"
if (isBaixo())
{
comprador.setMensagens("Estoque Baixo");
} else
{
if (qtd>=n) {
qtd = qtd - n;
ok = true;
}
if (qtd<estoqueMinimo) {
comprador.comprar(this);

}
}
return(ok);
}

de modo anlogo pode-se traduzir o evento reporMaterial, que s processado


quando o estado original for de estoque baixo, caso contrrio retorna falso na operao
reporMaterial:

public boolean reporMaterial (int n)


{
boolean ok = false;
if (isBaixo())
{
qtd = qtd + getQtdReposicao();
comprador.setMensagens("material reposto");
ok = true;
}
return(ok);
}

Estas operaes resumem o ciclo de vida da classe ItemEstoque, que necessita


ainda das operaes de acesso para proteger os atributos. O resultado final est na

classe mostrada abaixo, que pode ser utilizada em aplicaes tpicas de gerenciamento
de estoques:

Figura 112 - Diagrama de classes do sistema itemDeEstoque


Para verificar a operao correta desta estrutura foi desenvolvido uma aplicao
que executa o gerenciamento de um item de estoque para teste. A classe Almoxerife,
que o cliente da classe ItemEstoque, implementada com um interface que permite:
Retirar uma quantidade de material (boto: Retirar)
Repor o estoque do item (boto: Repor)
Acompanhar a situao da quantidade e do estado do item. (rea de texto e
mensagens)
Verificar as mensagens de so enviadas para o setor de compras. (Caixa de
texto com a mensagem do comprador)
A figura abaixo mostra esta interface, que est genrenciando um item com os
seguintes atributos:

codigo = 101010
descrio = Tonner de copiadora
qtd = 100

estoqueMnimo = 50
qtdReposicao = 70

Figura 113 - Interface de teste do itemDeEsqtoque


Ao se retirar uma quantidade maior (55) que leva ao estoque mnimo temos que o
estoque passa a ser baixo e o comprador recebe a mensagem de comprar uma
quantidade de 70 para repor o estoque, como mostra a figura.

Figura 114 - Exemplo da comunicao ItemEstoque/Compras


Pressionando-se o boto re repor o estoque acrescido de 70 unidades e se
normaliza.

7.

Concluses

O livro desenvolve tcnicas para representar problemas de software por intermdio


de modelos orientados a objeto, seguindo a notao da UML. A abordadem proposta
permite um aumento gradual no nvel de detalhes da representao. Este aumento
causa e conseqncia do entendimento do problema que aumenta com a anlise e
construo do software. O objetivo final do modelo de software a apreenso da
complexidade do problema para que seja possvel a construo de uma soluo. Este
caminho vai depender de uma representao completa, precisa, coerente e com um
nvel de detalhes suficientemente grande, que possibilite a sua traduo em cdigos, a
serem integrados nos sistemas de software.
Nos captulos anteriores foi aprosentada a modelagem orientada a objetos em 3
tipos de modelos: o modelo de contexto, o modelo conceitual e o modelo detalhado.
Cada modelo possui uma escala e um ponto de vista prprio, e se utiliza de um conjunto
de tcnicas e de diagramas da UML para represent-lo. A tabela abaixo resume esta
combinao:

O desenvolvimento do trabalho mostra que no apenas as classes so importantes


em um sistema orientado a objetos, e destaca o importante papel desempenhado pelas
mensagens para descrever a dinmica do sistema. De modo muito parecido com uma
conversa entre as classes, o processamento de um sistema orientado a objetos um
suceder de eventos organizados para atender os objetivos do sistema.
O leitor no encontrar claramente no livro a organizao de um mtodo para

desenvolvimento de software, porque no esta a sua finalidade. Mas h sim, na forma


de apresentao dos assuntos, um caminho natural que pode ser seguido para o
entendimento de um problema, e que pode ser percorrido pelo analista como um
mtodo. Os melhores exemplos deste caminho natural so os estudos de caso, que se
utilizam da mesma seqncia de passos para desenvolver um sistema.
Cada problema exigir, no entanto, mais de um modelo do que de outro. A
finalidade para qual se est modelando condiciona a importncia que se deve dar aos
modelos. Um analista de negcio, por exemplo, que est envolvido nas primeiras etapas
da concepo de um sistema, ir dedicar mais tempo aos modelos de contexto, e talvez
um pouco menos ao modelo conceitual e no produzir nenhum modelo detalhado. O
engenheiro de software que procura garantir uma performance adequada para um
sistema, ir se dedidar, exclusivamente, aos modelos detalhados e aos diagramas de
implementao. O programador responsvel pelos cdigos poder receber um modelo
de contexto e um modelo conceitual j prontos e dever, por sua vez, produzir muitos
modelos detalhados para poder criar os componentes do sistema.
As tcnicas de modelagem orientada a objetos no terminam aqui. uma disciplina
viva da engenharia de software e passa, constantemente, por atualizaes, correes e
extenses para diversas reas de aplicao. A OMG o foro adequado para propor
mudanas e discutir as evolues da UML. Recomenda-se a visita freqente no seu
website para se manter atualizado com a UML
Apenas a atualizao terica no bastante, a prtica da modelagem necessria
para a apreenso dos conceitos. Assim como ao aprender uma lngua estrangeira
preciso falar, ao aprender uma linguagem de modelagem preciso modelar. Somente a
prtica pode dar ao modelista a habilidade necessria para obter a qualidade e
preciso na representao. Neste trabalho ao apresentar cada modelo pode-se observar
como possvel aplicar os recursos de representao em exemplos prticos, tirados de
casos simples, propostos e estudados ao longo de todo texto. Cabe agora ao leitor,
aceitar o desafio de aplicar estas tcnicas, e os diagramas da UML, para representar os
seus prprios sistemas de software, e comprovar as qualidades da modelagem
orientada a objetos.

7.1.

Referncias Bibliograficas

AMBLER, SCOTT; CRC Modeling: Bridging the Communication Gap Between


Developers and Users. November 29, 1998.
AMBLER, SCOTT; Be Realistic About the UML. 2001./ da internet/
Beck, K. e; Cunningham, W. A laboratory for teaching object-oriented thinking.
OOPSLA89 Conference Proceedings, 1989.
Beck, Kent Extreme Programming explained: embrace change. Addison Wesley
Longman, 1999.
Bellin, D.; Simone, S. The CRC Card Book. Addison-Wesley Pub Co; ISBN:
0201895358; Series on Object-Oriented Software Engineering. 1997.
BERARD, E. V. Be Careful with Use Cases, 1996. /da internet:
http://www.toa.com/pub/use_cases.htm /
BOOCH, G. Object-Oriented Analysis and Design with Application.
Benjamin/Cummings, 1994.
ECK, DAVID. The Most Complex Machine: A Survey of Computers and Computing.
A K Peters Ltd; ISBN: 1568810547; 1995.
FOWLER, M.; SCOTT, K. UML Destiled. Object Technology Series. AddisonWesley, ISBN 0201325632; 1997
HARMON, P.; WATSON, M. Understanding UML The Developer's Guide. San
Francisco, Morgan Kaufmann, 1997.
JACOBSON, I.; RUMBAUGH, J.; BOOCH, G; The Unified Modeling Language
Users Guide. Addison-Wesley Pub Co; . Object Technology Series; ISBN:
0201571684; 1998.
JACOBSON, IVAR et al. Object-Oriented Software Engineering: A Use Case
Driven Approach. Addison-Wesley Pub Co; ISBN: 0201544350; 1992
Larman, Craig. Applying UML and patterns: an introdution to object-oriented
analysis and design. Prentice Hall PTR, 1997.

OMG, Ed. OMG Unified Modeling Language 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 into Modules.
Communications of the ACM, Vol.5, No.12, December 1972, pp 1053-1058
Pfleeger, Shari Lawrence. Albert Einstein and Empirical Software Engineering.
IEEE Computer. V.32 n.10 Oct. 1999
PRESSMAN, R. S. Engenharia de Software. 3a Ed. So Paulo: Makron. 1995.
Probasco, Leslee. Dear Dr. Use Case: What About "Shall" Wording in a Use Case?.
Rational Software Canada, 2001. /da internet: http://www.therationaledge.com /
RUMBAUGH, et al. Modelagem e Projetos Baseados em Objetos. Rio de Janeiro:
Campus, 1994.
SEBESTA, ROBERT W. Concepts of Programming Languages. 3rd ed. New York:
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.

7.2.

Endereos da Internet

Seguem-se alguns endereos na internet onde se pode encontrar informaes sobre


orientao a objetos:
www.omg.org
website da Object Managment Group, entidade que rene empresas e interessados
na normatizao da tecnologia e das aplicaes orientadas a objeto. L se encontra a
documentao oficial da UML em www.omg.org/uml/ , as ltimas verses, o estado das
discusses das novas verses, referncias, e outras normas como CORBA e XML.
www.cetus-links.org
website que organiza at a data que escrevia este, mais de 18000 links para
websites sobre orientao a objetos. uma referncia obrigatria na busca de qualquer
assunto ligados tecnologia de objetos, UML, componentes, engenharia de software e
seus mais diversos padres e tpicos relacionados. O website bem cuidado e os links
so freqentemente atualizados. Em www.cetus-links.org/oo_ooa_ood_tools.html pode
ser encontrada uma lista das ferramentas CASE disponveis, com vrios programas em
demonstrao que podem ser copiados para avaliao.
www.c2.com
website da empresa de Ward Cunningham onde se pode encontrar alguns artigos
importantes sobre Objetos, inclusive o artigo original de introduo aos cartes CRC.
Curiosamente, pode-se encontrar em http://c2.com/doc/crc/draw.html a imagem dos
primeiros cartes que Cunningham e Beck utilizaram para apresentar a sua tcnica.
www.mundooo.com.br
website brasileiro com um portal bem atualizado e organizado sobre orientao a
objetos, possui diversos artigos e notcias de diversas origens, organizadas por assunto.
Possui um bom material tambm sobre Java. Dispe de um frum muito til para
discusso de assuntos relacionados a objetos, e que traduz bem a simplicidade e
praticidade da tcnica.
www.od.com.br
website de um dos mais importantes eventos sobre orientao a objetos que ocorre
no Brasil. Trata do estado da arte da tecnologia e de importantes aplicaes das

tcnicas em empresas nacionais.


www.objetos6000.com.br
website de outro importante evento patrocinado pela SUCESU-SP
(www.sucesusp.com.br) e que rene 3 tecnologias ligadas orientao a objetos:
UML, CORBA e Java.
www.rational.com
website da empresa Rational, onde originalmente foi criada a UML e hoje uma
empresa que desenvolve solues para apoio ao desenvolvimento de software usando
extensamente a UML, como na ferramenta CASE Rational Rose.
www.microgold.com
website da empresa Microgold que produz o software de CASE WithCLASS que
utilizei para produzir os modelos apresentados neste livro.
www.uml.com.br ou www.umlbrasil.com.br
um dos portais nacionais sobre a UML com link para outros portais, artigos,
tutoriais e outras informaes sobre UML e orientao a objetos.
http://java.sun.com .
website oficial da linguagem Java, no domnio da empresa Sun, onde todas as
informaes sobre a linguagem, os compliladores e mquina virtual podem ser
encontrados. Pode-se encontrar tambm tutoriais e exemplos de sistemas
desenvolvidos nesta linguagem.
www.voxxel.com.br/deboni
Meu website pessoal que mantenho dentro do portal da empresa Voxxel Consultoria
de Sistemas. Nele mantenho alguns artigos sobre o UML, Objetos, Java, novidades e
material complementar a este livro.

Glossrio
A

Abstrao

(abstraction) As caractersticas essenciais de uma entidade que a


distinguem de outra entidade. Uma abstrao define os limites da
entidade relativos perspectiva do espectador.

Ao

(action) Uma mensagem enviada quando da ocorrncia do evento,


permite a integrao entre o diagrama de estado e os diagramas de
interao.

Adorno

(adornment) Elementos grficos que aumentam a preciso da


descrio de um diagrama.

Agregao

(aggregation) Forma especial de associao que especifica uma


relao de todo-parte entre o agregado (todo) e seus componentes
(parte).

Anlise

(analisys) fase do desenvolvimento do sistema onde se identifica os


objetivos e se procura entender o problema a ser resolvido.

Analista de
sistemas

(system analiyst) profissional responsvel por realizar a anlise de


um sistema.

Arquitetura

(architecture) organizao proposta para resolver um problema,


inclui a configurao de software e hardware, e como eles se
organizam.
(signature) conjunto composto do nome, o valor de retorno e dos

Assinatura

parmetros da operao de uma classe, no inclui a sua


implementao.

Associao

(association) tipo de relacionamento entre classes onde h um certo


nvel de envolvimento entre elas, cada classe se mantm
independente, mas guardam algum tipo de significado na ligao.

Ator

(actor) representa os elementos externos ao sistema, que interagem


com ele Como um usurio que desempenha um papel no sistema,
estando fora do sistema, e no podem ser alterados pelo
desenvolvedor do sistema.

Atributo

(atribute) parte da estrutura que permite o armazenamento de


informao em uma classe, possui um tipo e um nome.

Booleano

(boolean) Tipo de enumerao que assume os valores de falso ou


verdadeiro.

Brainstorm

(brainstorm) estratgia utilizada para levantar os requisitos de um


projeto em uma reunio de trabalho.

Camada

(layer) conjunto de classes que compartilham o mesmo nvel de


abstrao ou finalidade, um layer pode ser representado por um
pacote.

Cardinalidade

(cardinality) nmero de elementos de um conjunto.


(CRC cards) Tcnica proposta por Beck e Cunnigham (1989), que

Cartes CRC

utiliza cartes de papel para representar as classes e organizar um


trabalho em equipe que identifica e descreve conceitualmente as
classes de um sistema.

CASE

Engenharia de Software Apoiada por Computador, do ingls:


Computer-Aided Software Engineering. Corresponde a programas
de computador que do suporte s atividades de engenharia de
software, principalmente as atividades de modelagem

Caso de Uso

(Use Case) seqncia de transaes ocorridas no sistema, que


refletem em algo de importncia para o ator que se comunica com
ele.

Cenrio

(scenary) instncia de um caso de uso, pode ser otimista,


alternativo ou de exceo.

(development cicle) srie de atividades que gera um software a


Ciclo de
partir dos requisitos de um problema Possui 4 atividades
desenvolvimento principais: anlise, design, construo de componentes e
integrao.

Ciclo de teste

Ciclo de vida

Classe

(test cicle) srie de atividades que verifica se o software fornecido


pelo ciclo de desenvolvimento est de acordo com os requisitos de
projeto.
(life cicle) srie de atividades entre a criao e destruio de uma
classe, software ou de outro componente de um sistema, ou at
mesmo do prprio sistema.

(class) molde para a criao de objetos, identifica um conjunto de


objetos que compartilha a mesma estrutura de dados e as mesmas
operaes. a base para a contruo de um software orientado a
objetos.

(abstract class) apenas descreve conceitos abstratos e que no


sero transformados em objetos diretamente. Uma classe
Classe abstrata
abstrata possui pelo menos uma operao abstrata, definida apenas
pela sua assinatura.

Classe concreta.

(concrete class) classe que permite a sua instanciao em objetos,


no possui nenhuma operao abstratas.

Classificao

(classification) processo de identificao das classes de um


sistema em uma hierarquia de tipos.

Cliente

(client) 1.contratante do desenvolvimento do software, interessado


pelo resultado que o software ir dar ao seu negcio. 2.classe ou
componente de software que solicita um servio a outra classe ou
componente.

Cdigo

(code) programa de computador escrito em uma linguagem de


programao.

Cdigo
executvel

(executable code) programa de computador em linguagem de


mquina, executvel em um processador.

Cdigo fonte

(source code) programa de computador em uma linguagem de


programao de alto nvel, passvel de ser compreendida por um
programador.

Colaborao

(collaboration) conjunto de interao entre classes para cumprir um


objetivo do sistema.

Comentrio

(comment) Ver nota

Componentes

(component) unidades que armazenam software e permitem a


manipulao: arquivamento, distribuio e instalao deste
software. Devem possuir uma interface bem-definida.

Comportamento

(behavior) Os efeitos observveis de uma operao ou evento, as


operaes pblicas expostas por uma classe ou componente.

Composio

(composition) relacionamento entre classes com uma forte


propriedade de posse, o todo formado pelas partes que dependem
existencialmente do todo.

Condio de
disparo

(guard condition) expresso lgica avaliada quando da ocorrncia


do evento e que condiciona a execuo do evento.

Construo

(contruction) fase do desenvolvimento onde os componentes


so criados (programados, codificados) a partir dos modelos .

Contexto

(context) conjunto de elementos relacionados que interagem para


cumprir um objetivo do sistema.

CRC

Classe, Reponsabilidade e Colaborao, do ingls: Class


Responsability and Colaboration

Delegao

(delegation) A habilidade de um objeto em compartilhar uma


responsabilidade com outro objeto, por meio da duplicao desta
operao entre eles. A delegao pode ser usada como uma
alternativa herana.
(dependency) relacionamento existente entre classes que de alguma

Dependncia

forma no est especificada pela relao, forma frace de


relacionamento.

Design

(design) fase do desenvolvimento onde se elaborar uma estratgia


para resolver o problema Na fase de design so tomadas decises
ligadas soluo do problema.

Diagrama

(diagram) representao grfica de uma coleo de elementos


relacionados: diagramas de classes, diagrama de objetos, diagrama
de casos de uso, diagrama de seqncia, diagrama de
colaborao, diagrama de estados, diagrama de atividades,
diagrama de componente, e diagrama de distribuio.

Diagrama de
objetos

(object diagram) rene objetos e as suas relaes em um instante no


tempo. Um diagrama de objeto pode ser considerado um caso
especial de um diagrama de classes..

Diagrama de
Casos de Uso

(use case diagram) descreve um modelo funcional de alto nvel do


sistema de infomaes em projeto. Identifica os usurios e
representa o sistema segundo a sua viso.

Diagrama de
Atividades

(activity diagram) representao grfica dos diferentes estados e


eventos que esto associados com um cenrio. Representa as
mensagens entre classes e os eventos intraclasse.

Diagrama de
Classes

(class diagram) mostra uma coleo esttica de elementos do


modelo seus contedos e relaes. Forma a base para a traduo em
cdigo, criando uma estrutura para orientar a construo.

Diagrama de
Colaborao

(colaboration diagram) mostra as interaes de objetos


organizadas entre os objetos e seus vnculos. Assemelha-se em
contedo ao diagrama de seqncia.

Diagrama de
Componentes

(component diagram) mostra a organizao e as dependncias entre


os componentes de software.

Diagrama de
Distribuio

(deployment diagram) mostra a configurao, em tempo de


processamento, dos ns de processamento, e os componentes,
processos e objetos que existem neles.

Diagrama de
Estados

(state diagram) mostra o ciclo de vida de uma classe na forma de


uma troca de estados provocada por eventos internos.

Diagrama de
Seqncia

(sequence diagram) mostra uma srie de mensagens entre objetos


organizadas seqencialmente no tempo. Diagramas de seqncia e
diagramas de colaborao expressam informao semelhante.

Disparo

(fire) Causa uma transio de estado.

Domnio

(domain) Uma rea de conhecimento ou atividade caracterizada por


um conjunto de conceitos e terminologias aceitas por especialistas
naquela rea.

Elemento

(element) um componente de um diagrama ou modelo.

(encapsulation) conceito fundamental dos objetos, associado ao


Encapsulamento fato que um objeto deve possuir todos os dados e as funes
necessrias para sua existncia independente.

Engenharia de
software

(software engeineering) a cincia da computao aplicada na


transformao do computador em uma ferramenta til, resolvendo

problemas para os seus utilizadores.


Engenheiro de
Software

(software engineer) o profissional que se utiliza de boas prticas


de engenharia em um projeto de software.

Enumerao

(enumeration) lista de valores identificados por nomes e usados


como uma srie para um tipo de atributo em particular.

Especificao

(specification) descrio do sistema de software ou de seu


componente, detalhando o que ele faz (ou deve fazer).

Estado

(state) caracteriza uma condio onde o objeto daquela classe pode


ser encontrado. O estado uma atividade da classe de carter lento
(estado de ao), e s vezes at esttico (estado de espera). Os
eventos provocam a mudana no estado.

Esteretipo

(stereotype) so baseados nos elementos j existentes na UML e


podem estender a semntica, mas no a estrutura destes elementos.
um dos mecanismos de extendibilidade na UML.

Evento de
tempo

(time event) evento que acontece em um momento particular. Pode


ser descrito como uma expresso de tempo.

Eventos

(event) retrata uma atividade rpida e que no pode ser


interrompida. Sempre ocorre um evento entre dois estados. Est
associado s operaes das classes, e sua dinmica.

Expresso

(expression) Uma seqncia de caracteres que resulta em um valor


de um tipo em particular. Por exemplo, a expresso " (7 + 5 * 3) "
resulta em um valor do tipo numrico.

(focus of control) smbolo em um diagrama de seqncia que


Foco de controle mostra o perodo de tempo durante o qual um objeto est executando
uma ao diretamente ou por um procedimento subordinado.
Fornecedor

(supplier) Um tipo, classe ou componente que prov servios que


podem ser invocados por outros.

Framework

(framework) micro-arquitetura que prov um modelo extensvel


para aplicaes dentro de um domnio especfico.

Generalizao

(generalization) relao existente entre um elemento mais geral e


um elemento mais especfico de uma classificao. O elemento mais
especfico totalmente consistente com o elemento mais geral e
contm informao adicional. Uma instncia do elemento mais
especfico pode ser usada sempre que o elemento mais geral for
aceito.

Granularidade

(granularity) caracterstica associada ao tamanho dos elementos de


um modelo, uma granularidade alta caracteriza uma grande
abstrao, uma granuladidade baixa leva a um alto nvel de
especificao.

GUI

Interface Grfica do Usurio, do ingls Graphics User Interface.

Herana

(inheritance) propriedade das classes de poder serem geradas a


partir de outras classes, herdando delas suas propriedades estticas
(atributos) e dinmicas (operaes) e relacionamentos.

Herana de
interface

(interface inheritance) a herana de interface de um elemento mais


genrico, como uma classe abstrata. No inclui herana da
implementao que ser realizada pela classe que herda a interface.

Herana
mltipla

(multiple inheritance) propriedade das classe em poder herdar de


mais de uma classe ao mesmo tempo. No um propriedade
facilmente implementvel.

IDE

Ambiente Integrado de Desenvolvimento, do ingls: Integrated


Development Environment

(implementation) definio de como algo construdo ou


Implementao processado. Por exemplo, uma classe a implementao de um tipo,
um cdigo a implementao (contruo) de uma classe.

Instncia

(instance) membro individual de um tipo ou uma classe. Em um uso


menos formal aceitvel se referir a um membro de uma classe
como um objeto ou uma instncia. Sinnimos de ocorrncia em
alguns casos.

Integrao

(integration) ao de colocar partes de um sistema juntas para


formar o todo. A unio das partes requer conhecimentos especficos
de configurao e de tcnicas de integrao.

Interao

(interaction) conjunto das trocas de mensagem entre um conjunto de


objetos dentro de um contexto particular para realizar um propsito
especfico. Uma interao pode ser descrita por um ou mais
cenrios.
(interface) descreve o comportamento externamente visvel de uma

Interface

classe, objeto, componente ou outra entidade. uma classe formada


apenas por mtodos abstratos, servindo para se definir uma forma
de comunicao. Descreve o conjunto de mensagens que as classes
que implementam a interface devem obedecer.

J, K,L

Linha da vida
de um objeto

(object lifeline) linha em um diagrama de seqncia que representa


a existncia de um objeto durante um certo tempo.

Mquina de
estado

(state machine) especifica as sucesses de estados que um objeto


ou uma interao passam durante sua vida, em resposta aos eventos
que recebe.

Membro

(member) parte de um tipo ou classe, pode ser representado por um


atributo ou uma operao.

Mensagem

(message) comunicao entre objetos que leva informao com a


expectativa que resultar em uma atividade. O recebimento de uma
mensagem , normalmente, considerado um evento.

Mensagem
assncrona

(asynchronous message) tipo de mensagem onde o objeto


emissor no tem sua execuo interrompida para esperar por
resultados.

Mensagem
sncrona

(synchronous message) tipo de mensagem onde o objeto


emissor pausa seu processamento para esperar por resultados.
(method) Os mtodos sugerem passos a serem seguidos para

Mtodo

cumprir o vazio existente entre a idia e o produto de software. A


implementao de uma operao. O algoritmo ou procedimento que
afetam os resultados de uma operao.

Modelo

(model) representa, simplificadamente, o que se pretende construir,


como uma planta de uma residncia. O modelo mostra no s os
requisitos do problema mas tambm como eles sero atendidos
pelos elementos da soluo.

Modelo
conceitual

(conceptual model) modelo que rene todos os conceitos presentes


no problema em estudo. Construdo em escala menor do que o
modelo de contexto, cria a estrutura do sistema, usando para isso um
modelo simplificado de classes.

Modelo
contextual

(contextual model) representa os aspectos funcionais de alto nvel


do sistema, possui uma escala grande o bastante para acomodar
todo o sistema em um nico diagrama.

Modelo
detalhado

(detailed model) incorpora todos os detalhes de uma verso


projetada do software. O modelo detalhado pode possuir um nvel
de detalhe equivalente ao cdigo do software.

Multiplicidade

(multiplicity) especifica a abrangncia da


cardinalidade permissvel que um conjunto pode assumir. Podem
ser dadas multiplicidade para papis dentro de associaes, partes
dentro de composies, repeties e em outros propsitos.

Nome

(node) representam os equipamentos em uma rede de processamento


de dados. As ligaes entre os ns representar as associaes
fsicas e lgicas existentes entre os equipamentos.
(name) seqncia de caracteres que identifica um elemento dos

diagramas.

Nota

(note) um comentrio preso a um elemento ou a uma coleo de


elementos. Uma nota no acrescenta um significado ao elemento,
pode no entanto restring-lo.

Objeto ativo

(active object) objeto que possui uma linha de controle de execuo


e pode iniciar o controle de uma atividade. Uma instncia de uma
classe ativa.

Objeto emissor (sender [object]) objeto que passa uma mensagem para um objeto
receptor.

Objeto
persistente

(persistent object) objeto que existe depois do processo ou da linha


de controle que o criou, normalmente, associado aos bancos de
dados e arquivos.

Objetos

(object) instncia de uma classe, ele implementa a classe para o


sistema. A estrutura do objetos definida pela classe, mas as
operaes e estados (valores dos atributos) so definidos na
instncia.

Operao

(operation) responsabilidades atribudas s classes, associadas ao


que a mensagens que a classe pode receber, e que definem as
funcionalidades que aquela classe est apta a realizar. So
implementadas pelos mtodos.

P
(package) elemento da UML utilizado para agrupar outros

Pacote

elementos de um sistema, para organiz-los, um pacote pode abrigar


outros elementos, outros diagramas, e at outros pacotes. Um
sistema pode ser pensado como um nico pacote de alto nvel.

Papel

(role) comportamento especficado por um nome de uma entidade


que participa de um contexto particular.

Parmetro

(parameter) varivel que pode ser alterada, transmitida ou


retornada, possui nome, tipo e direo. Parmetros so usados para
operaes, mensagens e eventos.

Polimorfismo

(polimorfism) propriedade fundamental da orientao a objetos


associada ao fato de no se precisa conhecer a instncia da classe
para utilizar seus servios. Esta propriedade leva ao fato de que
uma mesma mensagem pode ser interpretada de modos diferentes,
quando for recebida por objetos diferentes.

Ps-condio

(postcondition) Uma restrio que deve ser verdadeira na


concluso de uma operao.

Precondio

(precondition) Uma restrio que deve ser verdadeira quando uma


operao invocada.

Problema

(problem) Como todo projeto de engenharia, o projeto de software


tem como principal objetivo resolver um problema.

Processo

(process) Uma linha de controle que pode ser executada


simultaneamente com outras linhas de controle.

(development process) conjunto de passos ordenados executados


Processo de
para um determinado propsito durante o desenvolvimento de
desenvolvimento
software, que inclui construir modelos e programar.

Produto

(product) artefatos construdos durante o processo de


desenvolvimento, como modelos, diagramas, cdigos,
documentao e planos de trabalho.

(computer programmer) profissional especializado em criar


Programador de programas fonte nas diferentes linguagens de programao
computadores
existentes.

Projeto

(design) A parte do processo de desenvolvimento de software cujo


propsito principal decidir como o sistema ser implementado.
Durante o projeto so tomadas decises estratgicas e tticas para
se encontrar os requisitos funcionais e as exigncias de qualidade
de um sistema.

Pseudo-estado

(pseudo-state) vrtices de uma mquina de estado, tem a forma de


um estado, mas no se comportam como um estado como: inicial,
final, e as conexes histricas.

Qualificador

(qualifier) atributo ligados uma relao entre classes, seus


valores limitam o conjunto de objetos que participam da
associao.

Raia

(swimlane) pacote presente no diagrama de atividade, que serve


para organizar as responsabilidades associadas a um objeto.

Receptor

(receiver [object]) objeto endereado por uma mensagem passada


por um objeto emissor.

Rede

(network) ligaes entre os ns representando as associaes


fsicas e lgicas existentes entre os equipamentos.

Relao

(relationship) conexo de significados existente entre elementos do


diagrama.

Requisito

(requirement) propriedade ou comportamento desejado de um


sistema. Caracterstica de um problema que deve ser resolvida pelo
sistema.

Responsabilidade

(responsabilitiy) o que uma classe deve saber ou saber fazer,


correspondem aos atributos e s operaes de uma classe.

Restrio

(contraint) condio que limita o alcance de um elemento, as


restries fazem parte dos mecanismos de extensibilidade da UML.

Reuso

(reuse) O uso de um artefato pre-existente em outro contexto alm


daquele para o qual ele foi criado originalmente, economizando
tempo e recursos no processo de desenvolvimento.

Sinal

(signal) evento com um nome, que pode ser invocado


explicitamente, pode ser anunciado ou pode ser dirigido para um
nico objeto ou conjunto de objetos.

Sistema

(system) unio de partes com um objetivo especfico de resolver um


problema para o seus usurios. Unio de hardware e software.

Software

estratgia utilizada para resolver um problema real com apoio de


um computador, vai alm de um programa de computador

Subclasse

(subclass) especializao de outra classe, a superclasse na relao


de generalizao (herana).

Subsistemas

(subsistem) um sistema que parte de um sistema maior. Na


UML um subsistema modelado como um pacote de componentes.

Superclasse

(superclass) Em uma relao de generalizao (herana) a


generalizao de outra classe, a sub classe.

Superestados

(superstate) agrupamento de estados, e os eventos associados a


eles, que possuem um comportamento comum.

Texto

(string) seqncia de caracteres.

Thread

(trread) caminho de execuo de um programa, um modelo


dinmico, ou alguma outra representao de fluxo de controle.

Tipo

(type) define uma estrutura de dados e operaes que afetam esta


estrutura, sem a preocupao de implementar estas operaes. Um
tipo pode definir uma especificao de operao (como uma
assinatura) mas no a sua implementao.

Tipo primitivo

(primitive type) tipo bsico de um lingaugem, pr-definido, como


um inteiro ou um caracter.

Transio

(transition) indica que um objeto no primeiro estado poder ir para


um segundo estado quando um evento especificado acontecer e
condies especficas forem satisfeitas.

UML

Linguagem Unificada de Modelagem do ingls: Unified Modeling


Language

Valor

(value) Um elemento de um domnio de tipo, instncia de um


atributo.

Valor rotulado

(tagged value) definio explcita de uma propriedade pelo par:


nome-valor. Em um valor rotulado, o nome se refere ao rtulo. O
valor rotulado um dos mecanismos de extendibilidade em UML.

Vnculo

(link) conexo de significado entre objetos. A instncia de uma


associao, servem de meio para que as mensagens fluam e para a
navegabilidade no diagrama.

Viso

Visibilidade

W, X,Y,Z

(view projection) observao de um modelo a partir de uma


determinada perspectiva ou ponto de vista, omite entidades que no
so pertinentes a esta perspectiva.
(visibility) capacidade das classes de envolver em uma cpsula
atributos e operaes, ocultando ou no a informao de outras
classes que se encontram fora desta cpsula. A visibilidade pode
ser: pblica, privada ou protegida.

APNDICE

Cdigos Java dos Exemplos citados no livro


Seguem-se extratos dos programas Java que implementam os exemplos
desenvolvidos no livro. O objetivo deste apndice mostrar, com um pouco mais de
detalhes os cdigos das aplicaes desenvolvidas como exemplo para o livro. Os
comentrios sobre o cdigo, quando necessrio, esto presentes no prprio cdigo. Os
exemplos desenvolvidos para este livros podem ser executados pela internet, no
website www.eduardodeboni.com/uml dedicado a este livro..

Cdigo Java do Sistema de Vendas da Loja


Classe POS

(implementada por uma Applet)

/*
A basic extension of the java.applet.Applet class
*/

import java.awt.*;
import java.applet.*;

/**
* Applet original que chama a interface POS da loja
*
* @author JEDeboni
* @version 1.0
* @since 13/01/2003
*/
public class POS extends Applet
{

Loja aLoja;
Produto oproduto="null;"
Cliente ocliente="null;"
int parcelas="1;"

/**
* Programa principal de uma Applet.
* Aqui esto as funoes de desenhar os componentes da
interface
* e de acioar os objetos de negocio
*/
public void init()
{
/*
*

Cria os dados da Loja

*/

aLoja = new Loja();

//{{INIT_CONTROLS
setLayout(new BorderLayout(0,0));
setSize(445,92);
panel1.setLayout(new GridLayout(3,4,0,0));
add(BorderLayout.NORTH,panel1);
label1.setText("Codigo

");

label1.setAlignment(java.awt.Label.RIGHT);
panel1.add(label1);
panel1.add(textField1);

button3.setLabel("PRODUTO");
panel1.add(button3);
button3.setBackground(java.awt.Color.lightGray);
panel1.add(textField2);
label2.setText("CGC

");

label2.setAlignment(java.awt.Label.RIGHT);
panel1.add(label2);
panel1.add(textField3);
button1.setLabel("CLIENTE");
panel1.add(button1);
button1.setBackground(java.awt.Color.lightGray);
panel1.add(textField4);
label3.setText("N. parcelas");
label3.setAlignment(java.awt.Label.RIGHT);
panel1.add(label3);
panel1.add(textField5);
button5.setLabel("PARCELAS");
panel1.add(button5);
button5.setBackground(java.awt.Color.lightGray);
panel1.add(textField6);
button2.setLabel("Limpar");
add(BorderLayout.SOUTH,button2);
button2.setBackground(java.awt.Color.lightGray);
//}}

//{{REGISTER_LISTENERS
SymAction lSymAction = new SymAction();
button1.addActionListener(lSymAction);
button3.addActionListener(lSymAction);
button5.addActionListener(lSymAction);
button2.addActionListener(lSymAction);
//}}
}

//{{DECLARE_CONTROLS
java.awt.Panel panel1 = new java.awt.Panel();
java.awt.Label label1 = new java.awt.Label();
java.awt.TextField textField1 = new java.awt.TextField();
java.awt.Button button3 = new java.awt.Button();
java.awt.TextField textField2 = new java.awt.TextField();
java.awt.Label label2 = new java.awt.Label();
java.awt.TextField textField3 = new java.awt.TextField();
java.awt.Button button1 = new java.awt.Button();
java.awt.TextField textField4 = new java.awt.TextField();
java.awt.Label label3 = new java.awt.Label();
java.awt.TextField textField5 = new java.awt.TextField();
java.awt.Button button5 = new java.awt.Button();
java.awt.TextField textField6 = new java.awt.TextField();
java.awt.Button button2 = new java.awt.Button();
//}}

class SymAction implements java.awt.event.ActionListener


{

/**
* Captura os eventos da interface e os transfere para a
Applet
*
* @param event evento capturado
*/
public void actionPerformed(java.awt.event.ActionEvent
event)
{
Object object = event.getSource();
if (object == button1)
button1_ActionPerformed(event);
else if (object == button3)
button3_ActionPerformed(event);
else if (object == button5)
button5_ActionPerformed(event);
else if (object == button2)
button2_ActionPerformed(event);
}
}

/**

* Ao do boto CLIENTE
* que obtem um Cliente da lista com base no seu CGC
*
* @param event
*/
void button1_ActionPerformed(java.awt.event.ActionEvent
event)
{
try{
int cgc = Integer.parseInt(textField3.getText());
oCliente = aLoja.getCliente(cgc);
textField4.setText(oCliente.getNome());
} catch(Exception e){
textField4.setText("Erro");
}

}
/**
* Ao do boto PRODUTO
* Obtem um produto da lista de produtos com base no codigo
*
* @param event
*/

void button3_ActionPerformed(java.awt.event.ActionEvent
event)
{
try{
int codigo = Integer.parseInt(textField1.getText());
oProduto = aLoja.getProduto(codigo);
textField2.setText(oProduto.getDescricao());
} catch(Exception e){
textField2.setText("Erro");
}
}
/**
* Ao do boto PARCELAS
* Verifica se a venda esta aprovada com base no produto e
* no cliente ja identificados.
*
* @param event
*/
void button5_ActionPerformed(java.awt.event.ActionEvent
event)
{

try{
Parcelas = Integer.parseInt(textField5.getText());
boolean ok = oProduto.isAprovado(Parcelas, oCliente);
if (ok) {

textField6.setText(" Aprovada");
} else {
textField6.setText(" No Aprovada");
}
}catch(Exception e){
textField6.setText("Erro");
}
}
/**
* Ao do boto Limpar
* limpa os campos anteriores para facilitar uma nova
consulta
*
* @param event
*/
void button2_ActionPerformed(java.awt.event.ActionEvent
event)
{
// to do: code goes here.
textField1.setText("");
textField2.setText("");
textField3.setText("");
textField4.setText("");
textField5.setText("");
textField6.setText("");

}
}

Classe BDLoja

/**
* Classe auxiliar que inicializa a loja.
*/
public

class BDLoja

/**
* Numero de Clientes da Loja
*/
private int N_CLIENTES;

/**
* Numero de produtos da lista
*/
private int N_PRODUTOS;

/**
* Classe auxiliar que implementa a persistencia dos dados dos
produtos e clientes
* Eh uma classe que e chamada na in cializaao da loja.

* Ela guarda os dados dos clientes em codigo.


* Em aplicaoes comerciais deveria ser substituida por acesso
a um banco de dados
*/
public BDLoja(){
/*
Definir a quantidade de dados da loja
*/
N_CLIENTES = 5;
N_PRODUTOS = 9;
}

/**
* Obtem a lista de produtos da loja, cadastrados na classe
BDLoja
*
* @return Array de produtos armazenados na Loja
*/
public Produto[] getListaP() {
Produto listaP[] = new Produto[10];
listaP[1] = new Produto(101,"Guitarra Solo Fender",2000);
listaP[2] = new Produto(102,"Saxofone",800);
listaP[3] = new Produto(103,"Bateria Eletrnica",750);
listaP[4] = new Oferta(104,"Piano de Calda",5000);
listaP[5] = new Produto(105,"Guitarra Baixo",1000);
listaP[6] = new Produto(106,"Violo",200);

listaP[7] = new Produto(107,"Trompete",500);


listaP[8] = new Produto(108,"Flauta doce",100);
listaP[9] = new Oferta(109,"Baixo Acstico",1500);
return listaP;
}

/**
* Obtem o Numero de produtos da lista
*
* @return Numero de produtos da lista
*/
public int getNPRODUTOS() {
return N_PRODUTOS;
}

/**
* Obtem a lista de clientes da loja, armazenados na classe
BDLoja
*
* @return Array de Clientes
*/
public Cliente[] getListaC() {
Cliente listaC[] = new Cliente[10];
listaC[1] = new Cliente(1000,"Stan Getz",1000);
listaC[2] = new ClienteVIP(2000,"H. Hancock",1000);

listaC[3] = new Cliente(3000,"Charlie Parker",500);


listaC[4] = new ClienteVIP(4000,"Charlie Mingus",500);
listaC[5] = new Cliente(5000,"Miles Davis",300);

return listaC;
}

/**
* Obtem o numero de clientes da lista
*
* @return Numero de clientes da lista
*/
public int getNCLIENTES() {
return N_CLIENTES;
}

Classe Loja

/**
* Classe que representa a Loja no sistema
*

* @author JEDeboni
* @version 1.0
* @since 2003
*/
public

class Loja

/**
* Array de produtos que implementa um catlogo de produto
*/
protected Produto listaP[] = new Produto[10];

/**
* array de clientes, que implementa um catlogo de clientes
*/
protected Cliente listaC[] = new Cliente[10];

/**
* Numero de clientes do catalogo
*/
protected int N_CLIENTES;

/**
* Numero de produtos do catalogo
*/

protected int N_PRODUTOS;

/**
* objeto que representa o banco de dados, da acesso aos dados
persistentes
*/
BDLoja bd = new BDLoja();;

public Loja(){
/**
* Construtor padrao da classe Loja.
* Aciona os mtodos de acesso a lista de clientes e produtos da
classe BDLoja
*/
listaP = bd.getListaP();
N_PRODUTOS = bd.getNPRODUTOS();
listaC = bd.getListaC();
N_CLIENTES = bd.getNCLIENTES();
}

/**
* Pesquisa na lista de produtos um produto com um determinado
indice
*
* @param index numero inteiro que indica o indice do produto
na lista
* O indice deve estar dentro dos limites da lista

* @return O produto da lista com o indice


*/
public Produto getProdutoIndex( int index) {
return (listaP[index]);
}

/**
* Mtodo de acesso ao Cliente da lista com base no indice
*
* @param index indice do cliente na lista. O indice deve estar
dentro do limite da lista
* @return um cliente que esta na lista
*/
public Cliente getClienteIndex( int index) {
return (listaC[index]);
}

/**
* mtodo de acesso ao cliente com base no CGC
* o mtodo pesquisa a lista de clientes para encontrar o
cliente que possui este CGC
*
* @param pCGC numero do CGC
* @return Um cliente da lista com base no CGC
*/
public Cliente getCliente(int pCGC){

Cliente c = null;
for (int i="1;" i<=N_CLIENTES; i++){
if (listaC[i].getCGC()==pCGC)
{
c = listaC[i];
}
}
return (c);
}

/**
* Mtodo de pesquisa da lista de produtos por um produto que
possui um codigo
*
* @param pCodigo codigo do produto
* @return um produto com base no codigo da lista
*/
public Produto getProduto(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, representa os 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 do produto com base apensas no codigo.
* Deve-se usar os metodos de acesso para complementar as
informaoes
*
* @param pCodigo codigo do produto.

*/
public Produto ( int pCodigo) {
codigo = pCodigo;
return;
}

/**
* metodo contrutor do produto com todos os parametros.
*
* @param pCodigo codigo do produto
* @param pDescricao descricao do produto
* @param pPreco preco do produto
*/
public Produto (int pCodigo, String pDescricao, int pPreco) {
preco = pPreco;
codigo = pCodigo;
descricao = pDescricao;
return;
}

/**
* metodo de acesso ao preco do produto
*
* @return valor atual do preco do produto
*/

public

int getPreco () {

return preco;
}

/**
* metodo para atualizao do preco do produto
*
* @param pPreco valor do novo preco do produto
*/
public void setPreco (int pPreco) {
preco = pPreco;
}

/**
* metodo de acesso a descricao do produto
*
* @return a descriao atual do produto
*/
public String getDescricao(){
return(descricao);
}

/**
* metodo para atualizao da descriao do produto
*

* @param pDescricao nova descricao do produto


*/
public void setDescricao(String pDescricao){
descricao = pDescricao;
}

/**
* metodo de acesso ao codigo do produto
*
* @return o codigo do produto
*/
public int getCodigo() {
return codigo;
}

/**
* metodo que transforma os dados do produto em uma String de
texto
* para facilitar a impressao
*
* @return String com uma descriao do produto.
*/
public String toString() {
String s = "n";
s = s + getCodigo();

s = s + " "+getDescricao();
s = s + " R$ "+getPreco();
return s;
}
/**
* mtodo de verificao da aprovao do Crdito
* verificando as regras de venda a crdito para
* um dado cliente
*
* @param n numero de parcelas da venda
* @param c objeto que representa o Cliente que e o comprador
do produto
* @return verdadeiro se a venda foi aprovada e falso se a
venda for recusada
*/
public boolean isAprovado(int n, Cliente c){
/*
em linhas gerais a venda aprovada se a dvida
da venda for menor que o crdito 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 um produto em oferta.
*
* @author JEDeboni
* @version 1.0
* @since 2003
*/
public class Oferta extends Produto
{
/**
* mtodo de verificao da aprovao do Crdito
* verificando as regras de venda a crdito para um cliente
*
* @param n numero de parcelas da venda
* @param c objeto que representa o cliente comprador do
produto

* @return verdadeiro se a venda for aprovada, ou falso se a


venda nao for aprovada
*/
public boolean isAprovado(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 produto em Oferta

*
* @param pCodigo codigo do produto
* @param pDescricao descrio do produto
* @param pPreco preo do produto
*/
public Oferta (int pCodigo, String pDescricao, int pPreco) {
super (pCodigo, pDescricao, pPreco);
return;
}

Cdigo Java do Jogo da Velha


Segue-se o cdigo completo do jogo da velha na sua implementao bsica.

Classe Forca
import javax.swing.JOptionPane;

/**
* Classe principal, que integra as outras na implementaao do
jogo
*
* @author JEDeboni
* @version 1.0
*/
public class Forca {
/**
* objeto boneco usado no jogo
*/
private static Boneco

boneco = new Boneco();

/**
* objeto ppalavra que implementa a Palavra secreta no jogo
*/
private static Palavra palavra = new Palavra();

/**
* objeto j que representa o jogador no jogo
*/
private static Jogador jogador = new Jogador();
/**
* programa principal do jogo da forca
*
* @param arg no utilizado
*/

public static void main(String arg[]){


char letra;
String tela="";
palavra.escolheSecreta();
do {
//
// constroi o desenho da forca,
// da palava e das letras usadas
tela = boneco.desenha()+"n"
+palavra.desenha()+"n"
+jogador.getLetrasChutadas();
//
// captura uma letra entrada pelo usuario
letra="JOptionPane".showInputDialog(tela).toCharArray()[0];
//

// Envia mensagem ao jogador para entrar a letra no jogo


jogador.chutaLetra(letra, palavra, boneco);
}while(!(jogador.ganhar(palavra)||jogador.perder(boneco)));
//
// envia uma mensagem final
if (jogador.ganhar(palavra))
{
tela = tela + "n Parabens! ganhou!";
};
if (jogador.perder(boneco))
{
tela = tela + "n Que pena, perdeu!";
};
JOptionPane.showMessageDialog(null,tela,
"Jogo da Forca",JOptionPane.INFORMATION_MESSAGE);

System.exit(0);
}
}

Cdigo da Classe Palavra


import java.io.*;

/**

* Representa a palavra secreta no jogo da forca.


* A classe permite escolher uma palavra de uma lista arquivada
* e verificar se a letra esta n palavra
*
* @author JEDeboni
* @version 1.0
* @since 2002
*/
public class Palavra
{

/**
* array com as letras da palavra escolhida que e mantida
secreta
*/
private char[] palavraEscolhida =

new char[100];

/**
* array com as letras ja descobertas da palavra
*/
private char[] palavraDescoberta =

new char[100];

/**
* numero de letras existente na palavra escolhida
*/

private int np = 0;

/**
* seleciona aleatoriamente uma palavra de uma lista
* armazenada em no arquivo ListaPalavras e
* inicializa a palavra a ser descoberta com '_'
* vao existir tantos tracos quantas letras na palavra
*/
public void escolheSecreta () {
String linha[] = new String[200];
try
{
//
// abre o arquivo
FileInputStream ds = new
FileInputStream("ListaPalavras.txt");
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 = new Double(Math.random()*lp).intValue();
np="linha"[iescolhido].length();
//
// preenche de espaos "_" a palavra descoberta
for (i="0;" i<np; i++){
palavraEscolhida[i+1]=linha[iescolhido].toCharArray()
[i];
palavraDescoberta[i+1]='_';
}
} catch (IOException e)
{
System.out.println("Erro na leitura do arquivo de
palavras");
System.out.println(e);
}
}

/**
* metodo para desenhar a palavra secreta
*
* @return retorna um texto com a palavra secreta
* tracos marcam as letras nao descobertas
*/

public

String desenha()

{
String linha=" ";
for (int i="1;" i<=np; i++) {
linha = linha + palavraDescoberta[i]+" ";
}
return(linha);
}
/**
* verifica se a letra esta na palavra secreta
*
* @param letra letra a ser testada na palavra
* @return verdadeiro se a letra est na palavra ou falso se
nao esta
*/
public

boolean letraNaPalavra (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 palavra esta completa ou nao
* procurando espaos "_" na palavra 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 da Palavra
*/

public Palavra ()
{
// no existe construo especial para a palavra
}
}

Classe Jogador
/**
* Representa o Jogador no jogo da forca
* Permite que o jogador interaja com o jogo chutando as letras
para adivinhar a palavra secreta
* Esta classe ainda guarda a palavra secreta
*
* @author JEDeboni
* @version 1.0
*/
public

class Jogador

/**
* numero de letras chutadas at o momento
*/
private int iletra="0;"

/**

* lista de letras chutadas no jogo


*/
private char[]letrasChutadas = new char[50];

/**
* retorna uma lista das letras chutadas no jogo
*
* @return uma lista das letras chutadas
*/
public String getLetrasChutadas(){
String linha="Letras usadas: ";
for (int i="1;" i<=iLetra; i++)
{
linha="linha"+letrasChutadas[i];
}
return(linha);
}

/**
* adiciona uma letra na lista de letras chutadas
*
* @param letra letra a ser adicionada na lista
*/
public void addLetrasChutadas(char letra){

iletra="iLetra"+1;
letrasChutadas[iLetra]=letra;
}

/**
* le uma letra para tentar completar a palavra secreta e
* verifica se a letra esta na palavra, e desenha uma parte do
* boneco se no tiver.
*
* @param letra letra a ser verificada
* @param palavra palavra a ser descoberta
* @param boneco boneco que representa o jogador na forca
*/
public void chutaLetra (char letra, Palavra palavra, Boneco
boneco)
{
addLetrasChutadas(letra);
if (!palavra.letraNaPalavra(letra))
{
boneco.addParte();
}
}

/**
* operaao que verifica se o jogador ganhou

*
* @param palavra palavra a ser descoberta, se for completa o
jogador ganhou
* @return verdadeiro de o jogador ganhou, falso se no ganhou
*/
public boolean ganhar(Palavra palavra)
{
return(palavra.isCompleta());
}

/**
* Operaao que verifica se o jogador perdeu
*
* @param boneco boneco que representa o jogador, se for
completo o jogador perdeu
* @return verdadeiro de o jogador perdeu, falso se no perdeu
*/
public boolean perder(Boneco boneco)
{
return(boneco.isCompleto());
}

/**
* contrutor do Jogador, nao possui parametros
*/
public Jogador ()

{
// no existe construtor especial para o Jogador
}

Classe Boneco
/**
* Representa o boneco do jogo da forca
*
* @author JEDeboni
* @version 1.0
* @since 2002
*/
public

class Boneco

{
/**
* numero de partes desenhadas do boneco.
* Comea com zero e termina com 6 (boneco completo)
*/
private int parte="0;"

/**

* Matriz de 3x3 que desenha a forca


*/
private char[][] Dforca =

new char[4][4];

/**
* inicializa a forca, zerando a matriz Dforca
* uso privado internamente ao boneco
*/
private void limpaForca ()
{
parte = 0;
Dforca[1][1]=' '; Dforca[1][2]=' '; Dforca[1][3]=' ';
Dforca[2][1]=' '; Dforca[2][2]=' '; Dforca[2][3]=' ';
Dforca[3][1]=' '; Dforca[3][2]=' '; Dforca[3][3]=' ';
}

/**
* inclui mais uma parte no boneco, o boneco esta previsto para
* ser construido com 6 partes
*/
public void addParte()
{
parte="parte"+1;
if (parte==1) Dforca[1][2]='O'; //

desenha cabea

if (parte==2) Dforca[2][1]='/'; //

desenha bracoE

if (parte==3) Dforca[2][2]='|'; //
if (parte==4) Dforca[2][3]='';//

desenha corpo
desenha bracoD

if (parte==5) Dforca[3][1]='/'; //
if (parte==6) Dforca[3][3]='';//

desenha pernaE
desenha pernaD

/**
* desenha o boneco na forma de texto
*
* @return texto com o desenho de um boneco e da forca feito
com caracteres
*/
public String desenha()
{
String

linha = "n /-----";

linha = linha + "n |

"+Dforca[1][1]+Dforca[1][2]+Dforca[1]

linha = linha + "n |

"+Dforca[2][1]+Dforca[2][2]+Dforca[2]

linha = linha + "n |

"+Dforca[3][1]+Dforca[3][2]+Dforca[3]

[3];

[3];

[3];
linha = linha + "n |

";

linha = linha + "n |_________";


return(linha);
}

/**
* verifica se o boneco esta completo
*
* @return verdadeiro se o boneco esta completo ou false se nao
estiver
*/
public boolean isCompleto() {
if (parte==6) {
return(true);
} else {
return(false);
}
}

/**
* mtodo construtor da classe Boneco
* este metodo limpa a forca e prepara para colocar um boneco
* a forca e representada por uma matrix 3x3 Dforca
*/
public Boneco ()
{
limpaForca();
}
}

Cdigo Java do Item de Estoque


Classe Almoxerife
import java.awt.*;
import java.applet.*;

/**
* Classe de interface do sistema itemEstoque,
* realiza as aoes de capturar os eventos do usurio,
* enviar mensagens para a classe de negocio e
* exibir o resultado na interface
*
* @author JEDeboni
* @version 1.0
* @since 2003
*/
public class Almoxerife extends Applet
{

/**
* objeto que representa o item de estoque a ser gerenciado
*/
ItemEstoque item;

/**
* objeto que representa o comprador que gerencia este item de
estoque
*/
Compras comprador;

/**
* operaao de inicializaao da Applet Almoxerife
*/
public void init()
{
//{{INIT_CONTROLS
setLayout(new BorderLayout(0,0));
setSize(426,266);
panel1.setLayout(new FlowLayout(FlowLayout.CENTER,5,5));
add(BorderLayout.NORTH, panel1);
label1.setText("Almoxerife: quantidade");
panel1.add(label1);
textField1.setText("0");
panel1.add(textField1);
btnRetirar.setLabel("Retirar");
panel1.add(btnRetirar);
btnRetirar.setBackground(java.awt.Color.lightGray);
btnRepor.setLabel("Repor");
panel1.add(btnRepor);

btnRepor.setBackground(java.awt.Color.lightGray);
textArea1.setText("Historico das transaes");
add(BorderLayout.CENTER, textArea1);
panel2.setLayout(new FlowLayout(FlowLayout.CENTER,5,5));
add(BorderLayout.SOUTH, panel2);
label2.setText("Mensagem ao comprador");
panel2.add(label2);
panel2.add(textField2);
//}}

comprador = new Compras();


item = new ItemEstoque("101010", "Tonner de copiadora",
100, 70, 50, comprador);
textArea1.append(item.toString());

//{{REGISTER_LISTENERS
SymAction lSymAction = new SymAction();
btnRetirar.addActionListener(lSymAction);
btnRepor.addActionListener(lSymAction);
//}}
}

//{{DECLARE_CONTROLS
java.awt.Panel panel1 = new java.awt.Panel();
java.awt.Label label1 = new java.awt.Label();

java.awt.TextField textField1 = new java.awt.TextField(2);


java.awt.Button btnRetirar = new java.awt.Button();
java.awt.Button btnRepor = new java.awt.Button();
java.awt.TextArea textArea1 = new java.awt.TextArea();
java.awt.Panel panel2 = new java.awt.Panel();
java.awt.Label label2 = new java.awt.Label();
java.awt.TextField textField2 = new java.awt.TextField(25);
//}}

class SymAction implements java.awt.event.ActionListener


{

/**
* operaao para capturar os eventos da interface
*
* @param event evento vindo do usurio e
* que devem ser tratados pela classe
*/
public void actionPerformed(java.awt.event.ActionEvent
event)
{
Object object = event.getSource();
if (object == btnRetirar)
btnRetirar_ActionPerformed(event);
else if (object == btnRepor)

btnRepor_ActionPerformed(event);
}
}

/**
* operacao que trata o evento de Retirar,
* le o valor da quantidade a ser retirada,
* envia uma mensagem de retirar para o itemEstoque e
* exibe o resultado na interface
*
* @param event evento vindo da aao do usurio
*/
void btnRetirar_ActionPerformed(java.awt.event.ActionEvent
event)
{
int n = Integer.parseInt(textField1.getText());
if (item.retirarMaterial(n))
{
textArea1.append("nn*** Ao :

Retirar "+n);

} else
{
textArea1.append("nn*** Ao de Retirar bloqueada");
}
textArea1.append(item.toString());
textField2.setText(comprador.getMensagens());

/**
* operaao que trata o evento de repor,
* envia uma mensagem de repor para o itemEstoque e
* exibe o resultado na interface
*
* @param event evento vindo da interface do usuario
*/
void btnRepor_ActionPerformed(java.awt.event.ActionEvent
event)
{
int n = Integer.parseInt(textField1.getText());
if (item.reporMaterial(n))
{
textArea1.append("nn*** Ao

Repor "+n);

} else {
textArea1.append("nn*** Ao

de Repor bloqueada");

}
textArea1.append(item.toString());
textField2.setText(comprador.getMensagens());
}
}

Classe ItemEstoque

/**
* Representa o item de um sistema de estoque gerenciado
* A regra de controle de estoque nao permite
* que se faa uma retirada se o 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 item de estoque,
* com todos os atributos como parametros

*
* @param pCodigo Codigo unico do item de estoque,
* @param pDescricao Descriao textual breve do item
* @param pQtd Quantidade armazenada no item,
* nao pode ser menor do que o estoque minimo.
* @param pQtdReposicao Quantidade que deve ser reposta
* @param pEstoqueMinimo Valor do estoque minimo do item, ao
atingir o estoque minimo e' disparada ao comprador um pedido de
compra
* @param pComprador Objeto do tipo Compras que representa o
comprador responsavel por repor este item.
*/
public ItemEstoque(String pCodigo,
String pDescricao,
int pQtd,
int pQtdReposicao,
int pEstoqueMinimo,
Compras pComprador)
{
codigo = pCodigo;
descricao = pDescricao;
qtd = pQtd;
qtdReposicao = pQtdReposicao;
estoqueMinimo = pEstoqueMinimo;
comprador = pComprador;
}

/**
* metodo chamado para retirada

dos itens do estoque

*
* @param n quantidade de itens a serem retirados
* @return verdadeiro se o material foi retirado
* <br> ou falso se o material nao foi retirado
*/
public boolean retirarMaterial(int n)
{
boolean ok="false;"
if (isBaixo())
{
comprador.setMensagens("Estoque Baixo");
} else
{
if (qtd>=n) {
qtd = qtd - n;
ok = true;
}
if (qtd<estoqueMinimo) {
comprador.comprar(this);
}
}
return(ok);

/**
* metodo chamado na reposicao dos itens no estoque
*
* @param n quantidade de itens a ser reposta,
mantida para haver coerencia com a retirada,

* (deve ser sempre igual aa qtdReposicao)


* @return verdadeiro se a houver a reposicao do material
* <br> falso se a reposicao no ocorrer porque o estoque
estava normal
*/
public boolean reporMaterial (int n)
{
boolean ok = false;
if (isBaixo())
{
qtd = qtd + getQtdReposicao();
comprador.setMensagens("material reposto");
ok = true;
}
return(ok);
}

/**
* Metodo de acesso a quantidade de itens de estoque
*
* @return quantidade em estoque
*/
public int getQtd ()
{
return(qtd);
}

/**
* metodo de acesso a quantidade de reposicao
*
* @return quantidade a ser reposta
*/
public int getQtdReposicao ()
{
return(qtdReposicao);
}

/**
* metodo de acesso ao valor do estoque minimo
*
* @return quantidade de estoque minimo
*/

public int getEstoqueMinimo ()


{
return(estoqueMinimo);
}

/**
* operaao de acesso a descricao do item
*
* @return descricao do item
*/
public String getDescricao()
{
return(descricao);
}

/**
* operao de definiao da quantidade de reposicao
*
* @param pQtdReposicao nova quantidade de reposicao
*/
public void setQtdReposicao (int pQtdReposicao)
{
qtdReposicao = pQtdReposicao;
}

/**
* operacao de definicao do estoque minimo
*
* @param pEstoqueMinimo novo valor do estoque minimo
*/
public void setEstoqueMinimo (int pEstoqueMinimo)
{
estoqueMinimo = pEstoqueMinimo;
}

/**
* operacao que verifica se o estoque esta atualmente baixo
*
* @return verdadeiro se o estoque esta baixo,
* <br> e falso se o estoque estiver normal
*/
public boolean isBaixo()
{
boolean ok = false;
if (getQtd()<getEstoqueMinimo()) {
ok = true;
}
return(ok);
}

/**
* operacao que fornece uma descricao textual do item
*
* @return texto que descreve o item em seu estado atual.
*/
public String toString()
{
String s = "n"+codigo+" Item : "+descricao+
"n
Estoque = "+qtd+" Mnimo =
"+estoqueMinimo+" Reposicao = "+qtdReposicao+
"n

Estoque baixo : "+isBaixo();

return(s);
}
}

Classe Comprador

/**
* Classe que representa o setor 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 a atividade (estado) do comprador
*/
private String mensagens;

/**
* metodo contrutor do objeto da classe Compras,
* inicia informando que nao ha mensagens no comprador
*/
public Compras()
{
mensagens = "no h mensagens";
}

/**
* le as mensagens do comprador
*
* @return mensagem armazenada no comprador
*/
public String getMensagens()
{
return(mensagens);

/**
* define uma mensagem para o comprador
*
* @param pMensagens nova mensagem para armazenar
*/
public void setMensagens(String pMensagens)
{
mensagens = pMensagens;
}

/**
* operacao de comprar,
* futuramente devera implementar os processos de compras
*
* @param item ItemEstoque a ser comprado
*/
public void comprar(ItemEstoque item)
{
setMensagens("comprar "+item.getQtdReposicao()+"
"+item.getDescricao());
}

Notas de Rodap

[1]

Adaptao do software ao cliente, originaria da palavra: customer, cliente em


ingls.
[2]

CGC Cadatro Geral de Contribuinte, substitudo pelo CPF, Cadastro de


Pessoas Fsicas, um nmero nico que identifica os contribuintes do Imposto de Renda,
e que usado para identificar unicamente o cliente.
[3]

As funes so escritas usando uma conveno de notao em ingls: get para


obter, set para definir e is para verificar se falso ou verdadeiro.
[4]

A expresso super.getCredito( ) significa, na linguagem Java, que se est


chamando o mtodo getrCredito da classe me (super). No caso o mtodo getCredito da
classe ClienteVIP chama o mtodo getCredito da classe Cliente
[5]

Object_Oriented Systems, Languages e Applications. Conferncia annual sobre a


tecnologia de objetos.
[6]

CRC significa Class, Responsability and Colaboration. Em alguns artigos tem


sido encontrato tambem Contract no lugar de Colaboration, mas com um significado
equivalente.
[7]

Object Managment Group, organizao de padronizao de assuntos ligados


orientao objetos.
[8]

Optou-se por no acentuar os nomes das classes, atributos e operaes para


facilitar a transio do modelo para cdigos, j que a maioria das linguagens de
implementao no d suporte acentuao dos seus componentes.
[9]

GUI do ingls, Graphics Users Interface, interface grfica do usurio