Você está na página 1de 904

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, discutese 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 executlos. 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 autopeas 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 cliente s 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 verifica-se 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 prfabricadas. 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 realizla.

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

[1]

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 definese 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. Descrevese 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 chamase 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. Problema

Contexto do

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. 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
[2]

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

Modelo

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 adquir-los. 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 auto-suficiente 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 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.
[3]

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.getCred ) ) public int getCredito () { return (credito); } public int getCredito () { 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. Devese 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 chamam-se 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 organizlos, 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, abandona-se 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 representla. 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. Criando-se 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 afast-los do processo de

desenvolvimento. O uso de um retroprojetor, quadro-branco, flip-chart, 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 sugere-se, 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. Subsistemas

Descrio de

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) (c)

(b)

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 Operao getCredito do do [4] Cliente ClienteVIP public int getCredito() {

public int getCredito () {

return return(credito); (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. carto CRC

Histrico do

Os cartes CRC foram introduzidos por Kent Beck e Ward Cunningham em 1989 na 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 WirfsBrock (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
[5]

e da sua aplicao. Mais recentemente Kent Beck (1999) refere-se novamente tecnica dos cartes CRC nas fases de modelagem da aplicao do seu mtodo XP (eXtreme Programming) de desenvolvimento rpido. 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
[6]

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 a. Identificar e Distribuir as responsabilidades, b. Caracterizar os colaboradores, e c. Simular a dinmica do cenrio, validando o modelo.

5. 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 Usu Local:_________________ 1 2 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 , devese 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. Podese 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. resquisitos

Analisar os

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 ajud-la, 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, identificase uma nova classe para assumir as

responsabilidades, se no existir podese 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, temse 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. Desejase 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. Contexto

Modelo de

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

Modelo

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. Representamse 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. Observa-se 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.

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.

[7]

5.1.1. UML

Histrico da

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 ProntuarioMedico so nomes adequados para classes.
[8]

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. Supondose, 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. Seqncia

Diagrama de

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

Diagrama de

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, tem-se 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 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
[9]

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

Modelo

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: que representa a interface

POS

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

Modelo

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. Devese 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).toCh [0];

// // Envia mensagem ao jogador para entrar com letra no jogo jogador.chutaLetra(letra, palavra, boneco); }while(! (jogador.ganhar(palavra)||jogador.perder(

if (jogador.ganhar(palavra)) {tela = tela + "n Parabens! ganhou!"; }; if (jogador.perder(boneco))

{tela = tela + "n Que pena, perdeu!";};

JOptionPane.showMessageDialog(null,tel

"Jogo da Forca",JOptionPane.INFORMATION_ME

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

Modelo de

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

Modelo

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

Modelo

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. Addison-Wesley, 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. AddisonWesley Pub Co; ISBN: 0201544350; 1992 Larman, Craig. Applying UML and patterns: an introdution to objectoriented 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 10531058 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.cetuslinks.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 essenci uma entidade que a distinguem de outra ent Uma abstrao define o limites da entidade rela perspectiva do espec

(action) Uma mensage enviada quando da

Ao

ocorrncia do evento, permite a integrao en diagrama de estado e o diagramas de interao

Adorno

(adornment) Elemento grficos que aumentam preciso da descrio diagrama.

Agregao

(aggregation) Forma especial de associao especifica uma relao todo-parte entre o agre (todo) e seus compone (parte).

Anlise

(analisys) fase do desenvolvimento do si onde se identifica os objetivos e se procura entender o problema a resolvido.

Analista de sistemas

(system analiyst) profissional responsv realizar a anlise de um sistema.

Arquitetura

(architecture) organiza proposta para resolver problema, inclui a configurao de softwa

hardware, e como eles organizam.

Assinatura

(signature) conjunto composto do nome, o v de retorno e dos parm da operao de uma cl no inclui a sua implementao.

Associao

(association) tipo de relacionamento entre c onde h um certo nvel envolvimento entre ela classe se mantm independente, mas guar algum tipo de significa

ligao.

Ator

(actor) representa os elementos externos ao sistema, que interagem ele Como um usurio q desempenha um papel sistema, estando fora d sistema, e no podem s alterados pelo desenvo do sistema.

Atributo

(atribute) parte da estr que permite o armazen de informao em uma classe, possui um tipo nome.

Booleano

(boolean) Tipo de enumerao que assum valores de falso ou verdadeiro.

Brainstorm

(brainstorm) estratgia utilizada para levantar requisitos de um projet uma reunio de trabalh

Camada

(layer) conjunto de cla que compartilham o me nvel de abstrao ou finalidade, um layer po representado por um pa

Cardinalidade

(cardinality) nmero d elementos de um conju

Cartes CRC

(CRC cards) Tcnica proposta por Beck e Cunnigham (1989), que utiliza cartes de pape representar as classes organizar um trabalho e

equipe que identifica e descreve conceitualme classes de um sistema.

CASE

Engenharia de Software Apoiada por Computador, do ingls Computer-Aided Softw Engineering. Correspo programas de computa que do suporte s ativ de engenharia de software, principalmen atividades de modelag

(Use Case) seqncia transaes ocorridas n

Caso de Uso

sistema, que refletem e de importncia para o que se comunica com e

Cenrio

(scenary) instncia de caso de uso, pode ser otimista, alternativo ou exceo.

(development cicle) s atividades que gera um software a partir dos Ciclo de requisitos de um probl desenvolvimento Possui 4 atividades principais: anlise, des construo de compone integrao.

Ciclo de teste

(test cicle) srie de atividades que verifica software fornecido pel de desenvolvimento es acordo com os requisit projeto.

Ciclo de vida

(life cicle) srie de atividades entre a cria destruio de uma clas software ou de outro componente de um sist ou at mesmo do prpr sistema.

Classe

(class) molde para a cr de objetos, identifica u conjunto de objetos qu compartilha a mesma estrutura de dados e as mesmas operaes. a para a contruo de um software orientado a o

(abstract class) apena descreve conceitos abs e que no sero transformados em obje Classe abstrata diretamente. Uma clas abstrata possui pelo me uma operao abstrata, definida apenas pela su assinatura.

(concrete class) classe permite a sua instancia Classe concreta. em objetos, no possui nenhuma operao abs

Classificao

(classification) proces identificao das class um sistema em uma hierarquia de tipos.

Cliente

(client) 1.contratante d desenvolvimento do software, interessado p resultado que o softwa dar ao seu negcio. 2.c

ou componente de softw que solicita um servio outra classe ou compon

Cdigo

(code) programa de computador escrito em linguagem de programa

Cdigo executvel

(executable code) prog de computador em ling de mquina, executve um processador.

(source code) program computador em uma linguagem de programa

Cdigo fonte

de alto nvel, passvel compreendida por um programador.

Colaborao

(collaboration) conjun interao entre classes cumprir um objetivo do sistema. (comment) Ver nota

Comentrio

Componentes

(component) unidades armazenam software e permitem a manipula arquivamento, distribu instalao deste softwa

Devem possuir uma in bem-definida.

(behavior) Os efeitos observveis de uma op Comportamento ou evento, as operae pblicas expostas por classe ou componente.

Composio

(composition) relacionamento entre c com uma forte propried de posse, o todo form pelas partes que depen existencialmente do tod

Condio de disparo

(guard condition) expresso lgica avali quando da ocorrncia d evento e que condicion execuo do evento.

Construo

(contruction) fase do desenvolvimento onde componentes so criad (programados, codifica partir dos modelos .

Contexto

(context) conjunto de elementos relacionado interagem para cumprir objetivo do sistema.

CRC

Classe, Reponsabilida Colaborao, do ingls Class Responsability a Colaboration

Delegao

(delegation) A habilid um objeto em compart uma responsabilidade outro objeto, por meio duplicao desta opera entre eles. A delegao ser usada como uma alternativa herana.

Dependncia

(dependency) relacion existente entre classes alguma forma no est especificada pela rela forma frace de relacionamento.

Design

(design) fase do desenvolvimento onde elaborar uma estratgia resolver o problema N de design so tomadas decises ligadas solu do problema.

Diagrama

(diagram) representa grfica de uma coleo elementos relacionado diagramas de classes, diagrama de objetos, diagrama de casos de u diagrama de seqncia diagrama de colaborao, diagrama estados, diagrama de atividades, diagrama d componente, e diagram distribuio.

Diagrama de objetos

(object diagram) rene objetos e as suas rela um instante no tempo. U diagrama de objeto pod

considerado um caso especial de um diagram classes..

Diagrama de Casos de Uso

(use case diagram) de um modelo funcional d nvel do sistema de infomaes em projeto Identifica os usurios e representa o sistema se a sua viso.

Diagrama de Atividades

(activity diagram) representao grfica d diferentes estados e ev que esto associados c cenrio. Representa as

mensagens entre classe eventos intraclasse.

Diagrama de Classes

(class diagram) mostra coleo esttica de ele do modelo seus conte relaes. Forma a base a traduo em cdigo, criando uma estrutura p orientar a construo.

Diagrama de Colaborao

(colaboration diagram mostra as interaes de objetos organizadas en objetos e seus vnculos Assemelha-se em conte ao diagrama de seqn

Diagrama de Componentes

(component diagram) a organizao e as dependncias entre os componentes de softwa

Diagrama de Distribuio

(deployment diagram mostra a configurao, tempo de processamen ns de processamento, componentes, processo objetos que existem ne

Diagrama de

(state diagram) mostra ciclo de vida de uma c na forma de uma troca

Estados

estados provocada por eventos internos.

Diagrama de Seqncia

(sequence diagram) m uma srie de mensagen objetos organizadas seqencialmente no tem Diagramas de seqnc diagramas de colabora expressam informao semelhante.

Disparo

(fire) Causa uma transi estado.

(domain) Uma rea de

Domnio

conhecimento ou ativid caracterizada por um conjunto de conceitos e terminologias aceitas p especialistas naquela

Elemento

(element) um compone um diagrama ou model

(encapsulation) conce fundamental dos objeto associado ao fato que u Encapsulamento objeto deve possuir tod dados e as funes

necessrias para sua existncia independent

Engenharia de software

(software engeineerin cincia da computao aplicada na transforma computador em uma ferramenta til, resolve problemas para os seus utilizadores.

Engenheiro de Software

(software engineer) profissional que se util boas prticas de engen em um projeto de softw

Enumerao

(enumeration) lista de valores identificados p nomes e usados como u srie para um tipo de a em particular.

Especificao

(specification) descri sistema de software ou seu componente, detal o que ele faz (ou deve

Estado

(state) caracteriza uma condio onde o objeto daquela classe pode se encontrado. O estado atividade da classe de carter lento (estado de

ao), e s vezes at es (estado de espera). Os eventos provocam a mu no estado.

Esteretipo

(stereotype) so basea nos elementos j existe na UML e podem esten semntica, mas no a estrutura destes elemen um dos mecanismos de extendibilidade na UM

Evento de tempo

(time event) evento qu acontece em um momen particular. Pode ser de como uma expresso d

tempo.

Eventos

(event) retrata uma ativ rpida e que no pode interrompida. Sempre o um evento entre dois es Est associado s oper das classes, e sua din

Expresso

(expression) Uma seq de caracteres que resul um valor de um tipo em particular. Por exemplo expresso " (7 + 5 * 3) resulta em um valor do numrico.

(focus of control) smb em um diagrama de seqncia que mostra o perodo de tempo dura Foco de controle qual um objeto est executando uma ao diretamente ou por um procedimento subordin

Fornecedor

(supplier) Um tipo, cla componente que prov servios que podem se invocados por outros.

Framework

(framework) microarquitetura que prov u modelo extensvel para aplicaes dentro de u domnio especfico.

Generalizao

(generalization) rela existente entre um elem mais geral e um elemen mais especfico de uma classificao. O eleme mais especfico total consistente com o elem

mais geral e contm informao adicional. instncia do elemento m especfico pode ser usa sempre que o elemento geral for aceito.

Granularidade

(granularity) caracter associada ao tamanho d elementos de um mode uma granularidade alta caracteriza uma grande abstrao, uma granula baixa leva a um alto n especificao.

Interface Grfica do Us

GUI

do ingls Graphics Us Interface.

Herana

(inheritance) propried das classes de poder se geradas a partir de outr classes, herdando dela propriedades estticas (atributos) e dinmicas (operaes) e relacionamentos.

(interface inheritance herana de interface de

Herana de interface

elemento mais genrico como uma classe abstrata. No inclui he da implementao que realizada pela classe q herda a interface.

Herana mltipla

(multiple inheritance propriedade das classe poder herdar de mais d classe ao mesmo tempo um propriedade facil implementvel.

IDE

Ambiente Integrado de Desenvolvimento, do i Integrated Developme Environment

(implementation) defin de como algo constru processado. Por exem Implementao uma classe a implementao de um t um cdigo a impleme (contruo) de uma cla

(instance) membro individual de um tipo o classe. Em um uso men formal aceitvel se re

Instncia

um membro de uma cla como um objeto ou um instncia. Sinnimos d ocorrncia em alguns c

Integrao

(integration) ao de colocar partes de um s juntas para formar o to unio das partes requer conhecimentos especf configurao e de tcni integrao.

(interaction) conjunto trocas de mensagem en conjunto de objetos de um contexto particular

Interao

realizar um propsito especfico. Uma intera pode ser descrita por u mais cenrios.

Interface

(interface) descreve o comportamento externa visvel de uma classe, componente ou outra entidade. uma classe formada apenas por m abstratos, servindo par definir uma forma de comunicao. Descrev conjunto de mensagens classes que implementa interface devem obede

J, K,L

Linha da vida de um objeto

(object lifeline) linha e diagrama de seqncia representa a existncia objeto durante um certo tempo.

Mquina de estado

(state machine) especi sucesses de estados q objeto ou uma intera passam durante sua vid

resposta aos eventos q recebe.

Membro

(member) parte de um classe, pode ser repres por um atributo ou uma operao.

Mensagem

(message) comunica objetos que leva inform com a expectativa que resultar em uma ativid O recebimento de uma mensagem , normalme considerado um evento

Mensagem assncrona

(asynchronous messag de mensagem onde o o emissor no tem sua execuo interrompida esperar por resultados.

Mensagem sncrona

(synchronous message de mensagem onde o o emissor pausa seu processamento para es por resultados.

Mtodo

(method) Os mtodos sugerem passos a serem seguidos para cumprir vazio existente entre a o produto de software.

implementao de uma operao. O algoritmo procedimento que afeta resultados de uma oper

Modelo

(model) representa, simplificadamente, o q pretende construir, com planta de uma residnc modelo mostra no s requisitos do problema tambm como eles ser atendidos pelos elemen soluo.

(conceptual model) mo que rene todos os con

Modelo conceitual

presentes no problema estudo. Construdo em escala menor do que o modelo de contexto, cr estrutura do sistema, us para isso um modelo simplificado de classe

Modelo contextual

(contextual model) representa os aspectos funcionais de alto nve sistema, possui uma escala grande o bastan acomodar todo o sistem um nico diagrama.

(detailed model) incor

Modelo detalhado

todos os detalhes de um verso projetada do software. O modelo detalhado pode possuir nvel de detalhe equiva ao cdigo do software.

Multiplicidade

(multiplicity) especific abrangncia da cardinalidade permiss que um conjunto pode assumir. Podem ser da multiplicidade para pa dentro de associaes, dentro de composies repeties e em outros propsitos.

(node) representam os equipamentos em uma rede de processamento dados. As ligaes ent ns representar as associaes fsicas e l existentes entre os equipamentos.

Nome

(name) seqncia de caracteres que identific elemento dos diagrama

Nota

(note) um comentrio p um elemento ou a uma coleo de elementos. nota no acrescenta um significado ao element pode no entanto restrin

Objeto ativo

(active object) objeto possui uma linha de co de execuo e pode ini controle de uma ativida Uma instncia de uma c ativa.

(sender [object] ) obje Objeto emissor passa uma mensagem p objeto receptor.

Objeto persistente

(persistent object) obj que existe depois do processo ou da linha d controle que o criou, normalmente, associad bancos de dados e arqu

Objetos

(object) instncia de um classe, ele implementa classe para o sistema. estrutura do objetos definida pela classe, m

operaes e estados (v dos atributos) so defin na instncia.

Operao

(operation) responsabilidades atrib s classes, associadas a mensagens que a clas pode receber, e que de as funcionalidades que aquela classe est apta realizar. So implemen pelos mtodos.

Pacote

(package) elemento da UML utilizado para ag outros elementos de um sistema, para organizum pacote pode abriga outros elementos, outro diagramas, e at outros pacotes. Um sistema po pensado como um nic pacote de alto nvel.

Papel

(role) comportamento especficado por um no uma entidade que parti de um contexto particu

(parameter) varivel q

Parmetro

pode ser alterada, trans ou retornada, possui n tipo e direo. Parme so usados para opera mensagens e eventos.

Polimorfismo

(polimorfism) propried fundamental da orienta objetos associada ao fa no se precisa conhece instncia da classe par utilizar seus servios. E propriedade leva ao fa que uma mesma mensa pode ser interpretada d modos diferentes, quan recebida por objetos diferentes.

Ps-condio

(postcondition) Uma restrio que deve ser verdadeira na conclus uma operao.

Precondio

(precondition) Uma restrio que deve ser verdadeira quando uma operao invocada.

Problema

(problem) Como todo de engenharia, o projet software tem como pri objetivo resolver um problema.

Processo

(process) Uma linha de controle que pode ser executada simultaneam com outras linhas de controle.

(development process conjunto de passos ordenados executados Processo de um determinado prop desenvolvimento durante o desenvolvim de software, que inclui construir modelos e programar.

Produto

(product) artefatos construdos durante o processo de desenvolvimento, como modelos, diagramas, c documentao e planos trabalho.

(computer programme profissional especializ Programador de em criar programas fon computadores diferentes linguagens d programao existentes

(design) A parte do pr de desenvolvimento de software cujo propsit

Projeto

principal decidir com sistema ser implemen Durante o projeto so tomadas decises estratgicas e tticas p encontrar os requisitos funcionais e exigncias de qualidad um sistema.

Pseudo-estado

(pseudo-state) vrtice uma mquina de estado forma de um estado, m se comportam como um estado como: inicial, fi as conexes histricas.

Qualificador

(qualifier) atributo liga uma relao entre class seus valores limitam o conjunto de objetos qu participam da associa

Raia

(swimlane) pacote pre no diagrama de atividade, que serve pa organizar as responsabilidades asso a um objeto.

Receptor

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

Rede

(network) ligaes ent ns representando as associaes fsicas e l existentes entre os equipamentos.

Relao

(relationship) conexo significados existente e elementos do diagrama

Requisito

(requirement) propried ou comportamento dese de um sistema. Caracte de um problema que de resolvida pelo sistema

(responsabilitiy) o que classe deve saber ou s Responsabilidadefazer, correspondem ao atributos e s operae uma classe.

Restrio

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

parte dos mecanismos extensibilidade da UM

Reuso

(reuse) O uso de um ar pre-existente em outro contexto alm daquele qual ele foi criado originalmente, econom tempo e recursos no pr de desenvolvimento.

(signal) evento com um nome, que pode ser inv explicitamente, pode se

Sinal

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

Sistema

(system) unio de parte um objetivo especfico resolver um problema seus usurios. Unio de hardware e software.

Software

estratgia utilizada par resolver um problema com apoio de um computador, vai alm d programa de computad

Subclasse

(subclass) especializa outra classe, a supercla relao de generalizao (herana

Subsistemas

(subsistem) um sistema parte de um sistema ma Na UML um subsistem modelado como um pa componentes.

Superclasse

(superclass) Em uma r de generalizao (hera a generalizao de outr classe, a sub classe.

Superestados

(superstate) agrupame estados, e os eventos associados a eles, que possuem um comportam comum.

T (string) seqncia de caracteres.

Texto

Thread

(trread) caminho de execuo de um progra um modelo dinmico, o alguma outra represent

de fluxo de controle.

Tipo

(type) define uma estru de dados e operaes q afetam esta estrutura, s preocupao de implem estas operaes. Um ti pode definir uma especificao de opera (como uma assinatura) no a sua implementa

Tipo primitivo

(primitive type) tipo b de um lingaugem, pr definido, como um inte um caracter.

Transio

(transition) indica que objeto no primeiro esta poder ir para um segu estado quando um even especificado acontecer condies especficas satisfeitas.

UML

Linguagem Unificada d Modelagem do ingls: Unified Modeling Lan

Valor

(value) Um elemento d domnio de tipo, instn um atributo.

Valor rotulado

(tagged value) defini explcita de uma propr pelo par: nome-valor. valor rotulado, o nome refere ao rtulo. O val rotulado um dos mecanismos de extendibilidade em UM

(link) conexo de signi entre objetos. A instnc

Vnculo

uma associao, servem meio para que as mens fluam e para a navegabilidade no diag

Viso

(view projection) observao de um mod partir de uma determin perspectiva ou ponto d vista, omite entidades q no so pertinentes a e perspectiva.

(visibility) capacidade classes de envolver em cpsula atributos e operaes, ocultando o

Visibilidade

a informao de outras classes que se encontra desta cpsula. A visibilidade pode ser: pblica, privada ou protegida.

W, X,Y,Z

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.Labe panel1.add(label1);

panel1.add(textField1);

button3.setLabel("PRODUTO"); panel1.add(button3);

button3.setBackground(java.awt.Co

panel1.add(textField2); label2.setText("CGC ");

label2.setAlignment(java.awt.Labe panel1.add(label2);

panel1.add(textField3);

button1.setLabel("CLIENTE");

panel1.add(button1);

button1.setBackground(java.awt.Co

panel1.add(textField4); label3.setText("N. parcelas");

label3.setAlignment(java.awt.Labe panel1.add(label3);

panel1.add(textField5);

button5.setLabel("PARCELAS"); panel1.add(button5);

button5.setBackground(java.awt.Co

panel1.add(textField6);

button2.setLabel("Limpar");

add(BorderLayout.SOUTH,button2);

button2.setBackground(java.awt.Co //}}

//{{REGISTER_LISTENERS SymAction lSymAction

= new SymAction();

button1.addActionListener(lSymAct

button3.addActionListener(lSymAct

button5.addActionListener(lSymAct

button2.addActionListener(lSymAct //}} }

//{{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.Ac 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) { try{ int cgc = Integer.parseInt(textField3.getTe oCliente = aLoja.getCliente(cgc);

textField4.setText(oCliente.getNo } 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) { try{ int codigo = Integer.parseInt(textField1.getTe oProduto = aLoja.getProduto(codigo);

textField2.setText(oProduto.getDe } 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) {

try{ Parcelas = Integer.parseInt(textField5.getTe 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) { // 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 { private private int codigo = 0; int preco = 0; class Produto

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 = new Boneco(); 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".showInputDial [0]; // // Envia mensagem ao jogador para entrar a letra no jogo jogador.chutaLetra(letra, palavra, boneco); }while(! (jogador.ganhar(palavra)||jogador // // 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(nul "Jogo da Forca",JOptionPane.INFORMATION_ME

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 = char[100];

new

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

new

/** * 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.tx 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[iesco [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 linha=" "; String desenha()

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 { /** * numero de partes desenhadas do boneco. class 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]='|'; // desenha corpo if (parte==4) Dforca[2] [3]='';// desenha bracoD if (parte==5) Dforca[3] [1]='/'; // desenha pernaE if (parte==6) Dforca[3] [3]='';// desenha pernaD }

/**

* desenha o boneco na 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][3]; linha = linha + "n | "+Dforca[2][1]+Dforca[2]

[2]+Dforca[2][3]; linha = linha + "n | "+Dforca[3][1]+Dforca[3] [2]+Dforca[3][3]; linha = linha + "n | linha = linha + "n |_________"; return(linha); } ";

/** * verifica se o boneco 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

btnRepor.setLabel("Repor"); panel1.add(btnRepor);

btnRepor.setBackground(java.awt.C

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(lSym

btnRepor.addActionListener(lSymAc //}} }

//{{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.Ac 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.a event) { int n = Integer.parseInt(textField1.getTe 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.getM

/** * 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) { int n = Integer.parseInt(textField1.getTe if (item.reporMaterial(n)) {

textArea1.append("nn*** Ao Repor "+n); } else {

textArea1.append("nn*** Ao Repor bloqueada");

de

textArea1.append(item.toString())

textField2.setText(comprador.getM } }

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 "+isBaixo();

Estoque baixo :

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

Adaptao do software ao cliente, originaria da palavra: customer, cliente em ingls. 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.
[2]

[1]

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. 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 Object_Oriented Systems, Languages e Applications. Conferncia annual sobre a tecnologia de objetos.
[6] [5] [4]

[3]

CRC significa Class, Responsability

and Colaboration. Em alguns artigos tem sido encontrato tambem Contract no lugar de Colaboration, mas com um significado equivalente. Object Managment Group, organizao de padronizao de assuntos ligados orientao objetos. 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. GUI do ingls, Graphics Users Interface, interface grfica do usurio
[9] [8] [7]