Dedicatória Ao Ao meu filho, Murilo, Muril o, pelo estímulo, estí mulo, carinho e compreensão.
A quem qu em se destina este livro Este livro livr o se destina a diferentes classes class es de leitores, leitores , que tem em comum comum o desejo dese jo de conhecer técnicas para se descrever um software, seja porque são profissionais da área da computação, computação, seja sej a porqu porq ue acreditam acr editam que um um software software possa ajudá-los a melhorar melhorar o seu negócio, seja ele qual for. Os leitores deste livro podem ser: · encontrar neste livro apoio para o Estudantes e Professores que podem encontrar desenvolviment desenvolvimentoo de cursos de Engen Engenharia haria de Software Software,, de An Anális álisee e Projeto de Sistemas Sistemas e para o desenvolviment desenvolvimentoo de projetos pr ojetos de soft s oftware ware.. Apesar da abordagem dada a este trabalho não ter uma ênfase didática, ele pode ser utilizado como uma leitura complementar. Especialmente nos capítulos iniciais, onde o livro tece os fundamentos da orient ori entação ação a objetos, o teor int i ntrodut rodutório ório pode ser se r de grande ajuda a estudantes estudantes de computação e áreas afins. · Analistas de Sistema e Programadores de Computador envolvidos em projetos de sistem si stemas as de software, que encont encontrarão rarão reun r eunidas idas neste livro alg al gumas umas técnicas técnicas úteis para o desenvolvimento de modelos orientados a objeto destes projetos. A adoção destas técnicas pode ajudá-los a construir construir sistemas sistemas de software mais robustos, mais mais confiáveis e de manutenção mais fácil.
Usuár Usuários ios ou Geren Gere ntes te s de Proje Projeto to de Software Software que podem adotar algumas · das idéias presentes no livro para facilitar o planejamento de um projeto de software. A leitura ajudará a criar uma linguagem comum entre o usuário, o gerente de projeto e a equipe técnica de desenvolvimento. Como um projeto orientado a objetos requer uma grande dose de modelagem, este livro pode uniformizar os termos usados na comu comunicação com a equipe equipe de projeto e ajudar a definir as etapas e produt pr odutos os do projeto de software.
Convenções adotadas neste livro Para facilitar facil itar a leitura, l eitura, este livro livr o adota as segu s eguint intes es convenções tipográficas: tipográficas: · Os termos e conceitos concei tos importantes importantes para o texto texto são escri esc ritos tos em negrito na na primeira vez em que eles aparecem aparece m. Estes termos termos podem ser encontrados encontrados novament novamentee no glossário, ao final do livro, onde recebem uma breve explicação. · Os comandos comandos e extratos de código, códi go, escritos escr itos em ling li nguag uagem em de program progra mação usam fonte currier, assim como os nomes de componentes e elementos do modelo, quando citados no texto são escritos também em fonte currier, para diferenciá-los do seu significado significado fora do escopo esc opo do programa. programa. · As citações, os extratos extratos de textos textos da bibliograf bibli ografia ia e palavras palavr as em língua língua estrangeira estrangeira são escritos esc ritos com caractér itálico. · A lista lis ta de referências bibliográf bibli ográficas icas escontra-se no final final do livro. livr o. Qu Quando ando citadas no texto, as referências aparecem entre parênteses com o nome do autor e o ano de publicação. publicação . Por exemplo: exemplo: (Beck, 1999) ou citado por Beck (1999). · Os endereços de websites citados no texto e na bibliografia que podem ser acessados pela internet são gri grifados fados como no exemplo: exemplo: www.omg.org
1. Introdução Este capítulo capít ulo discute a importância de se criar cri ar um modelo modelo nos projetos de software. Inicialmente, Ini cialmente, apresenta apres enta o caráter dualista duali sta do software: soft ware: ora produto da criatividade, ora trabalho sistemático de engenharia, para então discutir o porquê, em ambos os casos, o modelo do software ser colocado no centro do processo de desenvolvimento, como forma de unificar a visão do software entre os participantes do projeto. O capítulo termina fazendo uma apresentação do restante do livro e de como ele pode ser lido.
1.1.
Introdu Introdução ção ao Desenvolvi Desenvolvim mento de Software Software
software é um produto da inteligência humana, por meio dele é possível se preservar preser var uma uma boa idéia idéi a e transm transmití-la ití-la para pa ra muit muitas as outras outras pessoas. pes soas. O software software é uma das poucas maneiras disponíveis capazes de capturar o conhecimento de alguém e colocá-lo colocá- lo à serviço servi ço de outros. outros. Existem Existem algum algumas formas formas para pa ra se s e fazer isso, isso , como como os livros livr os ou as aulas nas escolas, escol as, mas nenhu nenhum ma delas del as tem a capacidade capacida de de interação interação que o software oferece, e que pode transformar o conhecimento capturado, diretamente, em uma habilidade para o seu usuário. Um usuário, de posse de um software adequadament adequadamentee contruído, contruído, passa p assa a ter novas habilidades habili dades e pode fazer fazer coisas c oisas que antes antes não 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 conversão, discute-se aqui como se transforma uma idéia em um software útil. Como se captura uma idéia para que o desenvolvedor crie um sistema de software que irá dar esta habilidade ao usuário:
Figura 1- O software pode transformar uma idéia em uma habilidade Na constru construção ção de um softwar softwaree existe um uma boa dose de criativida cr iatividade, de, mas mas há um uma dose ainda maior de pensamento lógico e trabalho discipliando. O computador, uma das maiores invenções 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. Além da criatividade são necessários métodos, procedim procedi mentos entos e muita uita discipl di sciplina ina para criar um software útil. Toda esta organização organização é conseqüência conseqüência da d a distân dis tância cia que separa separ a os comput computadores adores dos homens, e das suas idéias. Os computadores são meros autômatos, sabem realizar com grande grande velocidade, vel ocidade, e por repetidas vezes, tarefas simples, escritas escr itas em um um programa programa de computador. Os programas de computador são seqüências de comandos simples escritos em uma linguagem de programação que pode ser entendida pelo computador, e que ainda está muito longe da linguagem humana, e da complexidade do pensamento humano.
A distância entre o conhecimento humano e as linguagens de programação se reflete nas inúmeras 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 estratégia utilizada utilizada para resolver resol ver um problem proble ma real rea l com apoio de um computador. Mais do que uma série organizada de instruções, o software atende uma finalid finalidade, ade, serve ser ve a um objetivo do seu utilizador. utilizador. Nesta visão, o software se s e completa completa ao hardware, hardwa re, o computador computador propriamen prop riamente te dito, e seus equipament equipamentos os periféric pe riféricos, os, que em conjunto compõem o que se pode chamar de sistema com co mputacional. O conjunto conjunto de partes relativa rel ativa ao software no sistema sistema comput computacional acional é o chamado chamado sistem siste ma de software . A atividade de program pr ogramação ação de computadores computadores é apenas uma uma etapa do trabalho de desenvolvimento de um software. Programar é escrever a solução de um problema, que á 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 solução. Desenvolver softwar softwaree é resolver res olver problemas por intermédio intermédio da programação programação de com c omput putadores adores é uma uma atividade de engenharia, da assim chamada “ Engenharia de Software”. ci ência da com c omput putação ação aplica a plicada da na transform transformação ação do do Engenharia de Software é a ciência computador em uma ferramenta de trabalho para os seus utilizadores. Ela é aplicada hoje aos mais diferentes diferentes desafios, des afios, desde a manipulação manipulação de dados adm a dministrativos inistrativos em um um sistema de informação gerencial até a transmissão de voz e imagem em equipamentos de telecomunicação. O software é hoje uma tecnologia onipresente. Do telefone ao despertador, da televisão ao supermercado, do brinquedo ao avião, do elevador à internet , o software está presente, dando uma importante contribuição à produtividade das empresas e à qualidade de vida das pessoas. Pressman (1995) destaca a importância da Engenharia de Software afirmando, que as práticas de engenharia de software se intensificaram com o agravamento dos problem proble mas relativos rel ativos ao software: a) A sofisticação dos problemas ultrapassaram a nossa capacidade de construir software que extraia o potencial oferecido pelo hardware, b) Nossa capacidade capac idade de construir construir software de qualidade qualidad e não pode acompanh acompanhar ar a demanda demanda por novas aplicações apl icações da computação, computação, e c) Nossa capacidade capacid ade de manter anter os software existentes existentes foi ameaçada ameaçada por p or projetos pro jetos ruins ruins e recursos inadequ i nadequados ados
Observa-se, nestas considerações, que a Engenharia de Software lida intimamente com as lim li mitações da capacidade ca pacidade hu hum mana em criar software. O cresci c rescim mento ento do poder dos microprocessadores torna mais aparente os limites da nossa capacidade de conceber e criar software que aproveite todo esta potencialidade. As demandas crescent cresce ntes es por po r parte par te dos usuários pressionam pre ssionam os desenvolvedores de senvolvedores para uma uma lu l uta contra contra o tempo na busca por bons projetos de software, que possam ser construídos e mantidos adequadament adequadamente. e. Os problemas pr oblemas atuais, atuais, a serem se rem resolvidos pelo softwar software, e, não apenas se tornaram complexos, eles estão se modificando continuamente, e se integrando a outros problem proble mas, igualm igualment entee complexos, complexos, em uma uma rede global de com co mputadores putadores que é a di gitalização da inf i nform ormação, ação, por p or exem e xemplo, plo, ajuda a criar cria r novas demandas demandas internet . A dig por software, com a possibili possi bilidade dade da distribuição distri buição ampla ampla da informação informação promovida pela internet . Aparentem Aparentement ente, e, a distân di stância cia ent e ntre re os desafios propostos pr opostos para o software e as linguag linguagens ens de program pr ogramação ação disponíveis para construí-los construí-los é int i ntranspon ransponível. ível. As linguagens se mantém relativamente simples, com instruções elementares, criando programas programas de computador computador longos, longos, ambígos ambígos e sujeitos sujeitos à muitas muitas falhas. falhas. A principal razão desta limitação é a própria arquitetura das máquinas de Von Neumann, base de todos comput computadores adores e processador proc essadores es com c omerci erciais ais existentes existentes hoje (Eck, 1995). Este uso, quase quase universal, da arquitetura de Von Neumann, como base para os computadores é o fator mais importante para o projeto de linguagens de programação, e conseqüentemente, dos métodos disponíveis para se criar software, como observa Sebesta (1996). Para se aproxim ap roximar ar o mun undo do dos problem proble mas reais r eais do univers universoo virtu vi rtual al de d e um comput computador ador é necessário necessári o que se selecione selec ione um paradigm paradi gmaa único, no qual se possam descrever os problemas reais, ao mesmo tempo, que possuam uma trqadução direta para a ling l inguag uagem em do comput computador. ador. A busca busca deste paradigm paradi gmaa pode ser usada para retratar o histórico das ling l inguag uagens ens de prog pro gramação ramação desde d esde a sua criação, criaçã o, e resulta no que que hoje são as linguagens de programação que se utilizam do paradigma de objetos, as chamadas linguagens orientadas a objetos. Essencialmente, a programação orientada a objetos busca a solução dos problemas de software pela identificação objetos do mundo real, que são depois traduzidos em outros objetos de um modelo de software (Sebesta, 1996). 1996) . As ling l inguag uagens ens orientadas a objeto obj eto como como Java, Jav a, Delphi, Visual Visual Basic, Basi c, C++ e C# facilitam esta tradução por se utilizarem dos mesmos fundamentos do paradigm paradi gmaa de objetos que foram foram usados na modelagem modelagem.. A disponibilidade disponibilidad e e ampla ampla divulgação divulgação destas de stas linguages linguages são as grandes grandes motivador motivadoras as para par a a evolução ev olução da análise e do projeto proj eto de sistem sis temas as orient or ientados ados a objeto, como como tentat tentativas ivas para se s e transpor o abism abi smoo entre entre as boas idéias i déias e o soft so ftware ware que as implement implementaria aria.. Este livro objetiva capacitar analistas, programadores e gerentes de projeto de
software na construção de um modelo orientado a objetos de um problema do mundo real. A principal meta deste trabalho é organizar um conjunto coerente de técnicas de análise e projeto de sistemas sistemas orient or ientados ados a objetos, de modo que que o modelo construído construído por estas técnicas sirva de d e ponte ponte para a construção construção do software.
1.2.
Como Como este livro está organizado
Para cumprir os objetivos propostos para este livro, a construção de modelo de um sistema sistema de software foi dividida di vidida em 6 capítu capí tulos, los, um glossário de termos termos e um apêndice, que são descritos a seguir:
Capítulo 1 – Introdução . Apresenta esta introdução aos objetivos do livro, a organização proposta, como ele pode ser lido, o seu público alvo e destaca a importância da modelagem para o desenvolvimento de software. Capítulo 2 - Fundamentos da Modelagem Orientada a Objetos . Apresenta os conceitos fundam fundament entais ais da orient ori entação ação a objetos e a sua relação com o processo proces so de desenvolviment desenvolvimentoo de softwar software. e. As características car acterísticas que diferem a abordagem abor dagem de objetos obj etos das outras outras abordagens abordagens são s ão aqui a qui descritas descri tas com detalhe. detalhe. Os conceitos de encapsulam encapsulament ento, o, herança, mensagens ensagens e polimorfismo pol imorfismo são definidos e exempli exemplificado ficadoss por um uma aplicação aplic ação simples de autom automação ação comercia comercial.l. É um capítulo de leitura obrigat obri gatória ória para quem deseja desej a revisar revis ar os o s conceitos da tecnologia tecnologia de objetos e conh conhecer ecer a nomenclatu nomenclatura ra utilizada no restante restante do livro. livr o. Aos leitores que já possuem estes conceitos, a leitura leitura deste capítulo capítulo pode ser dispensada. di spensada. Apresenta o primeiro modelo modelo a ser Capítulo 3 - O Modelo de Contexto. Apresenta desenvolvido para uma uma abordagem abor dagem inicial de um problem proble ma de softwar software. e. O modelo modelo de contexto é um modelo alto nível baseado na análise funcional, que visa definir a fronteira fronteira do sistema sistema e os seus objetivos principais. pr incipais. Neste modelo modelo são utilizados os diagramas de casos de uso propostos por Jacobson (1992) e adotados porteriormente pela UML UML (Jacobson, (Jacobs on, 1998). A fronteira fronteira isola iso la o sistem sis temaa de software dos component componentes es externos ao software, mas que interagem com ele. Este capítulo é especialmente importan importante te para os leitores l eitores envolvidos nas defin de finições ições iniciais de um sistema sistema computacional, que devem, em contato direto com os clientes do software, especificar os requisitos re quisitos do sistem si stema. a.
Capít Capítu ulo 4 - O Modelo Conceitual apresentado é baseado nos cartões CRC. Descreve a técnica dos cartões car tões CRC aplicada na definição inicial de um sistema sistema orientado a objetos. obj etos. Esta técnica utili utiliza za cartões comuns comuns de arquivo para p ara represent repres entar ar os objetos, e ajudam a judam na distribuição das fun funcionalidades esperadas espera das entre os objetos obje tos do modelo. Este capítulo capítulo é recomendado recomendado para os leitores envolvidos envolvido s na na concepção de sistemas, com experiência ou não em sistemas não orientados a objetos e que devem passar a "pensar" em objetos. Não é um um capítulo essencial para quem já posssui posss ui os conceitos de objetos bem be m consolidados. Mesmo Mesmo neste caso este leitores le itores podem pode m se servir da técnica dos cartões CRC como um método que permite envolver os clientes e
usuários usuários no levant le vantam ament entoo de requsitos de projeto p rojeto e no processo proc esso de concepção do software.
Capít Capítu ulo 5 - O Modelo de Detalhad De talhadoo de Objetos. Descreve, finalmente, os diagramas do modelo orientado a objetos na notação proposta pela UML: diagrama de classes, estados, seqüência, atividades, colaboração, componentes e distribuição. Cada diagrama é descrito em conjunto com seus elementos componentes e aplicado em diversos divers os exemplos, exemplos, qu q ue permitem ao leitor le itor visualizar vis ualizar as diversas dive rsas alternativas alternativas da sua aplicação aplic ação na modelagem modelagem de sistemas. sistemas. É um capítulo capítulo essencial para a compreensão da notação e dos detalhes construtivos dos diversos diagramas que compõem os modelos orientados a objeto. Capítulo 6 – Estudo de Casos. Aplica os modelos modelos apresent apre sentados ados nos capítulos 3, 4 e 5 em três estudos estudos de caso. Inicialmente Inicialmente o estudo de caso da aplicação aplic ação comercial do capítulo 2 é revisado, revis ado, assim ass im como como o exemplo exemplo do jogo da forca utili utilizado zado no no capítu capí tulo lo 4, e o exemplo exemplo de estoque estoque do capítulo 5. Desenvolvido com um uma visão vi são didática, di dática, ele el e perm per mite ao leitor l eitor compreender a in i ntegração tegração que existe existe entre os modelos e diagramas. diagramas. O leitor l eitor pode, se desejar, dese jar, in i niciar icia r a leitu lei tura ra do livro li vro por este capítu capí tulo lo tendo tendo uma uma abordagem inicial mais prática, para par a dai se aprofu apr ofundar ndar nos nos assun ass untos tos de maior maior interesse interesse nos capítulos anteriores. Um Glossário finaliza o trabalho listan li stando do os principais termos termos utilizados na modelagem orientada a objetos. Como alguns destes termos pode ter um significado diferente fora do contexto da modelagem, o glossário deve ser consultado sempre que surgir dúvida em algum termo durante a leitura do texto. O Apêndice mostra o resultador da tradução dos modelos da UML em códigos Java, transformando os exemplos em aplicações completas. Lá encontram-se os códigos dos programas programas e o endereço do website para executá-los. executá-los. Todos os exemplos exemplos usados ao ao longo do texo estão disponíveis para acesso pela internet . São várias as possibilidades de leitura do texto do livro, e elas estão esquematizadas esquematizadas na figu figura abaixo, partindo do in i nteresse do leitor le itor por uma uma visão vi são teórica, teóri ca, uma visão prática ou por um interesse específico por algum tema:
Figura 2 - Encadeamento Encadeamento possível possíve l para leitura leit ura dos capítulos Pode-se iniciar a leitura pelo Capítulo 2 para os que desejam consolidar os fundam fundament entos os da orientação a objetos. obj etos. No entant entanto, o, se os leitores l eitores já são s ão famili familiares ares a estes conceitos, podem utilizar este capítulo para familiarizarem-se com a nomenclatura util utilizada izada no restant res tantee do texto. texto. Os capítulos 3, 4 e 5 são relativamen rela tivamente te indepe independent ndentes es por se tratarem de 3 modelos modelos que diferem em escala e objetivo. Podem, por isso, iss o, ter uma leitura independente, mas que em conjunto apresentam as possibildades de modelagem que a orientação orientação a objetos obje tos nos nos oferece. A leitura leitura seqüen seqüe ncial destes três capítulos favorece o entendimento da evolução dos modelos que ocorre, naturalmente, durante o desenvolvimento de um sistema de software. Entretando, se o objetivo do leitor é apenas criar uma especificação espec ificação de alto nível do sistem s istemaa pode interromper interromper a sua leitura no capítulo 3. Se além do modelo de especificação deseja um aprofundamento dos conceitos do sistema em um modelo conceitual preliminar, ou se estiver diretament diretamentee envolvido na análise do d o sistem si stema, a, deve continu continuar ar sua leitura pelo pel o capítu capí tulo lo 4. O capítulo capítulo 5 se destin des tinaa aos leitores que desejam compreender compreender os detalhes de um modelo orientado a objetos criado com a notação da UML, provavelmente por estarem envolvidos nas etapas de design des ign e constru construção ção de softwar software. e. Uma Uma altern al ternativa ativa possível poss ível para o leitor le itor que desejar uma uma visão rápida r ápida das técnicas técnicas de modelagem apresen aprese ntadas aqui é ir diretament diretamentee para o capítu capí tulo lo 6 e utili utilizar-se zar-se das referências citadas ci tadas neste neste capítulo para um aprofundamento nos itens de maior interesse nos capítulos anteriores. Se no decorrer decorr er da d a leitu le itura ra houver dúvida sobre algum algum termo termo técnico empregado, empregado, o leitor l eitor pode procurar uma uma explicação no glossár glossário io de termos. termos.
Com esta organização é possível cobrir várias possibilidades de abordagem da orientação a objetos, desde uma abordagem mais formal, até uma abordagem mais prática e informal. informal. Com um grande núm número ero de exemplos, exemplos, procura-se pro cura-se sempre sempre apresent apre sentar ar as aplicações apl icações típicas dos conceitos apresent apre sentados. ados. O leitor le itor deve, ent e ntretan retanto, to, mant manter-se er-se atento à limitação dos exemplos propostos e imaginar como utilizar estes conceitos em seus próprios própri os problem proble mas e aplicações. aplic ações.
1.3.
A importância importância da modelagem
É fácil observar obs ervar que ou outras tras áreas área s do con co nheciment hecimento, o, as ou o utras discipli dis ciplinnas de engenharia, usam extensivamente da modelagem para representar seus projetos. A figura clássica de um engenheiro civil é alguém envolvido com plantas e diagramas, gerenciando uma construção. Uma planta de uma obra civil é uma representação gráfica do produt pro dutoo final, o edifício. edi fício. A plant pl antaa perm per mite que o client cl ientee avalie aval ie o produto e garanta garanta que o resultado final é muito muito próximo próximo do que ele deseja. de seja. A capacidade capacida de de gerenciamento da indústria da construção civil, permite uma razoável precisão na data de entrega entrega das obras graças à padronização de processos pr ocessos de construção construção e a uma uma int i ntensa ensa padronização de componen componentes. tes. Com exceção talvez apenas da alvenaria, uma uma edificação é composta composta de partes pa rtes já construídas construídas e que são integradas integradas para formar formar o produto produto final. final. Estas partes pré-fabricadas pré- fabricadas são s ão os objetos da construção construção civil. civi l. A engenharia mecânica, na indústria automobilística por exemplo, é uma indústria com um alto nível de automação, padronização e especialização. Um carro é fruto de um projeto básico que define os requisitos para os projetos de cada peça. Ele movimenta uma grande mercado para as indústrias de auto-peças que criam, isoladamente, os objetos individuais do carro. A construção do carro é uma montagem, uma integração de objetos. A engenh engenharia aria de software procura pr ocura trazer trazer para pa ra a ciência da comput computação ação estas es tas lições, liç ões, e incentivar a elaboração de um projeto de software, em um modelo orientado a objetos. Visando Visando a padroniz padr onização ação de componen componentes tes de software, o projeto e o processo proce sso de desen dese nvolvim volvi mento ento são desenvolvidos segun segundo a orient or ientação ação de se criar cr iar 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 residência. Um modelo que mostra não só os requisitos do problema mas também como como eles ele s serão se rão aten a tendidos didos pelos elementos elementos da solução. so lução. Um Um modelo que permita permita avaliar aval iar a qualidade da solu sol ução e simular simular o resultado final, de modo modo que projetista, client cl iente, e, construtor tenham todos uma mesma visão do projeto. O processso process so de desenvolviment desenvolvimentoo de softwar softwaree é um processo process o composto composto não apenas de componentes tecnológicos. Uma componente importante, e decisiva para o sucesso de um empreendimento, é a componente social. A componente tecnológica nos projetos de software se encontra, encontra, principalment principalmente, e, nas ativida atividades des de contrução contrução do software software.. A componen componente te social está lig li gada ao relacionam rela cionament entoo entre o usuário usuário e o desenvolvedor, e uma uma parcela pa rcela importan importante te da interação interação do usuário com o software. Pfleeger Pfleeger (1999) afirma afirma que o sucesso do software depende mais até do sucesso das interações sociais do que
da aplicação da tecnologia. Não se deve esquecer que software é desenvolvido por pessoas para p ara ser utili utilizado zado por outras outras pessoas. A interação do software software é uma uma interação interação entre entre pessoas, pes soas, mediada pela tecnologia. tecnologia. A qualidade de um software pode ser avaliada pela satisfação do cliente. O cliente que se serve do software cria, ao estabelecer os requisitos de um software, uma expectativa expectativa que só verá realizada reali zada quando quando o software software estiver concluído. concluído. Ao desenvolvedor cabe captar e atender estas expectativas com as possibilidades de realização. reali zação. Para isso is so client cl ientee deve contar, contar, desde des de o início i nício com um um modelo do software. Este trabalho objetiva auxiliar os desenvolvedores na criação de modelos orientados a objetos dos sistemas de software. A principal proposta é valorizar a atividade de criação do modelo para reduzir a incerteza do software, aproximar a expectativa da realização, facilitar a padronização e a automação dos projetos, incentivar a reutilização dos componentes de software e aumentar a maturidade da engenh eng enharia aria de software nas equipes de projeto.
2. Fundame Fundamen ntos tos da Modelagem Orientada a Objetos Objetos Este capítulo capít ulo descreve os conceitos fundam f undamentais entais da modelagem orient orientada ada a objetos por intermédio de um exemplo de aplicação. O exemplo mostra a herança, o encapsulamento e a troca de mensagens entre os objetos sob um ponto de vista rático. rátic o. Apresenta ainda as característi caracter ísticas cas principais do processo de desenvolvimento de software, os fluxos de trabalho e a importância da modelagem de objetos presentes neste processo.
2.1.
Processo de Desenvolvimento Desenvolvimento de Software
O desenvolvimento de um software depende de muito trabalho disciplinado. Ter uma uma boa idéia para um softwar softwaree só não basta, ela deve vir vi r acom ac ompanh panhada ada da organização organização e da disposiçã di sposiçãoo necessárias necessári as para par a realizar rea lizar o trabalho traba lho de transform transformá-la á-la em um produto. produto. Um sistema sistema de software é resultado da união união da criatividade cr iatividade , da tecnologia tecnologia e do trabalho trabal ho organizado. Um não funciona funciona bem sem os dem d emais ais.. A tecnologia tecnol ogia sozinh s ozinhaa não resolve os problemas, o esforço solitário fica isolado se não for criativo. O que une a tecnologia com a criatividade e direciona o trabalho é uma idéia comum, uma visão, representada em um modelo. Estudando-se as etapas para transformar uma idéia em um produto produto de software, verifica-se verifica- se a importância importância em criar cria r um modelo.
dese nvolvim vimee nto de software soft ware descrevem Os métodos para desenvol des crevem a organização organização necessária para se criar cr iar um software software.. Métodos sugerem sugerem passos a serem ser em seguidos seguidos para p ara cumprir o vazio existente entre a idéia e o produto de software. Este estudo não pretende desenvolver desenvolver um novo método, método, nem nem tão pouco pouco indicar um determinado determinado método método como como sendo o mais adequado. Pretende sim destacar algu a lgum mas propriedades propri edades presentes em todos os métodos, e observar que as técnicas de modelagem estão no centro dos métodos, e dão a sustentação necessária para a edificação do software. Os métodos métodos são organizados organizados em fases, fases, que caracterizam as etapas de evolu evol ução pelas pe las quais o software deve passar. Em cada fase uma série de atividades são realizadas, produzindo produzindo docum documentos, entos, esquemas esquemas e diagramas diagramas que finalizam finalizam no código do programa programa de computador. Sobre cada um destes subprodutos do método de desenvolvimento podem ser realizados testes, para garantir que se está evoluindo na direção prevista, e com a qualidade esperada. Ao avaliar as etapas de um projeto de software, observa-se que elas não são muito diferentes diferentes das etapas de qualquer qualquer outro outro projeto típico típi co de eng engenh enharia aria.. Como Como todo projeto p rojeto de engenh engenharia aria,, o projeto proj eto de software tem como como principal pri ncipal objetivo obje tivo resolver resol ver um problema. A solução do problema irá trazer benefícios para os usuários do produto do projeto, no caso, o softwar software. e. A solução do problema, problema, no no caso da engenh engenharia aria de software, é o próprio sistema de software. Identificar os objetivos e reconhecer os requisitos do problema são as atividades realizadas na fase de análise . Os requisitos variam de caso para caso, e dependem de um bom entendimento da área de conhecimento na qual será desenvolvida o projeto, das condições iniciais e das necessidades dos clientes. Pode-se dizer que a análise serve para se formular formular o problema que que o sistema sistema irá resolve r esolver. r. Conhecidos Conhecidos os requisitos e as necessidades do cliente pode-se elaborar uma estratégia para resolver o problema, ou
fazer, o que se chama aqui, do design da solução. Na fase de design são tomadas tomadas todas as decisões decisõ es que que envolvem envolvem a solução do problem proble ma, e a partir partir dele inicia-se inicia -se a construção dos componentes da solução. Este componentes podem ser novos ou reutili reutilizados zados de outros projetos, proj etos, já testados e aprovados. apr ovados. Com os component componentes es da solução disponíveis realiza-se a integração que coloca todas as partes juntas para se obter o produt p rodutoo final. É interessante notar notar que esta descrição descr ição aplica-se apli ca-se igualm igualment entee à construção construção de umar umar edificação, um projeto de in i nstalação elétrica ou um um projeto mecânico qualquer. Esta coincidência sugere uma grande semelhança na organização das atividades de engenharia seja qual for a disciplina. Um elemento importante e presente em todos os projetos de engenharia são as pr ojeto de eng engenh enharia aria é realizado re alizado sobre s obre uma uma plant pl anta, a, que é plantas de engenharia . Todo projeto uma representação gráfica minuciosa do que se pretende construir. Sobre a planta são avaliadas possíveis alternativas de solução, tomadas as decisões de projeto e a partir dela são obtidas as orientações para a construção do produto. A planta é, essencialmente, um elemento de comunicação entre os participantes do projeto. A planta representa representa o projeto de uma uma forma forma simplificada, é um modelo do sistem si stemaa final. final. Os modelos são contruídos para ajudar a entender um problema e para comunicar este entendimento a outros. A simplicidade, própria dos modelos, permite apenas que ele represente as informações importantes, deixando de lado detalhes que dificultem a compreensão compreensão do problema. Entendido Entendido o problem proble ma, o analista pode utili utilizar zar o modelo para comunicar comunicar ao client cli entee o que enten entendeu deu e como como pretende resolvê-lo. resolvê-l o. O projetista comunica, por um modelo, como deverão ser construídos os componentes e como estes serão integrados na solução. Terminado o projeto, o modelo ainda ajuda a comunicar aos responsáveis r esponsáveis pela pe la operação ope ração e manu manuten tenção ção do sistem s istema, a, os cuidados que devem ser tomados ao se realizar uma modificação ou um reparo no sistema. Como é uma poderosa ferram ferr ament entaa de comun comunicação icação o modelo deve ser representado r epresentado em uma uma linguagem ao mesmo tempo precisa e clara, que comunique sem gerar dúvidas de interpretação. interpretação. Este é talvez o maior desafio des afio da modelagem, modelagem, e a principal razão deste trabalho: como criar um modelo de software claro, clar o, preciso prec iso e ao mesmo esmo tempo tempo sim si mples. Outra propriedade Outra propr iedade important importantee dos modelos é a de poder acompanh acompanhar ar a evolução do projeto. No início, é comum comum os modelos modelos serem s erem apenas linhas linhas gerais e esboços. esboç os. Em alguns casos, nem os limites do problema estão ainda em definidos. Com um entendimento melhor do problema, o modelo passa a agregar mais informação e a se tornar-se uma visão mais completa de onde se pretende chegar. Um simples esboço pode dar lug l ugar ar a um diagrama diagrama mais mais preciso, pr eciso, a partir par tir do qual várias decisões dec isões de d e projeto podem ser tomadas. tomadas. Concluída Concluída a etapa de design desi gn,, o modelo modelo contém todas as inform informações ações necessárias necessár ias para p ara se s e iniciar a construção construção da solução, o modelo modelo está agora
bastante bastante detalhado detalhado e preciso. preci so. Finalment Finalmente, e, com o produto produto construído construído e em operação é importante manter-se o modelo atualizado e vivo, refletindo nele as eventuais alterações feitas no produto quando ele sofre uma manutenção, ou são realizadas expansões. O modelo é uma parte importante do projeto e deve evoluir com ele. Assim é possível possív el resu res umir as qualidades qualida des desejáveis desej áveis de um modelo como sendo sendo a clareza, clar eza, a precisão, preci são, a simplicidade e a facilidade facilidad e de evolução. A figu figura ra mostra mostra um esquema esquema das atividades em um um projeto de desenvolviment desenvolvimentoo de software software qualquer, qualquer, e a corresponden cor respondente te evolução do modelo deste sistema. sistema.
Figura 3 - Esquema de de um projeto de software Com base neste neste esquem es quemaa analisa-se analisa -se a evolução evol ução do modelo modelo no projeto de sistemas, sistemas, as atividades realizadas para obtê-los e os principais personagens envolvidos nestas atividades. Estuda-se, inicialmente, os dois principais fluxos de atividades represent repres entados ados neste esquema: esquema: o ciclo cicl o de desenvolvimento, desenvolvimento, represent repres entado ado pelas pel as atividades do lado do desenvolvedor, e o ciclo de teste do produto, representado pela seta vertical à esquerda, do lado do cliente.
2.1.1.
Cicl Cicloo de teste do software
O ciclo de teste do software é um processo de responsabilidade do cliente, ou do seu represent repres entant ante. e. Visa garantir garantir que as necessidades levantadas para a definição dos problem proble mas estejam sendo sendo atendidas atendidas pelo pe lo produto. No No ciclo de d e teste o cliente cliente verifica se se o produto fornecido fornecido pelo pel o ciclo cicl o de desenvolvim de senvolviment entoo está de acordo com c om os requisitos re quisitos de projeto, e para isso i sso ele realiza reali za testes testes sobre o produt pr oduto. o. Testes que que colocam coloca m o produto produto em situações de uso normal, e procuram detectar falhas e novos requisitos não identificados ainda. Como um sub-produto dos testes surgem correções e novas necessidades, que devem ser incorporadas aos requisitos de uma nova versão deste produto, produto, dando início início a um novo ciclo de desenvolvimento. desenvolvimento. Os cliente s são sã o todos os que contratam contratam o serviço ser viço de desenvolvim des envolviment entoo do software software,, porque estão interessados interessados pelo pel o resultado que que o software irá dar da r ao seu negócio. negócio. Os client clie ntes es podem pod em ser os usuários finais, que irão irã o usar o software software,, podem ser seus se us gerentes gerentes que devem garantir garantir a qualidade qualida de e a funcion funcionalida alidade de do software software ou patrocinadores do softwar softwaree que irão i rão incentivar incentivar o desenvolviment desenvolvimentoo e arcar com seus seus custos
Gerente da aplicação é o responsável r esponsável pela pel a operação oper ação do sistema sistema no ambiente ambiente do usuário. usuário. Du Durant rantee o desenvolviment desenvolvimentoo do projeto o gerente gerente é o lider lide r dos usuários usuários e atua atua como facilitador dos d os relaci re lacionam onament entoo entre eles e a equipe de desenvolvedores. desenvolvedores . Um Uma vez desen dese nvolvido volvid o o sistem s istemaa de software software o gerente gerente da aplicação apli cação passa pas sa a responder por ele int i nternam ernament entee à org or ganização. anização. sistema para par a auxili auxiliá-lo á-lo em suas suas atividades. ativi dades. Usuário final é quem se utilizará do sistema Em problemas complexos os usuários podem variar de departamento, função, hierarquia na organização. organização. Nestes casos é im i mportante portante se s e criar cr iar um comissão comissão de usuários usuários,, representat re presentativa iva da com co mun unidade, idade, para orientar o desenvolviment desenvolvimentoo do sistema. Patrocinadores fazem parte do grupo de clientes que dão apoio financeiro, técnico técnico ou político polí tico ao desenvolvim des envolviment entoo do sistem si stema. a. Este apoio é vital para que os desenvolvedores possam ter acesso às inf i nform ormações ações e possam poss am execut executar, ar, se se necessário, as alterações al terações na organização organização para a implantação implantação do sistem si stema. a.
2.1.2.
Cicl Cicloo de desenvolvi desenvolvimento mento do software
O ciclo de desenvolvimento do sistema é um fluxo de trabalho cíclico que gera novos produtos produtos a partir das in i nformações formações obtidas no levant leva ntam ament entoo de necessidades do problem proble ma. É dades cíclico cícl ico porque o produto produto de saída alimenta alimenta o ciclo seguint seguinte, e, de modo que a cada volta aproxima-se o produto das necessidades levantadas. Espera-se que o ciclo seja convergente, isto é, em um determinado estágio o produto atenderá todos os requisitos e poderá ser considerado terminado. Este ciclo é realizado inteiramen inteiramento to no lado do desenvolvedor, des envolvedor, mas possui int i nterações erações com o lado client clie nte, e, no ciclo de testes do produto. O ciclo de desen dese nvolvim volvi mento ento de um sistema sistema é caracterizado ca racterizado por 4 atividades atividad es principais: principais : análise, design des ign,, construção construção de componen componentes tes e integração. integração. A seguir seguir verificase o papel do modelos nas fases e os papel dos participantes de cada uma delas.
Fase de Análise A análise é a fase de levantamento dos requisitos do problema a ser resolvido. Nela estabelecem-se os lim l imites ites do problema, pr oblema, e identificam identificam-se -se as a s necessidades necessidad es do sistem s istema. a. Deve-se procurar lim l imitar itar a análise exclusivamen exclusivamente te ao problem proble ma em estudo, estudo, evitan evi tando do a influên influência cia de elem el ement entos os que estão es tão fora do escopo do problema. pr oblema. Detalhes Detalhes de implementação que podem ofuscar a definição do problema, falsos requisitos, limitações inexistent inexistentes es devem deve m ser deixadas d eixadas de lado. l ado. Para ajudar o analista analis ta na na busca de uma uma maior clareza cla reza nas definições inciais, inciais , ele deve criar cr iar um modelo do problem probl ema. a. Este modelo deverá ter apenas as inform informações ações relevant relev antes es para p ara o entendim entendiment entoo do problema e deverá receber a aprovação apr ovação por parte do client cl iente, e, garantindo garantindo que o caminh caminhoo está correto cor reto e servindo servi ndo de base para as demais demais fases do projeto. As técnicas aplicáveis à análise são muitas, e dependem, grandemente, da experiência do analista. a nalista. Quant Quantoo mais mais complexo complexo o problema, pr oblema, mais mais difícil é a análise e mais importan importante te o uso de modelos para reduzir reduzir e gerenciar esta es ta complexidade. complexidade. Todas as informações obtidas do cliente devem ser avaliadas e levadas em consideração na análise. Não existe um momento preciso que indica o final da análise, mas o analista pode identificar identificar este e ste mom moment entoo quanto quanto todas todas as facetas do problem proble ma foram exploradas e a visão vi são que o modelo traduz traduz é suficie suficient ntee para par a iniciar inicia r as fases seguint seguintes es do projeto. Mesmo que alguns requisitos foram esquecidos, não é motivo de preocupação, como o processo process o de desenvolvimento desenvolvimento é cíclico sem s empre pre será ser á possível possí vel rever reve r a análise e in i ncluir estes novos requisitos.
A análise é tarefa do analista de sistemas . Em projetos proje tos mais mais simples simples esta atividade pode ser desem de sempenh penhada ada por um desenvolvedor sên sê nior, ou pelo próprio própr io gerente gerente de projeto, se estes possuirem poss uirem um conh conhecimen ecimento to básico de modelagem modelagem de sistemas, sistemas, e a disponibilidade disponibil idade para entrevistar usuários usuários,, levan leva ntar e organizar organizar as inform informações ações disponíveis para o início do projeto. Em projetos mais complexos esta tarefa pode ser dividida entre diversos profissionais como o Analista de Negócios, o Analista de Documentação e o Analista de Banco de Dados.
Analista de Negócios - deve ser s er um especialis especi alista ta na área de conh conhecimen ecimento to a que o sistema sistema se destina, e tem como como objetivo obje tivo identificar identificar as responsabilida re sponsabilidades des que o sistema sistema deve cumprir cumprir para o negócio negócio do cliente. cl iente. O analis analista ta de negócios negócios pode desenvolver uma análise do retorno esperado com o invetimento no sistema, e estudar a viabilidade técnica do sistema, integrando-o ao ambiente computacional existente. Os requisitos de negócio, as regras e os processos de negócios devem ser modelados por este profissional. Analista de Banco de Dados - como uma grande parte dos sistemas de informação são baseados na tecnologia de banco de dados, é importante ter um entendimento preciso preci so das informações informações já j á existentes existentes em bancos de dados, antes antes de iniciar um novo projeto. O analista pode se utili utilizar zar de técnicas próprias própr ias e ferrament ferramentas as de software para criar os esquemas dos bancos de dados existentes e que serão úteis para o novo projeto de sistema. sistema. Analista de Documentação - é o responsável por elaborar a documentação do sistema, os documentos de especificação, manuais e diagramas. Como a fase de análise é uma fase onde a geração de documentos é maior, é importante ter-se um profission profissio nal técnico especializado especial izado encarre encarreggado da produção desta document documentação. ação. Uma prática interessante pode ser a de produzir o manual do usuário do sistema já na fase de análise, e utilizá-lo com parte da especificação técnica de requisitos do sistema. Como parte importante da fase de análise temos um modelo inicial do sistema que fará parte do docum do cument entoo de especificaçã e specificação, o, produto da fase de análise. análise . Porque as correções correç ões nas fases iniciais i niciais de um projeto são sã o sempre mais mais fáceis fácei s de serem s erem feitas, feitas, do que em fases mais avançadas, os documentos e os modelos desta fase devem ser, continu continuam ament ente, e, avaliados aval iados e verificados ver ificados pelos client clie ntes. es.
Fase de Design O design se concentra concentra na solução do problem probl emaa iden ide ntificado na fase fase de análise.
Busca incorporar aos modelos, os elementos que formam um sistema para resolver o problem proble ma de projeto. proje to. Com Comoo quase sempre sempre a seleção sel eção de uma uma estratégia estratégia de solução sol ução traz traz compromissos com outros sistemas, deve-se, nesta fase, avaliar o melhor caminho, testar e escolher es colher a alternativa alternativa de solução sol ução mais mais adequada. O designer designer cont c ontaa com a sua experiência e o apoio de modelos do sistema em projeto para apoiar sua decisão. O design é uma tarefa para engenheiros de software experientes. Em um projeto mais complexo, complexo, diversos divers os aspectos as pectos de um sistema sistema de software software devem ser considerados, considerados , o que exige exige a participação pa rticipação de outros especialis especia listas, tas, como como o Engenh Engenheiro eiro de Redes e o Designer de Interfaces.
Enge Engen nhe iro iro de Software - é o especialista em criar o operar os modelos dos sistemas para levá-los ao código. Deve possuir habilidade de conceber os componentes do sistema e caracterizá-los de modo a que atendam os requisitos do problem proble ma. Pode testar soluções e se utili utilizar zar de padrões de soluções sol uções já consagradas consagradas e aplicá-l apl icá-las as a novos problemas. O engenh engenheiro eiro de software deve garantir garantir também também que as boas práticas p ráticas de eng engenh enharia aria sejam respeitadas no projeto, assegurando assegurando a qualidade do produto. produto. Engenheiro de Redes - é um especialista importante quando o sistema será implementado em um ambiente de processamento distribuído. Neste caso, a comunicação entre os componentes do sistema será feita pela rede de comunicação de dados, dados , que deve ser projetada para p ara dar vazão ao volume volume de com c omuunicação esperado. Existindo uma grande interação entre os componentes da solução pode exigir, em alguns casos, que componentes especiais de comunicação sejam especificados e construídos. Designe Designe r de de Inte Interfaces rfaces - é um especia espe ciali lista sta na na comun comunica icação ção entre os usuári usuários os e o computador. É um profissional muito importante em sistemas com grande interação com os usuários usuários com co mo os sistemas sistemas para par a internet . O aumento do número de usuários nos sistemas de informação tem feito com que este profissional tenha um papel cada ca da vez mais mais im i mportante portante para a aceitação e para par a a usabilidade do sistema. sistema. Ele deve possuir a habilidade de e a criatividade para criar metáforas para a operação do sistema. Ao final final da fase de design desi gn todas as definições do projeto devem deve m estar registradas no document documentoo de especificação. especi ficação. Modelos, listas lis tas e esquem es quemas as servem s ervem como como referências para os construtores dos componentes e para a integração do sistema. O modelo produzido pelo desig desi gn pode variar muit muitoo no no nível dos seus detalhes. detalhes. No início do projeto proje to apresenta poucos detalhes mostrando conceitualmente a solução, para uma avaliação inicial, ou para a validação de um cliente. Nos ciclos mais avançados do projeto, o modelo deve estar muito bem detalhado para determinar aos programadores todos os
pormenores pormenores do softwar software. e.
Fase de Construção doms Componentes Na fase fase de construção de componentes inicia inicia-se -se as ativida atividades des de programação programação na na construção construção do software. A boa prática pr ática de construção construção recomenda recomenda a adoção do conceito de component componentes es de software software reutili reutilizáveis záveis para par a reduz re duzir ir prazos e custos custos no desenvolvimento, mantendo a qualidadade do produto. É cada vez mais comum se dispor de component componentes es pré-fabricados pré-fabri cados prontos para serem utilizados utilizados em diversos divers os projetos, organizados organizados em um framework . Nestes casos a construção de componentes se limitará a criar os componentes que são específicos para o novo projeto. A construção construção civil é um exemplo exemplo típico típic o de padroniz pa dronização ação de peças pré-fabricada pr é-fabricadas. s. Poucas são as a s partes par tes criadas cri adas específicam especí ficament entee para par a uma uma construção. construção. Na área á rea mecânica mecânica o exemplo mais interessante de criação de componentes encontra-se na indústria automobilística, onde um carro é efetivamente a montagem de peças e partes completas feitas por outras empresas,. Muitas vezes a mesma peça é utilizada em diferentes carros. carros . Esta abordagem a bordagem ainda é nova na engenh engenharia aria de soft s oftware ware,, mas mas está, aos poucos, revolucionando revolucionando o desenvolvim des envolviment entoo de software. A construção dos componentes é um trabalho para o programador de computadores , que é o especialista nas linguagens de programação. Um mesmo sistema pode possuir componten compontentes tes escritos em diferentes diferentes linguag linguagens, ens, no no entant entanto, o, para facilitar facili tar a manut manutenção enção e simplificar simplifi car o sistema s istema quanto quanto menor menor o número número de ling li nguag uagens ens mais facilment facilmentee o sistema sistema será se rá mantido. mantido. O programador programador segu s eguee princípios pri ncípios e práticas próprias, própri as, que não farão parte deste trabalho. Como uma grande parte dos sistema atuais se utiliza de um banco de dados para armazenar as informações e possui uma grande dose de interação com os usuários, é importante também envolver na fase da construção outros especialis especi alistas: tas: o program pr ogramador ador de banco de dados, o programador programador de componen componentes tes e o programador programador de interfaces.
Programador de interfaces é o profissional responsável por desenvolver os componentes de interação entre o sistema e os seus usuários. Os componentes de interface devem se caracterizar pela facilidade de uso e pela precisão na comu comunicação. O uso de uma uma int i nterface erface gráfica e regras próprias próp rias para criar cria r estes es tes componentes, componentes, proje pr ojetador tador por um design desi gner, er, exigem que um programador especializado nesta tarefa seja convocado para realizá-la. esc reve os com c omponen ponentes tes de neg negócio ócio obedecendo Programador Programador de Compon Componee ntes nte s escreve as regras de negócio definidas pelo Analista de Negócios e projetadas pelo
Engen Engenheiro heiro de Softwar Software. e. Sua principal tarefa é garantir garantir a qualidade do componente, componente, sua eficáfica efic áfica e robustez. r obustez. Utili Utiliza, za, em gera geral,l, uma uma ling l inguag uagem em robusta em um ambiente de desenvolvimento próprio. Programador de Banco de Dados é um profissional importante na fase de construção construção se houver houver necessidade necessi dade de criar cria r component componentes es específicos espe cíficos para p ara o armazenamento e recuperação de informação. Em sistema orientados a objeto o uso do banco de dados é lim li mitado e organ or ganizado izado pelos objetos, sendo que este profission profissio nal deve ser s er responsável resp onsável por integrar integrar os sistem s istemas as orient orie ntados ados a objeto obj eto com os sistema legados em bancos bancos de dados. Como o produt pr odutoo final da fase de const c onstrução rução são os próprios própri os Anali Analista sta de Teste Tes te . Como componen componentes. tes. Cada component componentee próprio pr óprio ou adquiri adquirido do de ter terceiros terceir os deve de ve ser testado individualment individualmente, e, para garantir que ele esteja de acordo com a especificação do projeto. Este teste faz parte do processo de criação de componen componentes tes mas mas não deve ser desprezado. despr ezado. Pode-se criar, criar , em projetos maiores maiores,, uma função específica com esta responsabilidade, garantindo a sua qualidade e funcionalidade. O analista de testes não pode ter uma função acumulada com a função de programador, para evitar um conflito de interesses.
Fase de Integração Integração A fase de integração encerra o processo process o de desenvolvimento desenvolvimento gerando, gerando, como produto produto final, final, uma uma nova versão do software. Nesta fase, fase, a atividade ativida de mais mais importante importante é a de configuração da versão do software, compilando e instalando os componentes necessários nos equipamentos servidores. É uma fase de trabalho minucioso e organizado, organizado, onde se deve assegurar assegurar que todos os componen componentes tes necessários necessári os foram integrados. Após este integração é importante realizar uma fase de teste. É comum nesta fase se criar cria r roteiros r oteiros aut a utom omatizados atizados de teste, assim assi m como como pode ser necessária algum alguma atividade de program pr ogramação ação para integração integração final dos componen componentes. tes. As atividades de integração integração podem, podem, em sistemas sistemas mais simples, ser realizadas reali zadas pelo sis temas as mais Enge Engen nhe iro iro de Software ou pelo próprio Gerente de Projetos Projetos . Em sistem complexos é comum encontrarmos o Gerente de integração ou Gerente de c oordenar uma uma equipe de profissionais, p rofissionais, os Integradores que Configuração que irá coordenar responderão pela un união ião correta dos componen componentes. tes. Os modelos, na fase de integração, servem de mapa para a configuração do sistema, e união dos componentes. Em muitos casos, não se está interessado em criar um sistema totalmente novo, mas sim em adaptar um sistema existente para as necessidades
específicas especí ficas de um client clie nte. e. Chama-se Chama-se ao processo pr ocesso de adaptar ada ptar um software software especialm especi alment entee [1] para as necessidades necessi dades de um cliente de customização . O processo de customização passa por todas as fases do processo process o de desenvolvimento, desenvolvimento, mas mas tem uma uma ênfase ênfase maior maior na fase de integração, integração, onde são realizadas real izadas a maior parte das atividades de configu configuração do software.
2.2.
Modelos de um Software
O processo process o de desenvolviment desenvolvimentoo de um software software apresentado é baseado bas eado na evolução evol ução de uma visão que os desenvolvedores controem, em conjunto com os clientes, sobre o problem proble ma a ser resolvi r esolvido. do. Esta visão é concretizada em modelos, que devem representar esta visão e evoluir com ela. No início, a visão é incompleta e pode possuir ambiqüid ambiqüidades ades e distorções, que ao longo longo do processo pr ocesso de desenvolvim dese nvolviment ento, o, com o entendimento do problema, são eliminadas. No final, o modelo resultante é equivalente em signif significado icado ao código códi go gerado gerado para implemen implementar tar a solução s olução do problema, pr oblema, eles devem ter igual riqueza de detalhes e precisão. Em um problema complexo, dificilmente uma visão única, completa e bem definida será obtida logo no início do processo. pr ocesso. É importan importante te que que os comprom compromissos issos do software representados no modelo sejam assumidos aos poucos, acompanhando o entendimento que se tem do problema. As técnicas de modelagem, que serão exploradas em detalhes nos próximos capítulos, ajudam os analistas e designers a documentar e comunicar o entendimento que adquirem do problema em diagramas de forma precisa, evitando a construção de sistemas de software inconsistentes. Um único modelo apenas é insuficiente para representar todos os fenômenos existentes em um sistema complexo, são necessários um conjunto coerente de modelos com diferentes escalas, criados a partir de diferentes pontos de vista. Jacobson (1992) propõe que a complexidade complexidade seja sej a introduz introduzida ida gradualment gradualmentee no modelo modelo do sistem si stema, a, com a ajuda de uma uma série sér ie de sucessivos modelos que aos poucos são capazes ca pazes de gerenciar essa complexidade. Ele propõe 5 tipos diferentes de modelos: modelo de requisitos, r equisitos, que captura requisitos funcion funcionais ais do sistem si stema, a, modelo de análise, que dá ao sistema uma estrutura de objetos, modelo de design, que refina esta estrutura para a implementação, modelo odel o de implementação, implementação, que q ue efetivamente efetivamente implementa implementa o sistem sis tema, a, modelo de teste que verifica o sistem si stema. a. Este estudo estudo utili utiliza za apenas apenas três modelos para representar r epresentar os sistem si stemaa de soft s oftwar ware: e: modelo de contexto, modelo conceitual e modelo detalhado. A idéia central aqui também é introduzir a complexidade aos poucos. O modelo de contexto equivale ao modelo de requisitos de Jacobson, enquanto o modelo
conceitual conceitual se s e equivale ao a o modelo modelo de análise de Jacobson. O modelo modelo detalhado pode ser aplicado ao design, à implementação ou ao teste do sistema, dependendo do nível de detalhes e da finalida finalidade de a que ele se s e destin des tina; a; assim assi m, substitui substitui os 3 outros outros modelos propostos por Jacobson. Ja cobson. O modelo de contexto inicia a definição do problema. É construído em uma escala escal a grande, onde onde grande parte dos detalhes do problem probl emaa estão es tão encobertos. Representa os aspectos funcionais de alto nível do sistema, analogamente ao modelo de requisitos de Jacobson (1992). Serve para pa ra representar r epresentar o sistem si stemaa proposto propos to no no context contextoo do negócio do cliente. Deve possuir uma representação simples, sem uma formalidade excessiva, para poder ser entendido e validado pelo cliente, que normalmente é leigo em assuntos de software. No modelo de contexto define-se a fronteira do problema e os principais objetivos que o sistema deve cumprir para os seus usuários. Este modelo é, essencialmente, desenvolvido durante a fase de análise pois refere-se, principalmente, à uma visão do problema a ser resolvido. Deve ser possível ao modelo de contexto situar o sistema no contexto do cliente, identificando pontos de integração com outros sistemas já existentes e caracterizar a contribuição do novo sistema. O modelo conceitual é um modelo que reúne todos os conceitos presentes no problem proble ma em estudo. estudo. Constru Construído ído com um uma escala escal a menor menor do que que o modelo modelo de contexto, contexto, cria a estrutura estrutura do sistem sis tema, a, usando usando para isso um modelo sim s implificado plificado de classes. cl asses. Nele devem estar estar representadas r epresentadas os principais pr incipais componen componentes tes do sistem si stemaa e su s uas relações r elações.. No modelo conceitual conceitual está es tá caracterizada as proposta de solução do problema, pr oblema, mas mas sem se m o detalhe necessár necessário io para par a a sua s ua implemen implementação. tação. A idéia central central é represent repr esentar, ar, simplificadamente, em poucos diagramas, o sistema como um todo e as partes principais que o constitu constituem em.. Como Como o modelo modelo final do sistema sistema pode ser muito muito complexo, complexo, o modelo conceitual serve de índice, de orientação, para que dele sejam detalhados os modelos de implementação. É um modelo desenvolvido nas fases de análise e design porque recebe não só os detalhes do problema problema a ser resolvi re solvido, do, como como também também os elementos elementos incorporados ao modelo durante durante o design da solu sol ução. A quantidade quantidade de detalhes do modelo modelo conceitual conceitual deve de ve estar es tar entre entre a abstração do modelo de contexto e a grande quantidade de detalhes do modelo detalhado. Como o modelo conceitual possui um nível maior de detalhamento que o modelo de contexto, é possível, possív el, a partir dele de le estabelecer estabele cer um planejament planejamentoo do desenvolvimento desenvolvimento e um um dimension dimensionam ament entoo mais mais preciso preci so dos recursos necessários necessár ios para a construção construção do sistema. sistema. Estas definições são impossív impossíveis eis de serem s erem feitas feitas apenas com o modelo modelo context contextual, ual, assim ass im o modelo conceitual assum ass umee também um importante importante papel p apel no gerenciamento gerenciamento do processo process o de desenvolvimento desenvolvimento de software. software.
O modelo detalhado, por sua vez, incorpora incorpora todos os detalhes de uma uma versão vers ão projetada do software. O modelo modelo detalhado pode possuir um nível de detalhe equivalente equivalente ao código c ódigo do software, podendo-se até a té criar uma uma correspondên corr espondência cia biunívoca biunívoca com ele. Para cada versão ver são de um software software o modelo detalhado pode mudar, mudar, incorporando as novidades desta versão. versão . Podem ser gerados quandos quandos modelos detalhados quantas quantas versões versõe s do produto produto existirem. existirem. O objetivo obje tivo principal pri ncipal do modelo detalhado é a construção construção do sistem si stema, a, assim ass im nele nele devem estar represent repres entados ados todos os detalhes construt construtivos ivos e as definições definições de projeto. pr ojeto. É um modelo que se in i nicia na fase fase de de design, com os detalhes com componentes a serem construídos e é detalhado na fase de construção. Como o modelo detalhado possui uma escala ainda menor que o modelo conceitual, conceitual, os detalhes do sistem sis temas as são revelados revel ados com precisão, precisão , na medida medida da necessidade do d o desenvolvimento, desenvolvimento, seja para pa ra uma uma maior maior definição definição precisa preci sa do design d esign,, seja sej a para implement implementação ação ou seja para testes. A figura figura abaixo mostra, mostra, de forma forma esqu esq uemática, emática, as relações rela ções ent e ntre re a escala escal a proposta propo sta de modelos e os produtos de software em suas diversas versões.
Figura 4 - Seqüência de Modelos em um Projeto de Software Típico
2.3.
Documento Documento de Especificação de Projeto
O principal documento do desenvolvimento do software é o Documento de Especificação de Projeto. Como seu próprio nome diz, ele deve descreve, detalhadamente, o projeto de um software. Normalmente, a especificação é tomada como um documento feito para orientar a construção do software, mas neste estudo a especificação especi ficação é tomada tomada como um um espelho do projeto do sistema, sistema, e assim deve ser se r mantida atualizada durante toda a evolução do sistema, inclusive após a sua construção. Na fase fase de análise a especificação especificaç ão deve considerar os objetivos do problema, pr oblema, apresen aprese ntando tando os modelos de contexto contexto e conceitual. conceitual. Na fase de design de sign a especificação especificaçã o recebe os detalhes das soluções escolhidas, para que na construção todas as alterações no sistema sistema possam poss am ser represent repr esentadas adas em modelos detalhados na especificação. especificaçã o. Mantém-se assim o documento vivo, acompanhando todo o projeto do sistema. Como este trabalho não se propõe a apresentar um método para desenvolvimento de um software, o documento de especificação não será detalhado. Entretanto, é de esperar, encontrar muitos diagramas e modelos em um documento de especificação de software.
2.4.
A Modelagem Orientada a Objetos
Para criar um modelo é preciso escolher o que é considerado importante, e por isso será represent repres entado ado no modelo, modelo, do que pode ser omitido. omitido. A seleção sel eção do que é, e do que não é, importante importante segu s eguee um paradigm paradi gma, a, um ponto ponto de vista, vis ta, uma uma forma de olhar a realidade que se vai modelar. Descreve-se aqui algumas características dos diferentes paradigm paradi gmas as usados para modelar modelar sistemas sistemas de software. Para desenvolver de senvolver um sistema sistema de soft s oftware ware é necessário necessári o criar cri ar uma uma visão vis ão do problema, pr oblema, representada em um modelo que orienta o processo de desenvolvimento. Para se estabelecer esta visão deve-se definir um ponto de vista, isto é, deve-se a olhar o software segundo um paradigma. O paradigma define uma unidade de decomposição do sistema, sistema, destacan des tacando do algu al guns ns aspectos em e m prejuízo prejuízo de outros. outros. Algum Algumas possívei p ossíveiss visões vi sões e as unidades de decomposição associadas são: A Visão Funcio Funcional nal decompõe de compõe um sistema sistema em funções; funções; A Visão dos Dados decompõe um sistema em estruturas de dados; e A Visão de Objetos decompõe um sistema em classes de objetos. A visão funcional valoriza o fluxo de informação do sistema, buscando responder o que o sistema deve fazer. A idéia, que se traduz em uma análise funcional, é a de definir o sistema como uma grande função, que pode ser quebrada em funções menores, em uma técnica de análise chamada de análise top-down (de cima para baixo). Este procedim procedi mento ento parte do princípio que um um sistema sistema de software deve fazer algo para o seu usuário. Uma função complexa pode ser decomposta em funções mais simples, continuamente, até que a quebra funcional leva a funções tão simples a ponto de poderem ser implem implement entadas adas e testadas. Testadas isoladam isol adament ente, e, as funções funções element elementares ares são agrupadas e integradas em uma estratégia de integração botton-up (de baixo para cima). Integrando Integrando todas as funcionali funcionalidade dadess tem-se tem-se,, ao final, final, o sistem sis temaa comple completo to com toda a funcion funcionalida alidade de preten p retendida. dida. O termo “função” é quem orienta todo o processo de desenvolvimento. O que o sistema sistema deve fazer fazer conduz conduz o processo de análise e construção. construção. Por isso, se for necessário introduz introduzir ir alterações, alterações , modificações modificações e novas funcion funcionali alidades dades nos soft s oftware waress desenvolvidos sobre s obre este paradigm par adigmaa a tarefa mais mais difícil. di fícil. Ao se int i ntroduz roduzir ir uma uma alterção, uma uma série sé rie de outras funcion funcionalida alidades des que decorreram decor reram desta podem ser afetada. A quantidade de código envolvido pode ser muito grande, inviabilizando grandes mudanças em sistemas desenvolvidos sob uma visão exclusivamente funcional.
Figura 5 - Esquema da da Modelagem Funcional Na modelagem de dados, outro paradigma possível no desenvolvimento de softwar software, e, o destaque destaque se volta para par a a estrutura estrutura da in i nformação formação que é tratada pelo sistema, sistema, ao contrário das operações operaçõe s ou funções funções às quais estas es tas inform informações ações estarão sujeitas. A estrutura da informação de um sistema corresponde ao conjunto organizado de entidades que guardam alguma informação para o software e como elas se relacionam. O princípio por trás da modelagem de dados é que um sistema de informação processa informação informação.. Dá-se uma uma maior aio r em qual informaçã informaçãoo é processa proce ssada da e não em como se dá este processamento. Na modelagem modelagem de dados não há há lugar lugar para represent repres entar ar as características car acterísticas dinâm di nâmicas icas do problema, suas funções, operações ou algorítmos. Ainda que algumas regras de negócio reflitam apenas em elementos estáticos ou limites destes elementos, a maioria das regras de negócio exige a criação de algorítmos mais complexos que não encontram abrigo no modelo de dados. Existe, entretanto, na modelagem de dados uma grande reutilização das informações armazenadas e da sua estrutura. A capacidade em se adaptar uma mesma estrutura de dados em problemas semelhantes é muito grande, dando amplas amplas possibili possib ilidades dades de uma uma grande reutili reutilização zação deste tipo de modelo. Problemas semelhantes usam estruturas de informação semelhantes. É importante se observar que nem sempre a estrutura da informação reflete a estrutura do problema. Algumas vezes redundâncias e hierarquias presentes no problem proble ma são elim eli minadas ao se analisar apenas a penas a inform informação ação armazenada. armazenada. O processo process o de normalização de tabelas de um banco de dados é um exemplo desta simplificação. Outra observação importante é que um sistema exige dados e funções, e que nem sempre uma abordagem permite uma visão 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 modificação necessária, seja em dados, seja em funções pode resultar em um trabalho complexo demais. A figura mostra que um dado pode ser necessário para mais de uma função e que que modificar um dado requer modificar muitas funções.
Figura 6 - Um programa combina combina dados e funções A orientação a objetos enfoca a busca da estrutura do problema, e não apenas da informação. Identifica em objetos, os elementos importantes do domínio do problema, que guardam dados e possuem funções que podem operar seus dados. Não são apenas as funções que o sistema deve desempenhar, como na modelagem funcional, nem somente os dados que serão armazendados, como na modelagem de dados; a importância maior é encontrar os elementos do problema que possuem todas estas propriedades. propri edades. Sebesta (1996) (199 6) estu es tuda da a evolução das linguag linguagens ens de programação programação e verifica que enquant enqu antoo a program pr ogramação ação procedural pr ocedural foi desenvolvida dese nvolvida na década de 70, na década de 80 começou-se a combinação combinação de algoritm al goritmos os e estruturas estruturas de dados da dos em objetos obj etos com a linguagem Smalltalk. As idéias da programação orientada a objetos foram incorporadas à linguagem C gerando C++ que ajudou a popularizar as linguagens orientadas a objeto. Apesar de ser possível haver programação orientada a objetos desde 1980, os conceitos que envolvem envolvem o projeto proje to de sistem si stemaa com esta filosofia não são simples, e por isso demoraram demoraram a ser utili utilizados zados pela comun comunidade idade de desenvolvedores. des envolvedores. Os programas programas continu continuavam avam,, até meados da década déc ada de 90, a serem projetados com c om um uma separação sepa ração clara entre a análise funcional e a análise de dados. Num sistema onde qualquer função pudesse se utili utilizar zar de qualquer qualquer dado armazenado, armazenado, seria impossível saber sa ber quais dados são necessários para cada função, função, sem anali analisar sar cada uma uma das funções funções separadam separ adament ente. e. Esta grande dependência entre os dados e as funções dificulta uma alteração nos dados
ou nas funções, funções, porque as conseqüências conseqüências são imprevis imprevisívei íveis. s. importan importante te criar um critério critéri o para par a se unir dados e funções funções em conjun conjuntos tos organizados organizados e coerentes. Desta idéia surge a modelagem orientada a objetos. Um objeto, segundo Jacobson et al (1992), é caracterizado por um conjunto de operações operaçõe s e um estado que armazen armazenaa os efeitos e feitos das operações oper ações que o objeto obj eto é capaz de realizar. reali zar. Assim os dados arm a rmazen azenados ados no estado objeto servem ser vem para armazenar armazenar o efeito das funções, criando-se o vínculo desejado entre as operações e os dados. Os objetos tem uma dimensão maior do que apenas os dados e as funções isoladamente, como exemplifica a figura.
Figura 7 - Objetos reúnem dados e funções A orientação a objetos parte da constatação que o mundo é formado por elementos autônomos e relativamente independentes, e que criar um modelo de um sistema de softwar softwaree é ident i dentificar ificar qu q uais destes elem ele mentos entos são relevant releva ntes es para par a o software. Os objetos que devem ser incluídos no modelo modelo são os que realizam algo de destaque para o problem proble ma em questão. questão. Esta abordagem reduz a distância entre entre o modelo modelo e o mundo mundo real, porque utiliza utiliza element elementos os da realidade real idade para par a criar cria r o modelo, modelo, facilitan facili tanto to o enten entendim diment entoo do problema pelo analista e pelo cliente. Selecionar Seleci onar a orient orie ntação ação a objetos para par a analisar um problema, inclui inclui uma uma série sér ie de características caracterí sticas in i ntrínsicas à tecnologia tecnologia de objetos ob jetos que devem ser bem entendidas entendidas para que o analista possa poss a fazer um uso correto deste des te paradigm paradi gma. a. Dentre Dentre estas e stas características cara cterísticas destacam-se o conceito de encapsulamento das classes, a herança, a troca de mensagens e o polim pol imorfism orfismo. o. Estas características cara cterísticas serão apresen aprese ntadas a segu se guir, ir, acom ac ompanh panhadas adas de exemplos práticos que visam a facilitar o entendimento.
2.4.1.
Encapsulamento
Todos os dados e operações necessárias para um objeto existir, e realizar suas responsabilidades responsabil idades para o sistema, sistema, devem estar armazen armazenadas adas no próprio própri o objeto. Diz-se que o comportamento e os dados estão encapsulados no objeto. Envoltos em uma cápsula os dados d ados dos objetos não estão mais mais isolados isol ados das funções, funções, eles cam c aminh inham am untos.
Figura 8 - Esquema do do encapsulamento O encapsulam encapsulament entoo é a principal pr incipal caracterís c aracterística tica para par a se identificar identificar um objeto. O princípio por trás desta idéia é qu q ue o objeto possua todos os dados e as funções funções necessárias para sua existência. Selecionar um objeto da realidade para o modelo indica que ele represent repres entaa algo al go que que existe de fato fato no domínio domínio do problem pr oblema, a, e que será transportado para o domínio do modelo do software, com toda a sua autonomia.
Figura 9 - Um objeto deve representar re presentar algo al go que existe de verdade ve rdade Um lâmpada, como a da figura, é um objeto importante, por exemplo, para um sistema sistema de cont c ontrole role doméstico. doméstico. As proprieda pr opriedades des que a lâm lâ mpada possui, poss ui, para este sistema sistema são sã o uma uma tensão elétrica e um preço. A lâmpada lâmpada oferece para este sistem si stemaa as funcion funcionalida alidades des de acender ac ender a um determinado determinado preço pelo qual foi comprada.
O encapsulament encapsulamentoo proteg pr otegee os dados de um objeto do acesso aces so descont d escontrolado rolado por outros outros objetos. O acesso ace sso é realizado real izado por interm intermédio édio de mensagen mensagenss trocadas entre entre objetos, que nada mais são do que chamadas das funções do objeto. Apenas a interface do objeto, obj eto, formada formada pelo conjun conjunto de funções, funções, é exposta, oferecendo serviços ser viços deste objeto ao mundo exterior. Como as mensagens passam por uma função do objeto antes de acessar os dados, esse acesso é controlado e o dado protegido. As informações do objeto e como ele implementa estes serviços são mantidos ocultos. A este conceito chamamos de ocultamento de informações, e é outra decorrência importante do encapsulamento de objetos. O encapsulament encapsulamentoo dos objetos encon e ncontra tra analogia em diversas situações da vida diária. Um exemplo de sucesso de encapsulamento presente em nossas casas é o caso do aparelho apar elho de TV e do aparelho apa relho de reprodução de DV DVD. D. Vam Vamos os observar obs ervar que as funções da TV e da unidade de DVD são muito bem definidas: o aparelho de TV possui como função função apres ap resentar entar imagens, imagens, enqu e nquanto anto o a un unida idade de de d e DVD reproduz repro duz imagens imagens armazenadas no formato padrão do DVD. Eles se complementam para servir o seu usuário, e ao mesmo tempo se mantêm independentes.
Figura 10 - Exemplos reais de encapsulamento Além das funções específicas, os aparelhos possuem uma interface bem definida e padronizada que que permite permite que sejam operados sem s em a necessidade de se conh conhecer ecer o funcionamento interno dos aparelhos. Assim como nos objetos, estes aparelhos protegem protegem os componen componentes tes e suas inform informações ações de um uso indevido, indevido, expondo expondo apenas um uma interface externa. O encapsulam encapsulament entoo implica em e m outra outra caracterís ca racterística tica própia própi a da orientação a objetos, ob jetos, que é a colaboração entre os objetos pela troca de mensagen mensagens. s. A integ integração ração dos componentes ocorre interligando a saída de um objeto com a entrada do outro, de modo que um objeto possa acionar uma função do outro objeto. De modo análogo, o DVD se comunica com a TV para utilizar a função de exibição de imagens. O aparelho de DVD
pede à TV que apresente apresente as imagens, imagens, e para isso ele el e envia pela interface interface externa externa de comunicação , a mensagem com a imagem a ser apresentada. A operação em separado dos aparelhos apar elhos é confiável e segu s egura, ra, o que leva lev a a uma uma confiabil confiabilidade idade e segurança segurança da operação em conjunto. O encapsulamento leva à reutilização, outro grande benefício da orientação a objetos. Com ela é possível separar a criação de objetos, da integração destes objetos em sistemas. sistemas. A reutili reutilização zação é uma uma das conseqüências conseqüências mais procuradas no projeto orientado a objeto, obj eto, pois dela decorre decorr e uma uma redução re dução no no custo do desen dese nvolvimento volvimento de novos sistemas e uma maior facilidade de manutenção e expansão. Um objeto bem projetado, testado e confiável confiável pode ser utilizado em diversas divers as situações, diluindo o seu custo custo entre várias vária s aplicaçõe apl icações. s. A manu manuten tenção ção é simplificada simplificada e a expansão expansão pode po de 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 um objeto para par a apresent apr esentação ação de imagen imagenss em diversos sistemas de multimídia, assim como quando um aparelho de vídeo cassete pode ser subst s ubstitu ituido, ido, quase sempre, sempre, por um aparelho aparel ho de DVD, DVD, mais mais moderno, moderno, sem necessariamente necessariamente alterar o aparelho apar elho de TV.
Figura 11 - Exemplo de interface padronizada A figura figura mostra mostra uma uma int i nterface erface padroniz pad ronizada ada para pa ra a operação ope ração da maioria dos aparelhos aparel hos eletrônicos de reprodução de som e imagem imagem.. O uso repetido permite permite que seja qualquer qualquer for a implement implementação ação interna, interna, o usuário usuário saberá o que irá ir á acontecer se escolher a seta (reproduz (r eproduzir) ir) ou o quadrado quadrado (int ( interromper). erromper). O que caracteriza um encapsulamento eficiente é a definição precisa da interface. A interface é a a lista dos serviços que o objeto oferece, ela esconde como o objeto as implementa. Muitas interfaces já estão padronziadas e há um grande esforço geral de padronização para tornar tornar o acesso acess o aos serviços servi ços de objetos mais fácil e simplificado. Existem Existem boas perspectivas per spectivas para p ara a modelagem orientada a objetos nos serviços ser viços de objetos distribuidos. di stribuidos. Diversos Divers os serviços se rviços comu comuns a mu muitos sistem si stemas as podem pode m ser oferecidos aos objetos ob jetos desde desd e eles el es atendam a uma uma interface padronizada, como como o padrão CORBA CORBA ou o padrão EJB. (Orfali, 1998). 1998) .
2.4.2.
Mensagens
A comu comunicação entre os objetos obj etos se dá por meio de mensagens. Um objeto obj eto que que desejar deseja r uma uma inf i nform ormação ação de d e outros objetos deve de ve solicitar sol icitar às funções funções destes objetos, obj etos, 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 função de um objeto, é o acionamento de uma operação encapsulada encapsulada no objeto de destino, feita feita a partir pa rtir do objeto de origem or igem.. A inform informação ação transmitida transmitida é passada ao objetos obj etos de destino d estino pelos parâm p arâmetros etros da função, função, enquanto a resposta da mensagem é obtida pelo parâmetro de retorno da função. Assim, por definição, toda mensag mensagem em tem uma resposta de retorno e pode transm transmitir itir uma uma informação na chamada e no retorno. Para que os objetos se comuniquem é necessário que haja algum tipo de vínculo integrando estes objetos. Estes vínculos, que podem ser relacionamentos existentes entre os o s obje o bjetos, tos, asse a ssegu guram ram um conhecimento conhecimento que um objeto obje to tem da existência do outro.
Figura 12 - Troca de mensagens entre objetos Retomando o exemplo o DVD, nota-se que ele se comunica com a TV por intermédio da função de exibir imagens que a TV possui. Esta função está disponível na
interface da TV, o que permite que outros aparelhos possam servir a TV com imagens. Outra forma interessante de comunicação existente entre estes objetos é a comunicação existente entre os equipamentos eletrônicos e o controle remoto. O controle remoto recebe os comando do usuário e os transmite para a TV como mensagens. Esta comunicação é facilitada porque as interfaces entre o controle e a TV, e entre a TV e o DVD são padronizadas. O que permite esta forma de comunicação entre os objetos é a definição 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 comunicação entre os objetos é bastante restrita, as mensagens ensagens recebidas recebi das por um objeto se limitam limitam às operações expostas expostas na interface. Caso o sistema exija que uma nova mensagem seja enviada, é necessário criar uma função específica para receber esta mensagem no objeto de destino. A definição 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 comunicação comunicação entre objetos objet os
2.4.3.
Tipos, Tipos, Classes 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 serviços para o sistema. Estes objetos seguem a mesma estrutura e definem o que chama-se de um tipo abstrato de dados. Um tipo é uma estrutura de dados com um conjunto de definições de operações que afetam esta estrutura. No tipo não existe a preocupação de implemen implementar tar estas operações, ele serve se rve apenas para se definir um padrão no modelo, reduzindo a complexidade da modelagem. A implementação de um tipo é uma classe . A classe possui, além das definições, a implementação das operações, para criar um componente autônomo para o sistema. A classe class e é um molde para a criação cr iação de objetos, obj etos, porque permite permite descrever des crever um conjunt conjuntoo de objetos qu q ue com co mpartilha a mesma esma estru es trutu tura ra de dados dad os e as mesmas esmas defin de finições ições operações. operações . Todos os objetos de uma classe possuem as mesmas definições mas podem possuir valores valore s diferen di ferentes tes nos dados, respondendo de modo diferente diferente às mensagens ensagens enviadas à ele.
Figura 14 - Exemplos de Classes e Objetos Um objeto é uma uma instância instância de uma uma classe, cl asse, ele e le reali r ealiza za a classe class e para o sistem sis tema. a. A estrutura do objetos é definida pela classe, mas as operações e estados são definidos na instância (Jacobson, 1992). No mundo real os objetos existem e trocam mensagens. É a partir destes objetos obj etos que que se abstrai as classes class es para o modelo, porque no no modelo modelo se está e stá interessado nas estruturas dos objetos. O processo de classificação dos objetos, isto é, determinar determinar a classe cl asse a que o objeto deva perten pe rtencer, cer, é a essência ess ência da modelagem modelagem orientada a objetos. Em um exemplo típico de uma instalação de engenharia é possível classificar os equipamentos como equipamentos elétricos e equipamentos hidráulicos. A figura abaixo mostra mostra esta classificaç cl assificação ão na forma forma de conju c onjunt ntos os . As classe c lassess estão associada as sociadass aos conjuntos,e os objetos aos seus elementoss destes conjuntos, que compartilham as mesmas propriedades. Pertencer ao conjunto equivale dizer que o elemento compartilha
algum algumas características. caracterí sticas. Podem existir existir equipament equipamentos os que possuem características de mais de um conjunto.
Figura 15 - Subclasses da classe class e Reprodutor de Imagens O exemplo exemplo pode mostrar a classificação class ificação não é ún ú nica e pode estar e star sujeita a múltiplas interpretações, dependendo do enfoque que se queira dar ao problema. O importante é verificar em cada classe quais as propriedades que estão sendo compartilhadas pelos seus elementos, elementos, para haver uma uma boa relação r elação entre entre o modelo e a realidade. real idade.
Figura 16 - Classes se assemelham ass emelham a conjutos conjutos de objetos objet os
2.4.4.
Herança
A herança é uma das principais características da orientação a objetos, e que está intimamente associada ao conceito de agrupamento dos objetos segundo um conjunto de propriedades propri edades comuns. comuns. Um Uma classe class e de um objeto é o agrupam agrupament entoo de objetos que compartilham a mesma estrutura de dados e funções. É possível se encontrar grupos que possuam um conjunt conjuntoo de propriedades, propri edades, e que a partir deste grupo grupo seja possível pos sível criar outros grupos que possuam propriedades ainda mais específicas, formando assim um subconjun subconjunto to do anterior. A orient ori entação ação a objetos obj etos permite criar uma uma relaçã r elaçãoo entre as classes de objetos de modo que classe pode ser gerada a partir de outra classe, herdando herdando dela suas propriedades propri edades estáticas e státicas (atributos) e dinâm di nâmicas icas (funções). (funções). A herança herança permite ainda que que as características caracterí sticas herdadas da classe cla sse mãe possam ser alteradas e expandidas pela classe filha. Incluindo novas características, ou modificando características caracterí sticas existentes. existentes. Esta capacidade capac idade dos modelos modelos orientados a objetos perm p ermite ite que a modelagem seja feita em camadas camadas de classe c lasses, s, criando cr iando uma uma árvore ár vore para cada classe c lasse,, com um nível decrescent decresc entee de abstração, quando quando se caminh caminha da mãe mãe para a filha. O uso da herança permite permite criar cri ar classes class es mais genérica genéricas, s, com fun funcionalidades cionalidades gerais erai s e que podem ser herdadas por várias vár ias classes class es em diferentes diferentes situações simplificando simplificando a modelagem e implementação. A herança de classes aumenta muito a capacidade de reutilização das classes, porque pode-se criar classes genéricas com propriedades gerais e qu q ue podem ser utili utilizadas zadas em diversas divers as situ si tuações. ações. O reuso re uso de classes clas ses apresent apr esentaa um efeito positivo no prazo e no custo do desenvolvimento de projetos de software.
Figura 17 - Exemplo real de herança No exem exemplo, plo, a herança é utilizada utilizada para distribuir di stribuir os equipament equipamentos os em categorias categorias..
Observa-se que, inicialmente, todos são equipamentos. Os equipamentos podem ser para casa, cas a, podem ser elétricos el étricos e podem ser mecânicos. mecânicos. Alguns Alguns equipamen equipamentos tos para casa são também elétricos, criando a classificação dos eletrodomésticos. O conceito de herança e de objetos em software não é novo, mas foi pouco utilizado nos projetos de sistema até que as linguagens de programação que permitissem implem implement entar ar em softwar softwaree estes e stes conceitos com facili facilidade. dade. Hoje existem e xistem várias vária s linguagens orientada a objetos que permitem incorporar herança e encapsulamento nos sistema sistema de software.
2.4.5.
Polimorfismo
Uma decorrência interessante da comunicação por mensagens e da herança a orientação a objetos obj etos é o polimorfismo. polimorfismo. Define-se Define-se polimorfismo como a propriedade que o emissor de uma mensagem não precisa conhecer a instância da classe que recebe esta mensag mensagem em.. (Jacobson, (Ja cobson, et al, 1992). 1992 ). Esta propried pr opriedade ade leva l eva ao fato fato de que um uma mesma mensagem pode ser interpretada de modos diferentes, quando for recebida por objetos diferentes. Assim, como as implementações das funções que recebem a mensagem são diferentes elas podem responder de forma diferente (poli = múltiplas, morfo="forma"). Polimorfismo é a propriedade de que a mesma mensagem pode ser respondida de forma forma diferen di ferente te por duas ou mais mais classes. class es. Há alguma alguma confusão confusão entre o encapsulam encaps ulamento ento e o polimorfismo porque ambos ambos se se referem refer em ao ocultam oc ultamento ento da im i mplem ple mentação do d o mundo mundo externo ao obje o bjeto. to. No ent e ntanto, anto, o polimorfismo polimorfismo está está centrado centrado na possibilidade possibil idade de uma uma resposta respos ta diferente diferente devido ao desconh desc onheci ecim mento do destinatário desti natário da mensagem, ensagem, enqu e nquanto anto no encapsulam encapsula mento a implementação está apenas oculta do mundo exterior.
Figura 18 - Polimorfismo: a mesma mensagem mensagem tem respostas diferentes dif erentes
2.4.6.
Vantagens da Orientação Orientação a Objetos
Ao escolher desenvolver des envolver um softwar softwaree pelo paradigm paradi gmaa de objetos, ob jetos, o desenvolvedor procura obter uma série sér ie de vantagen vantagens, s, decorrentes deco rrentes das características desta abordagem: O uso de objetos na modelagem torna mais fácil descrever as estruturas e o comportamento existente no mundo real. Essa proximidade faz com que os clientes possam se identificar identificar mais mais diretam di retament entee com os problem proble mas nos modelos. modelos. O encapsulam encaps ulamento ento do conh conheci ecim mento em component componentes es isola iso la o com c omportament portamento, o, o que q ue permite permite que que as mudan mudanças ças nos requisitos possam também também serem isoladas em cada componente sem afetar o sistema como um todo. O uso de classes e objetos facilita a integração das fases do processo de desenvolviment desenvolvimento, o, porqu porq ue ao contrari contrarioo de outros outros modelos onde cada fase possui técnicas técnicas e paradigm par adigmas as próprios pr óprios,, na orien orie ntaçã a objetos ob jetos o mesmo esmo paradigm par adigmaa é conduzido da análise à construção. O encapsulamen encapsulamento to favorece o teste dos sistem s istemas as de softwar software, e, que pode ser isolado isola do para cada com c omponen ponente. te. O resultado é um um aument aumentoo na quali qualidade dade do sistem sis tema. a. O encapsulamento permite ainda que os componentes possam ser desenvolvido por fornecedores diferentes, diferentes, A reutilização, decorrente do encapsulamento, reduz custos e prazos no desenvolvimento de software porque possibilita que o mesmo componente seja usado em vários projetos, A herança herança associa a ssociada da ao encapsulam encapsulament entoo perm per mite abordar abor dar problem proble mas mais complexos do que com outras abordagems de desenvolvimento. A herança cria uma família de objetos com uma complexidade crescente e que podem ser aplicados em vários problemas diferentes. Algumas das vantagens da orientação a objetos podem ser compravadas na prática com o estudo de caso que se segue.
2.5.
Estudo Estud o de Caso: Automação Automação de Vendas
Para melhor entender os conceitos da tecnologia de objetos, segue um exemplo da aplicação desta tecnologia. O objetivo é destacar, didaticamente, as características da orientação a objetos em um sistema que reproduz uma automação de vendas. Não se pretende resolver o problema pr oblema de autom automação ação comercial, mas mas utili utilizar zar como como exemplo exemplo o problem proble ma do sistema sistema de inform informações ações para par a apoio às vendas em uma uma loja. loja . Como Como um um sistema sistema de inform informação ação gerencial, ele deve atender as regras do neg negócio ócio e, simultaneamente, ser flexível para acomodar as mudanças destas regras, resultado natural natural da evolução evol ução do negócio. negócio. A adoção adoç ão do paradigm par adigmaa de objetos o bjetos aju aj uda a obter o bter esta flexibil flexibilidade, idade, conseg c onseguuida pelo pe lo uso correto corr eto das características car acterísticas desta tecnologia tecnologia como: como: encapsulamento, as mensagens, a herança e o polimorfismo, que serão demonstradas a seguir. Este estudo estudo de caso c aso também também serve para ex e xemplificar emplificar a abrang abra ngência ência e aplicabi apl icabilidade lidade dos modelos em um sistema prático. Inicia-se formulando o problema por meio de uma visão do contexto onde este sistema se encontra. Segue-se construindo um modelo conceitual do sistema, que define as principais classes do sistema e suas relações. Das definições preliminares passa-se para um detalhamento que se traduz na implementação do sistema. O escopo do exemplo é limitado ao entendimento dos princípios da orientação a objetos, sem descer em detalhes excessivos dos códigos e das opções de implementação, que podem ser encontrados no capítulo 6, no final do livro.
2.5.1.
Contexto Conte xto do Problema Problema
O estudo estudo de caso ocorre oc orre com um uma loja l oja de departam depar tament entos os e o seu processo proc esso 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 código de barras que obtém, com base em um código, o preço dos produtos. Alguns produtos podem ter descontos descontos para pagament pagamentoo a vista, ou parcelament parcelamentoo em 2 ou 3 vezes, com ou sem juros. juros. Este estu es tudo do se interessa interessa pelas etapas de determ de terminação inação do preço pr eço e das d as condições de pagamento do produto. Deseja-se um sistema de informação que dado o código do produto informe o preço e as condições de pagamento deste produto. As condições de pagamento serão definidas em função do crédito que o cliente tem com a loja em um uma regra re gra de negócio negócio pré-estabelecida. pré-es tabelecida. Segue-se Segue-se a arquit ar quitetu etura ra do sistema sistema e as regras de neg negócio: ócio:
Arquitetura do Sistema O sistema é processado em uma rede de postos de venda, também conhecidos como POS (do inglês: inglês: point of sale sal e). Eles fazem a interface entre o caixa, funcionário da loja, e um comput computador ador central central que processa as requisições r equisições do processo proc esso de venda. A figura figura abaixo descreve descre ve esta arquit ar quitetu etura: ra:
Figura 19 - Esquema da Arquitet Arquitetura ura do Sistema da Loja O comput computador ador central central armazen armazenaa os dados dos d os produt pr odutos, os, dos clientes e do histórico das vendas em um banco de dados. As regras do negócio também são processadas no computador central. Os POS implementam uma camada de apresentação e comunicação com o caixa, e fazem as requisições ao computador central. Existe um pequeno poder de processamen proc essamento to local nos POS que que pode ser utilizado, dependendo dependendo da aplica a plicação ção e da estratégia estratégia de desenvolvim d esenvolviment entoo escolhida. es colhida.
Regras de negócio O processo de venda proposto para esta loja resume-se a três ações, executadas pelo caixa, cai xa, por meio meio do POS: 1. Identificar Identificar o produto pelo seu s eu código, [2]
2. Identificar o crédito do cliente e seus dados pessoais pelo seu CGC , e 3. Informando o número de parcelas, verificar se a venda parcelada foi aprovada. A principal regra de negócio negócio neste sistema sistema está na aprovação aprovaçã o do crédito cr édito nas vendas à prazo. Por uma norma estabelecida pela administração da loja, todo cliente tem um crédito gerenciado pela loja e que pode ser elevado pelo gerente, conforme as novas compras do cliente na loja. No entanto, o cliente não pode financiar compras acima do seu crédito. Se o saldo de uma compra parcelada for superior ao crédito do cliente, a venda não é aprovada. Por exemplo, se um cliente possui um crédito de R$1.200,00 e deseja comprar um produto produto de R$ 2.100,00 ele pode comprar à vista porque não não fica com saldo devedor. de vedor. Pode também também parcelar parcel ar em duas duas vezes de R$1.050,00 porque o saldo sal do devedor será de R$1.050,00 e inferior ao seu crédito de R$1.200,00. No entanto, se ele quiser parcelar em 3 vezes iguais iguais de R$700,00 terá um saldo de R$1400,00 superior ao seu crédito, crédi to, e não consegu conseguirá irá aprovar a venda. Esta regra pode ser s er expressa pelo pseudocódig ps eudocódigoo abaixo, abai xo, para uma uma venda de n parcelas, parcel as, onde: saldo - valor que que resta a pagar após a entrada entrada preco - preço do produto produto à vista n - número úmero de parcelas parcel as da venda credito credi to - limite limite de crédito crédi to do clien clie nte com a loja saldo = (n-1)*preco se (saldo<=credito) então vendaAprovada senão vendaNãoAprovada
Para incen i ncentivar tivar a venda para algu al guns ns clientes especiais especiai s iden ide ntificados como ClientesV ClientesVIP IP a loja loj a dá um crédito dobrado dob rado para pa ra estes e stes client cli entes, es, de modo que os clien clie ntes considerados VIP podem fazer dívidas com a loja duas vezes superiores ao valor do crédito, se não fossem VIP. É possível que alguns produtos tenham, em época de promoções e descontos, condições especia e speciais is de venda a serem definidos definidos posteriormente. posteriormente. Por exemplo, exemplo, uma uma promoção promoção pode permitir a venda de determ determinados inados produtos, produtos, em até 3 parcelas independent independentee do crédito do client clie nte. e. O sistem si stemaa a ser desenvolvido para autom automatiz atizar ar a loja deve ser flexível para acomodar estas modificações e outras novas regras de negócio no futuro.
2.5.2.
M odelo Concei Conce itual
Estabelecendo-se este e ste context contextoo e seus requisitos, é possível possív el defin d efinir ir um sistema sistema para par a atendê-los atendê-los,, partindo dos prin pri ncipais cipai s conceitos deste problem pr oblema. a. No modelo modelo conceitu c onceitual al já já são percebidas as características da orientação a objetos, onde o primeiro passo é identificar identificar as classes cl asses presentes no sistema. sistema. Analis Analisando ando a descrição descri ção do context contextoo do sistema, sistema, observa-se obser va-se que o processo de venda ocorre ocorr e entre os seguint seguintes es personag per sonagens: ens: O Cliente, que pode ser VIP ou não e possui o crédito; O Caixa que que processa proce ssa os pedidos como como usuário usuário final; final; O POS que define a interface com o sistema; A Loja onde estão aramazenadas as regras e informações e O Produto Produto que possui o preço pre ço e as ofertas. Com estes personag pers onagens, ens, é possível possí vel se s e definir o processo pro cesso de d e venda, sob o pont p ontoo de vista da orientação a objetos, caracterizando c aracterizando as mensagen mensagenss qu q ue os objetos trocam entre entre si. Sob este ponto de vista, o processo de venda ocorre em 3 fases, a saber:
Fase 1 - Identificação do Produto Para ident i dentificar ificar o produto produto pelo seu código, o caixa inicialmente inicialmente lê o código c ódigo no no produto produto e pergunt perguntaa para a loja: l oja: Qual é o produto produto com o código xxx xxxxx xx?? . A pergun pergunta ta é dirigida para a loja porque a loja é responsável por manter uma lista de seus produtos. A loja então, então, procura nesta lista lis ta o produto produto desejado desej ado e o retorna ao caixa cai xa com as inform informações ações sobre s obre este es te código. O caixa pode ent então, ão, se quiser, descobrir desco brir o nome nome e o preço do produt pr oduto. o.
Fase 2 - Identificação Identificação do Cliente Cliente Analogamente ao produto, o caixa pode pegar o número do CGC do cliente, e pergunt perguntar ar para a a loja, quem é o client clie ntee que possui possui o CGC yy yyyy yyyy yy?? A resposta da loja, loja , caso o cliente esiver presente na lista de clientes da loja, será o próprio cadastro do cliente, que retorna ao POS. Neste cadastro o caixa pode verificar os dados do cliente como nome, o crédito que este cliente possui, entre outras informações.
Fase 3 - Autorização do Crédito, para vendas à Prazo
O caixa, represent repr esentado ado pelo pel o POS, possui, após ap ós as consultas consultas anteriores, um produto produto e um cliente. Sabendo que o cliente deseja fazer a compra em n parcelas, algum elemento do sistem si stemaa deve inform informar ar se s e esta es ta venda pode ser realizada reali zada ou não. não. No exemplo, exemplo, a venda será realizada se a dívida do cliente, na compra parcelada, for menor do que o crédito que o cliente possui com a loja, como manda a regra de negócio. Algum componente da loja precisa ser responsável por testar esta regra de negócio. Tomando uma decisão de projeto, optou-se optou-se em atribuir atribuir esta respon respo nsabildade sabil dade para o produt pr oduto. o. Assim, Assim, para saber sabe r se a venda pode ser se r realizada re alizada o caixa c aixa pergunt perguntaa para o produto: Você Você produ prod uto, pode ser vendido para este client cli entee por n parcelas? O produto, produto, conhecedor conhecedor da regra de negócios, responde com um sim ou não e termina esta etapa do processo de venda. Estas três ações podem se decompostas na forma de mensagens trocadas entre os componen componentes tes principais pr incipais do neg negócio: ócio: caixa/POS, produto e cliente e loja. Imaginemos estes componentes como personagens de um mundo fictício, onde o processamento do sistema é realizado com uma coleção de perguntas e respostas entre estes componentes, esquematizada na figura abaixo:
Figura 20 - Comunicação Comunicação entre os Componentes da Loja Neste modelo modelo conceitual conceitual pode-se pode- se analisar as a s características carac terísticas de encapsulament encapsulamentoo das classes, class es, in i ntegração tegração com banco banco de dados, mensagens ensagens e herança; próprias própria s do modelo orientado a objetos.
Encapsulamento A primeira característica que se observa na descrição do problema é a existência de algun alguns objetos ob jetos bem identificados identificados.. Na descriç de scrição ão foram usados usados o POS, a Loja, o Cliente e o Produto. Nenhum Nenhuma ação a ção ficou sem se m um uma ori o rigem gem ou um destino des tino entre estes es tes obje o bjetos. tos. O hábito de fazer fazer compras em lojas, torna estes conceitos famili familiares ares para a maioria aiori a 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 Pr a facilitar facili tar o processo proc esso de venda a loja loj a mant mantém ém,, além de uma uma lista li sta de produtos para venda, um uma lista lis ta de clientes cadastrados, com um limite de crédito. A lista de produtos é análoga a uma estante onde os produtos a serem vendidos estariam expostos expostos para a venda. Cada Produto possui um preço, uma descrição e um código para facilitar a ven ve nda. Qu Qualquer alquer outro outro objeto do sistem sis temaa pode escolh escol her um Produto e verificar seu nome, preço e código simplesmente “perguntando” para ele. O Produto possui estas informações a seu respeito, e possui ainda meios para responder à pergunt perguntas as o tipo: Qu Qual al é o seu preço? A característica do Produto de ser autoautosuficiente em prover informações sobre si mesmo é conseqüência do encapsulamento. No modelo, modelo, a Loja é uma entidade que se relaciona com os POS para prover inform informações ações para as ven ve ndas. O POS é uma interface de acesso às informações da Loja, e por isso ele pergunta para a Loja o que que ele quer quer saber. Para conseguir conseguir dar todas as respostas como o preço do produto, ou o crédito do cliente a Loja conta com outros objetos encapsulados na própria Loja: uma listaDeClientes, que guarda guarda a lista li sta de todos os clientes da loja e um uma listaDeProdutos, que guarda todos os produtos à venda. Ao ser questionada sobre qual é o produto que possui um determinado código, 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 característica caracterí stica relacionada relac ionada ao encapsulamen encapsulamento to dos objetos: o objeto oProduto é transferido para o POS em resposta à esta mensagem, todas as informações e a capacidade capaci dade de receber mensagens ensagens e dar respostas r espostas vai com ele. Como está encapsulado encapsulado no objeto todas estas habilidades, abil idades, elas são transferidas em e m conjunt conjuntoo 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 quando pede para ident i dentificar ificar o Cliente pelo seu CGC. O nome, nome, o crédito c rédito próprios pr óprios deste client cli entee são sã o transferidos transferidos encapsulados encapsulados no objeto. Em um sistema sistema orient or ientado ado a objetos não há como separar separa r uma uma inf i nform ormação ação do seu s eu proprietário. proprie tário. Não é possível existir um um método sem que um um objeto seja o seu se u dono. O encapsulamento é obrigatório. Temos, Temos, neste exemplo, exemplo, duas classes: cl asses: a dos Produtos e a dos Clientes. As classes definem tipos de objetos. Uma classe define uma estrutura que é compartilhada por todos os objetos obj etos que forem forem criados a partir daquela da quela classe. class e. Esta estrutu estrutura é formada formada por um conjunto de dados armazenados pelo objeto, e um conjunto de funções que o objeto usa para se comu comunicar. Os dados e as funções funções estão encapsuladas encapsuladas no objeto obje to e só existem enquanto existir o objeto. Cada função é uma possível mensagem que o objeto está habilitado a responder. A análise de um sistema sistema parte, pa rte, inicialm inicial mente, ente, por uma uma defin de finição ição das classes class es do sistema para então definir como os objetos, gerados a partir destas classes, irão interagir. O modelo conceitual de um sistema é, em síntese, um modelo das classes do sistema, sistema, e da sua estrutura. estrutura. No modelo modelo conceitual conceitual devem d evem ser descritas descr itas as classes class es extraída extraídass do domínio domínio do problema pr oblema e como como elas el as se organizam organizam.. É de se esperar e sperar que terminada esta descrição, grande parte dos problemas estejam, conceitualmente, resolvi res olvidos. dos. Resta entretant entretanto, o, o detalhamento detalhamento necessári necess árioo para a implementação. implementação.
Integração Integração com Banco B anco de Dados A lista de clientes e a lista de produtos da loja devem estar disponíveis para a pesquisa assim assi m que o sistema sistema inicia a operação. oper ação. Para que isto seja possível pos sível elas devem de vem 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 de dados Para efeito de testes serão ser ão utilidadas as segu s eguint intes es tabelas tabel as de dados, que mostram mostram a estrutura dos dados disponíveis para a loja
Um objeto pode receber chamadas chamadas de mensagen mensagenss de outros outros objetos, para par a isso is so ele el e dispõem de funções que são acionadas pelo objeto chamador. Uma mensagem pode enviar com ela uma informação e recebe outras informações como resposta. A comunicação 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, pressionan pressi onando do botões para enviar as mensagen mensagens, s, e receben recebe ndo as respostas res postas em uma tela. As mensagens enviadas pelo Caixa ao POS se transformam e outras mensagens que o sistema como a Loja.A execução execução do sistema sistema se POS e pode enviar a outros objetos do sistema inicia com a criação da lista de clientes ( listaClientes ) e de produtos ( listaProdutos).
Antes da execução 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 exem exemplo plo optamos optamos por executar executar esta criação na inicialização iniciali zação do sistema. sistema. No entando, ela pode ser feita em tempo de execução, isto é, na medida em que os objetos são solicitados pelo sistema eles são procurados no banco de dados.
Mensagens A comun comunica icação ção ent e ntre re os o s objetos obj etos ocorre ocor re na forma de mensagens. mensagens. Um Uma mensagem mensagem é a chamada de uma função de um objeto, requerida por outro objeto. O objeto POS é uma interface gráfica criada para o caixa poder acionar as funcionalidades disponíveis nos objetos da loja, ou em objetos locais. Ele recebe a solicitação feita pelo Caixa e as transfere para os outros objetos do sistema. Esta seqüência de mensagens forma o processam process ament entoo em um sistema sistema orien orie ntado a objetos. O POS é uma classe criada para se colocar entre o usuário final, o caixa, e os demais objetos do sistema. Os elementos presentes no POS são caixas de diálogo e botões. Um Uma caixa de diálogo permite permite que que se entre entre com dados em caixas de texto texto apropriadas. apropri adas. Ou Outras tras caixas cai xas de diálogo di álogo apresent apres entaa uma uma forma forma do POS se comu comunicar com o usuário pelas mensagens escritas. Os botões representam as funcionalidade que o POS oferece ao Caixa.
Figura 23 - Interface Interf ace do POS POS A classe Cliente , por exemplo, oferece ao sistema a funcionalidade de informar o seu crédito. As mensagens podem ser entendidas como perguntas feitas de um objeto a outro. As perguntas não são formuladas na forma interrogativa como Qual é o crédito?, mas sim escritas na forma imperativa como obtenha o crédito ( ou getCredito ). Assim dado o objeto ob jeto comprador comprador do tipo Client Clie ntee (Cliente:comprador); podemos perguntar ao [3] qual o seu crédito, crédi to, usando usando a função função getCred getCredito ito , que devolve um valor de comprador qual crédito como resposta, na forma da mensagem:
vCredito = comprador.getCredito() comprador.getCredito() Neste comando, comando, a variável vCredito vCredi to recebe o valor do crédito crédi to do comprador. Como podemos podemos ver, o formato formato típic típicoo de uma uma mensag mensagem em,, também também conh conhecida ecida como a assinatura assinatura de uma mensagem, é mostrado abaixo. Entre os parentesis “( )” da função podem ser transferidos parâmetros e dados de entrada na pergunta. Resposta = objeto.função( ) O botão CLIENTE serve para enviar a pergunta para a Loja: Quem é o cliente que possui o CGC yy yyyy? Onde Onde o valor do d o cgc foi foi digitado na na área de en e ntrada de dados. A mensagem que é enviada ao objeto obje to Loja é : Comprador = loja.getCliente(yyy)
Figura 24 - Exemplo da Operação Operação do Sistema O botão PRODU PRODUTO TO pergu per gunt ntaa para a Loja: Qual é o produto com o código xxx? , com o valor do código digitado na área de entrada de dados.
oProduto = loja.getProduto(xxx) O botão PARCELAS PARCELAS pergunta pergunta para o produto, se ele pode ser vendido para este comprador comprador por n parcelas? parcel as? On Onde de n foi foi digitado na na área de entrada de dados e o oProduto e o comprador foram obtidos obtidos nas respostas r espostas das da s pergu per gunt ntas as acionadas ac ionadas por CLIENTE e PRODUTO.
Aprovado = oProduto.isAprovado( oProduto.isAprovado(n, n, comprador) comprador)
Figura 25 - Exemplo do sistema em operação A figura figura mostra mostra o processa proce ssam mento que não aprovou apr ovou a venda do item de código códi go 101 para o client cl ientee 1000 em 3 parcelas. parcel as.
Herança No exem exemplo, plo, foi definida um uma regra de negócio negócio na qual qual o client cli entee pode se tornar um um cliente do tipo VIP que possui as mesmas características do cliente comum, mas com uma capacidade de crédito dobrada. Isto é, ele pode fazer dívidas duas vezes maiores que o seu crédito. Assim deve-se criar uma classe ClienteVIP que deriva da classe Cliente , ou como se diz na linguagem da orientação a objetos, a classe ClienteVIP herda da classe Cliente os seus s eus dados e funções. funções. A capacidade de uma classe herdar de outra classe é uma das principais características da orientação a objetos. A classe Cliente é chamada de super classe, ou classe mãe, da subclasse ClienteVIP ou classe filha. O que isso que dizer que a classe filha é, inicialmente, uma classe igual à classe mãe, mas pode modificar ou extender suas habilidades, podendo ser mais especializada que a classe mãe original. No exem exemplo, plo, a classe cla sse ClienteVIP é uma classe Cliente possuindo por isso iss o um nome, um CGC e um crédito; no entanto, por ser um ClienteVIP ele terá o seu crédito dobrado. Para implemen implementar tar esta modificação modificação a função função de inform informar ar o crédito é reescrita reescr ita de modo a responder com o crédito em dobro, como mostra a tabela que compara estas duas funções funções::
Clien liente.ge te.getC tCre redi dito( to( )
Client lienteV eVIP IP.g .getC etCre redi dito( to( )
public int getCredito getCredi to ()
public int getCredito get Credito ()
{ }
return (credito); (credito);
{
return (2*credito);
}
Como o ClienteVIP é também uma classe do tipo Cliente, os objetos gerados por assumir o papel dos objetos obj etos do tipo Cliente, isto é podem fazer ClienteVIP podem assum parte da lista lis ta de Clientes Clientes da Loja e também também ser enviado como como resposta respos ta ao POS. Em qualquer situação onde um objeto do tipo Cliente possa ser usado um outro objeto do tipo ClienteVIP também também pode. Esta versatilidade vers atilidade dos sistem si stemas as orient ori entados ados a objeto dá ao analista uma liberdade muito grande para expandir o sistema sem perder as funcion funcionalida alidades des já j á implement implementadas. adas. O analista pode buscar as heranças heranças próprias pr óprias do problem proble ma estudado, estudado, e criar cria r árvores árvor es de classes, cla sses, descrevendo des crevendo o problema por interm intermédio édio de camadas crescentes de significado e funcionalidade. Quando o sistema em projeto atingir atingir o nível de sign s ignificao ificao desejado deseja do é interrompido interrompido o desenvolviment desenvolvimento. o.
3. Modelo de Contexto Contexto
Este capítulo capít ulo descreve o modelo de contexto context o do sistema, representado represent ado na UML pelo diagrama de casos de uso. Este modelo, o primeiro a ser criado para definir um problema, representa as expectativas funcionais dos usuários e por isso é desenvolvido em conjunto entre analistas e usuários. São descritos aqui alguns cuidados próprios deste tipo de modelagem, e o resultado da aplicação desta técnica em um exemplo de aplicação.
3.1.
Introdução
A escala de observação é o fator que define o nível dos detalhes observados em um modelo. Alguém olhando de uma grande distância pode distinguir uma casa na paisagem e até dizer se há fum fumaça saindo sa indo pela chaminé, chaminé, mas mas não saberá saber á dizer se as paredes par edes são s ão lisas e bem cuidadas, ou se há alguém na sala. Ao se aproximar um pouco mais poderá distinguir distinguir as portas e janelas e até enum enumerá-las. erá-l as. Aproximando-se Aproximando-se ainda mais da janela j anela da sala, sal a, por exemplo, exemplo, poderá pode rá olhar ol har por ela el a e saber s aber se s e há alguém alguém na sala, mas mas deixa dei xa de observar a chaminé. Perde-se a noção do todo ao se manter atento a um único detalhe. Deve-se escolher es colher a distân di stância cia e o ponto ponto de vista vi sta em função função do que se pretende analis analisar ar com o modelo. Observando um fenômeno com uma grande escala pode-se ver o seu comportamento global e o balanço entre as entradas e saídas, mas perde-se o detalhe de cada processo independente. Reduzindo a escala, o número de detalhes aumenta, e observa-se particularidades particularidade s que estavam perdidas perdi das na visão geral, o problem proble ma é que agora agora perde-se, perde -se, inevitavelment inevitavelmente, e, a visão vis ão global. Não é possível possí vel observar obse rvar globalmente globalmente e ao mesm mesmoo tempo ter todos os detalhes. Cada fenômeno a ser estudado exige que selecionemos uma escala adequada para modelá-lo. Este estudo propõe-se organizar a modelagem de sistemas de software segundo três modelos: modelo de contexto, modelo conceitual e modelo detalhado. Este capítulo descreve o modelo de contexto , que observa o sistema a uma grande distância, de modo que um único diagrama é suficiente para representar o sistema como um todo. Não é possível, possível , com o modelo modelo de contexto, contexto, observar detalhes da operação, operaçã o, construt construtivos ivos ou de imple implem mentação. No entanto, entanto, é um modelo odel o suficiente para se s e notar as funcion funcionalida alidades des principais pr incipais do d o sistem sis temaa e se s e ter uma uma definição clara cla ra de quais são 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 definição do problema, colocando o sistema no contexto do negócio e do cliente. A idéia de desenvolver um modelo que faça a integração do sistema em estudo com o contexto do cliente exige que o modelo seja simples, simples, e de certo c erto modo modo até intuitivo. intuitivo. Isto é, o client cli entee deve ser capaz de reconhecer o sistema no modelo sem a necessidade de um treinamento especial. O modelo de contexto contexto não deve possuir poss uir uma uma formalida formalidade de excessiva, excessiv a, para poder ser entendido e validado pelo próprio cliente. Deve ser possível ao cliente situar o sistema no seu contexto de trabalho, identificando pontos de integração com outros sistemas e com seus usuários.
Para criar o modelo modelo de contexto contexto usaremos usaremos dois recursos da d a UML UML: o diagrama diagrama de pacotes e o diagrama diagrama de casos de uso. O modelo de pacotes pac otes ajuda a dividir um sistema sistema em subsistemas, e identificar as dependências entre os subsistemas. O modelo de casos de uso ajuda a definir os requisitos fun funcionais e a desenh dese nhar ar a fronteria fronteria de cada subsistema.
3.2.
Pacotes, Sistemas Sistemas e Subsistem Sub sistemas as
Ao se estudar um sistema de informações, que se pretende automatizar, pode-se chegar a um número de problemas que impledem o seu tratamento, como um todo porque o conjun conjunto to é complexo complexo demais. demais. O analista precisa precis a ter neste neste mom moment ento, o, ferramentas para organizar este sistema complexo em partes menores, às quais chamamse de subsistem subsis temas. as. Um Um subsistem subsis temaa possui poss ui todas todas as carac ca racterís terísticas ticas de um sistem sis tema, a, e é parte integran integrante te de um um sistema sistema completo completo maior. maior. A organização em subsistemas surge, naturalmente, da análise detalhada de um problem proble ma. Ela pode ser realizada real izada por um particionament particionamentoo funcion funcional, al, organizacional, organizacional, operacional, operaci onal, ou por diversas dive rsas outras outras formas. formas. A única exig e xigência ência é que a união destas partes, ao final, final, formem formem o sistema sistema completo completo proposto inicialmente. inicialmente. O pacote é o elemento da UML utilizado para agrupar os elementos de um sistema, para organizá-los organizá-los,, um um pacote pode abrigar outros outros elem el ement entos, os, outros outros diag dia gramas, ramas, 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 - Representação de um pacote A representação gráfica de um pacote é feita pelo o ícone de uma pasta, metáfora que recor re corda da um armazenador, armazenador, um conjunto conjunto de conteúdos organizado sob so b um nome, nome, o nome do pacote. Apesar de estarem sendo indicados aqui para par a modelar modelar os sistem si stemas as e su s ubsistemas, bsistemas, os pacotes podem ser aplicados apl icados em e m qualquer qualquer fase do desenvolvimento desenvolvimento de um um software, inclusive para organizar organizar as próprias pr óprias fases do desenvolvim des envolviment ento, o, versões vers ões do sistema, sistema, isolar isol ar component componentes es de softwar software, e, etc. Os pacotes se aplicam aplic am a todos os modelos da UML, mas tem uma aplicação maior nos diagramas estruturais como os de classes e casos de uso. A boa prática manda usar nomes simples, curtos, escrito em letras minúsculas. Os
nomes devem estar associados aos componentes principais, ou subsistemas, que o pacote represent repres enta. a. Os pacotes podem se relacionar rel acionar com outros outros pacotes, através de uma uma relação de dependência. Um subsistema pode depender de outro subsistema. Esta relação pode ser apresentada graficamente, em um diagrama de pacotes. As dependências são representadas por meio de setas tracejadas. As setas partem do subsistema dependente e apontam para os subsistemas independentes.
Figura 27 - Exemplo de dependência entre subsistemas subsist emas Retomando o exemplo do sistema de automação comercial que controla as vendas de uma uma loja loj a e gerencia o crédito cr édito e o cadastro dos client clie ntes. es. Para Par a organizar organizar este sistem si stemaa pode-se dividídi vidí-lo lo em três subsistemas: subsistemas: vendas, crédito crédi to e cadastro; como como mostra mostra a figura. figura. Nela pode-se pode- se ver que o subsistema subsistema vendas depende dep ende do subsistema subsistema de crédito e de cadastro, c adastro, adicionalm adi cionalment ente, e, o subsistema subsistema de crédito crédi to também também depende 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 evolução do sistema em direção à fase de implementação, os modelos se tornam demasiadamente complexos, grandes ou poluidos com informação em excesso. excesso. O uso de pacotes pode aju aj udar a organizar organizar os modelos nestes nestes caso, ca so, além al ém da divisão em subsistemas já vista. Deve-se, no entanto, tomar o cuidado para não utilizar pacotes em excesso, que que uma uma vez pode ser um elemento elemento que que dificulta a leitura leitura de modelos simples. Em uma primeira abordagem, a escala dos subsistemas permite definir os limites do sistema sistema e sua s ua divisão, quan quando do necessária, necessári a, em subsistem subsistemas. as. Deve-se agora observar o interior interior de cada subsistema, subsistema, para criar cria r um modelo qu q ue perm per mita observar observ ar cada
pacote isoladam isola dament ente, e, em um único diagrama. diagrama. O modelo modelo de contexto contexto aum aumenta enta o seu nível nível de detalhes, mas permite ainda uma visão global, feita com uma grande escala, com um alto nível de abstração.
3.3.
Modelo de Contexto
O modelo de contexto define a fronteira entre o que é sistema do que não é sistema. O que é sistem sis temaa pode ser modificado pelo desenvolviment desenvolvimentoo do software software.. O que não é sistema, sistema, e por isso ficará fora da fronteira, fronteira, não pode ser se r modificado modificado pelo soft s oftware ware,, mas 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 técnica tem como principal vantagem a simplicidade da representação, que permite uma interação direta com os client clie ntes es e usuários na definição dos d os requisitos r equisitos funcion funcionais ais do sistem si stemaa Em 1987, Jacobson Jac obson apresenta os Casos de Uso (Use Cases) usados como ferramenta da metodologia Objectory. A adoção do termo Caso de Uso possui claramente a intensão em mostrar uma visão do usuário do sistema, e de que o sistema de informação é construído construído para par a os seus s eus usuários. usuários. No diagram dia gramaa de casos ca sos de uso o sistema sistema é descri de scrito to como uma caixa preta, e que possui algumas funcionalidades. Cada funcionalidade corres cor responde ponde ao que que se convencionou chamar chamar de Caso de Uso. Uso. Em 1992, Jacobson Jaco bson (1992) lança um livro livr o onde onde toda a Engenh Engenharia aria de Software Orient Ori entada ada a Objetos é desenvolvida sob uma abordagem de Caso de Uso. O diagrama de Casos de Uso foi incorporado desde a prim pri meira versão da UML UML (Jacobson, 1998) com c omoo uma uma abordagem abor dagem funcional feita pelo usuário, com finalidade de nortear os demais diagramas do modelo orientado a objetosda UML.
3.3.1.
Diagrama Diagrama de Casos de Uso
O objetivo do diagram dia gramaa de casos de uso é descreve d escreverr um modelo fun funcional de alto nível do sistema sistema em projeto. Este diagram di agramaa procura pro cura identificar identificar os usuários e represent repres entar ar o sistema segundo a sua visão. Jacobson (1992) afirma que um conjunto de descrições de casos cas os de uso deve especificar es pecificar completam completament entee a funcion funcionalida alidade de do sistema, sistema, assim ass im os desenvolvedores devem procurar procurar junto junto aos usuários de cada subssistem s ubssistemaa formar formar este e ste conjunto de casos de uso. Os casos de uso são utilizados em todas as fases do desenvolvimento de um sistema. No início início,, durant durantee o desenvolviment desenvolvimentoo e ao final, final, quando quando o sistema sistema está pronto. pronto. A aplicabilidade inicial do diagrama de casos de uso é a de auxiliar o analista na definição definição dos requisitos r equisitos do sistem s istema. a. Os requisitos r equisitos que o sistem si stemaa devem atender atender são decorrentes do uso que os usuários pretendem do sistema. As funcionalidades pretendidas devem ser transform transformadas adas em objetivos que o sistema sistema deve cumprir cumprir para seus usuários. usuários. Esta definição definição de requisitos r equisitos pode ser suficiente suficiente para se assum as sumir ir um contrato entre os clientes e desenvolvedores na fase inicial do projeto. Os objetivos dos usuários serão os casos de uso do sistema, e o compromisso dos desenvolvedores é de atendê-los. Durantee as fases de design Durant de sign e construção, construção, os casos de d e uso são usados para par a ajudar a criar outras visões, além da funcional, do sistema. A análise da descrição dos casos de uso pode ajudar a entender entender os processos proc essos e a dinâm di nâmica ica dos do s problem probl emas as envolvidos no sistema. sistema. A partir da descrição desc rição,, contida contida nos casos cas os de uso, pode-se pode- se extrair o que sistema sistema deve fazer e como ele deve atender atender os usuários usuários.. Os casos de uso devem ser explorados durante durante o desenvolvim de senvolviment entoo para par a validar va lidar o sistem si stema. a. A cada c ada nova funcionalidade funcionalidade implem implement entada ada no sistema sistema os casos c asos de uso podem ser usados para par a validar val idar se esta es ta funcionalidade está de acordo com o especificado pelos usuários. Como os casos de uso são criados a partir da visão do usuário. Eles podem ser aplicados aplic ados na fase final de testes de int i ntegração egração do sistem si stema. a. A partir de cada de uso é possível possív el definir testes, por vezes vezes chamados chamados de casos cas os de teste, que são aplicados no sistema, sistema, quando quando este estiver e stiver pront pr onto. o. Os diagram di agramas as de casos de uso podem ser usados para o planejam pl anejament entoo do desenvolviment desenvolvimentoo do sistema, sistema, uma uma vez que que é possível possí vel extrair das funcionalidades contidas nos casos de uso uma medida da complexidade. Apesar de grande flexibilidade, a utilização dos casos de uso deve ser limitada, e pode ser mal utilizada utilizada se for extrapol extrapolada ada a abrangência abrangência da sua aplicação. É comum comum se tentar traduzir a funcionalidade expressa nos casos de uso diretamente para um sistema de software, deix dei xando de lado os modelos modelos orientados a objeto. obje to. Esta é uma uma abordagem abor dagem
exclusivamente funcional, uma vez que os diagramas de casos de uso são análogos aos diagramas de fluxos de dados (DFD) da abordagem funcional. Agindo assim, abandonase a orientação a objetos obj etos e volta-se ao paradigm para digmaa fun funcional. O diagrama diagrama de casos c asos de uso deve isolar isol ar os elementos elementos do sistem sis temaa de soft s oftwar waree dos elementos externos. Os elementos externos são 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 Diagrama de Casos Casos de Uso No exem exemplo plo observa-se obser va-se que um um ator (ator1) pode se com co mun unicar icar com c om mais de um caso de uso, isto é, pode utilizar o sistem si stemaa para mais de uma uma finalidade (casos ( casos de d e uso 1 e 2). Assim tam também bém,, a mesma mesma finalidade (caso de uso 2) pode ser se r 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 sistema é não poder ser s er alterado al terado pelo pel o desen dese nvolvimento volvimento do sistem si stema. a. Isto quer dizer que o desenvolvedor não tem sobre o ator o poder pod er de programar programar a sua ação, como ele tem sobre o computador nos casos de uso. Ao focar os atores, a modelagem procura se concentrar concentrar em como como o sistema sistema será utilizado, e afastar afastar o analista de como como o sistema sistema será ser á contruído. contruído. Ainda não deve haver na descrição descriç ão dos casos de uso compromisso assumido com a construção. A importância dos atores, no modelo de contexto, vem do princípio de que os sistemas computacionais servem para atender as necessidades de seus usuários usuários.. O mais mais important importantee nos prim pri meiros passos do desenvolvimento de um sistema é identificar quem são os atores e quais são as suas necessidades. Um ator é um papel de alguém ou alguma coisa no ambiente que se relaciona com o sistema. Alternativamente, Jacobson (1992) define ator como representando tudo que recisa trocar informação 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 sistema por mais de um ator. O termo termo ator caracteriza c aracteriza bem a possibili possi bilidade dade do mesmo esmo usuário, em diferentes diferentes situações, assum ass umir ir personalidades personalidade s diferent d iferentes es para o sistema, agindo como um ator em uma peça teatral. Em cada uma destas situações, deve-se procurar identificar as necessidades dos atores, que se tornarão requisitos para o sistem sis tema, a, na forma forma de casos c asos de uso. A linha linha que separa os atores dos casos cas os de uso é a fronteira do sistema. Deve-se notar a diferença entre atores e usuários. Os usuários usuários do sistem sis temas as são sã o instâncias dos atores. Um mesmo usuário pode, em diferentes momentos do sistema, instanciar diferentes atores, ou seja um mesmo usuário pode assumir diferentes papéis no sistema.
Representação . Os atores são, normalmente, representados por uma figura humana estilizada. A UML admite também o uso de ícones e outras simbologias para representar um ator, que podem ser representados rep resentados tam também bém por um retângulo retângulo com a anotação anotação <
>. A anotação <> , representa um estereótipo da UML, e permite transformar a simbologia escolhida em um ator.
Figura 29 - Formas Formas alternativas alter nativas de representar re presentar um ator. Os atores devem ser identificados com um nome que traduz o papel deles no sistema. Não existem regras rígidas para dar nomes aos atores, mas uma boa prática é utilizar nomes substantivos, com o significado ligado ao domínio do problem proble ma estudado. estudado. Deve-se evitar evi tar dar nomes nomes muit muitoo genérico genéricoss como: como: Usuário, Operador ou Sistema. O uso da palavra "Usuário", como o nome de um ator, pode ser utili utilizada zada desde qu q ue, por exemplo, exemplo, aquele a quele ator represente rep resente todos os usuários do sistema. sistema. Os atores são encontrados encontrados entre entre os o s usuários usuários prováveis provávei s do sistema. sistema. Usuários Usuários que podem ser pessoas pess oas ou até até mesm mesmoo outros outros sistem si stemas as comput computacionais. acionais. Um Uma das técnicas é cercar, imaginariamente, o sistema e observar quem interage com ele. Pode-se procurar a quem a solução sol ução do problem proble ma interessa, e quem colabora colabor a para se chegar chegar a esta solução. Nestes personagens encontram-se os atores. É comum encontrar grupos de personagens, personagens, que se comportam comportam da mesm mesmaa forma forma frente frente ao sistema. sistema. Estes grupos grupos são representados com um único ator do sistema. A mesma pessoa, usuária do sistema, pode pertencer a mais mais de um grupo, grupo, e assim assi m uma mesm mesmaa pessoa pode assum a ssumir ir mais do que um papel, e ser representada no modelo de contexto por mais do que um ator. Em um processo process o é possível pos sível que os atores se relacionem relac ionem entre entre si, si , trocando informações, mensagens ou realizando algumas operações entre si. O analista deve observar se esta comunicação comunicação entre entre atores se dá dentro dentro ou fora do sistem si stema, a, para decidir decidi r se deve ou não representá-la. Quando a comunicação é feita dentro do sistema ela é importan importante te para o desenvolvedor dese nvolvedor porque por que deverão existir e xistir comandos comandos e interfaces no softwar softwaree para permitir permitir que os dois do is atores se relacio re lacionnem. em. No caso da comu comunicação fora do sistem si stemaa ela não é represent repres entada ada pelos pel os casos cas os de uso e não é important importantee para o desenvolviment desenvolvimentoo do software software.. Um ator represent repr esentado ado no sistem sis temaa não pode ser programado, programado, ele el e fica fora do escopo es copo do desenvolvim des envolviment entoo do sistema, sistema, e, provavelm provavel mente, ente, não é alterado pelo sistema. sistema. Observa-se, entretanto, que a introdução de um sistema de informações afeta muito além do que as fronteiras fronteiras definidas definidas inicialmente, inicialmente, podendo ir para p ara além a lém dos usuários usuários.. No
início do desenvolvimento de um sistema um ator possui necessidades que são expressas e consideradas como como requisitos do sistema sistema de soft s oftware ware.. Quando Quando o softwar softwaree é implem implement entado, ado, e as necessidade iniciais são atendidas, atendidas, surgem surgem outras outras necessidades necessida des nos usuários usuários,, que foram provocadas provocada s pela pel a introdução introdução do sistema, sistema, ou seja, o sistem si stemaa pode também alterar os atores. Este efeito é, normalmente, desconsiderado no desenvolviment desenvolvimentoo pela pel a sua alta complexidade complexidade e pela pel a incapacidade incapacida de de ser s er modelado e tratado com precisão. 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 representação de atores em um determinado sistema. Considerando que a melhor alternativa é aquela que incorpora uma quantidade maior de informação, temos que:
3.3.3.
Caso de Uso
As necessidades dos atores são representadas nos casos de uso. Um caso de uso é uma seqüência de transações ocorridas no sistema, que refletem em algo de importância para o ator que se comun comunica ica com este este caso de uso. Os atores definem definem suas necessi necessidades dades na form formaa de objetivos obj etivos a serem cum cumpridos pelo sistem s istema, a, que são capturados pelos pelo s casos de uso. O princípio, por po r trás deste de ste diagrama, diagrama, é que um sistema sistema de soft s oftware ware é criado cri ado para atender atender os o s seus usuários, representados rep resentados no diagrama diagrama pelos pel os atores. Os atores dem d emandam andam resultados do sistema, sistema, que se organizam organizam em objetivos, representados re presentados nos casos de uso. Um caso de uso se traduzirá em uma série de ações, que vão descrever como um ator poderá atingir atingir o seu objetivo, assim assi m como como as alternativas e as exceções que irão impedir impedir a conclusão com sucesso deste objetivo. Todos estes cenários de interação interação do ator com o sistema sistema devem estar inclusos na na descrição descr ição dos caso cas o de uso. Utiliza-se um caso de uso quando se deseja representar uma funcionalidade de alto nível 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 agrupando-as e associado as sociado-as -as aos a os atores. Um caso de uso é composto composto por uma uma representação re presentação gráfica e por um descrição descri ção textual, textual, que são descritas desc ritas a seguir: seguir:
Representação Gráfica 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á represent repres entando. ando.
Figura 30 - Representação Gráfica de um Caso de Uso Uso O nome do caso de uso é, em geral, uma oração verbal curta que representa, no contexto do sistema, o objetivo pretendido. Os atores formam o sujeito da ação
expressa pela pe la oração. Desta forma, forma, é convenient convenientee utilizar verbos ver bos no present pr esente, e, no infinitivo ou no gerúndio 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 cas os de uso como predicado, na form forma: a:
O Gerente (pode) aprovar crédito O Cliente (está) consultando Catálogo O Comprador Comprador realiza reali za a compra.
Figura 31 - Exemplos de Casos Casos de Uso Descrição Descrição Textual
Associado Associado a cada caso de uso um texto descreve os fluxos f luxos de eventos que resultam r esultam no objetivo pretendido pelo ator. Todo caso de uso tem, necessáriamente, um fluxo de atividades principal, que vai levar o ator ao sucesso do seu objetivo. A seqüência normal de atividades pode apresentar caminhos alternativos ao fluxo principal, assim como seqüências de atividades que descrevem falhas que impedem o ator de atingir o seu objetivo. A figura mostra, esquematicamente, estes fluxos, que devem ser descritos descr itos em um texto que acompanha o caso de uso:
Figura 32 - Fluxos possíveis possívei s em um caso de uso uso (a) principal, (b) alternativo e (c) caminho com falha A descrição dos casos de uso pode ser escrita em uma linguagem informal, em um texto estruturado ou até mesmo com um pseudocódigo. O importante é que a descrição de um caso de uso possa ser aprovada pelo cliente do sistema, e que os projetistas possam enten entender der o processo proc esso de negócio. negócio. Os casos de uso podem também também ter pré e pós condições, que vão condicionar a seqüência s eqüência de transações que devem ocorrer. As precondições dizem di zem que para o ator poder executar executar aquele aquele objetivo obj etivo são necessárias necessári as algum algumas condições c ondições anteriores, assim assi m como como a execução execução do d o objetivo obj etivo leva l eva a uma uma condição posterior à execu e xecução ção (pós-condição). (pós- condição). Toma-se como exemplo o caso de uso onde um cliente consulta um catálogo de produtos produtos de uma uma suposta loja virtual. Este caso de uso, uso, chamado chamado de Consultar Consultar Catálogo Catálogo pode ser descrito de scrito textu textualmen almente, te, de form formaa não estrut estruturada urada como: como:
Caso de Uso: Consultar Catálogo
Busca por um ou mais produtos em um catálogo de produtos. Os produtos são organizados por tipo e família. A consulta pode ser feita selecionando-se o tipo de roduto e em seguida escolhendo uma família daquele tipo. Os produtos podem ser ordenados por preço ou por ordem alfabética do nome. É possível procurar um roduto por parte do nome ou da descrição. A procura fornece uma lista de produtos onde o texto procurado foi encontrado no nome ou na descrição. Se o usuário da consulta já se identificou para o sistema, a lista dos últimos 10 produtos procurados
ode ser apresentada, facilitando a procura. Este mesmo caso de uso também pode ser descrito de forma estruturada, como: Nome: Consultar Catálogo Catál ogo Objetivo principal : Permitir a procura de um ou mais produtos em um catálogo
de produtos organizado por tipos e famílias de produtos. Alternativas Alternat ivas Alternativamente a procura pode ser feita por uma palavra existente no
nome ou na descrição do produto.
Se o catálogo não oferece o produto procurado, oferecer uma lista com os dez produtos mais procurados.Se mais de 50 produtos atendem o critério de rocura, os produtos são apresentados em grupos de 50. Exceções
Précondições
: O cliente deve estar cadastrado, cadastrado,
Pós-condições Pós-condiçõe s : Após a procura os produtos encontrados passam a compor a lista
de produtos procurados, que podem seguir para o processo de compra. A descrição descri ção estru es trutu turada rada é mais formal formal e por isso mais completa completa que uma uma descrição desc rição não estruturada e informal. A descrição informal é suficiente na maioria dos sistemas, principalmente principalmente para a validação vali dação do modelo modelo de contexto contexto por parte dos usuários. usuários. No entant entanto, o, a descrição descri ção estru es trutu turada rada é mais adequada na aplicação apli cação dos Casos de Uso em um um método formal para desenvolvimento de sistemas.
Colaboração entre os Casos de Uso Os casos de uso podem colaborar com atores e com c om outros outros casos ca sos de uso. Estas colaborações colabor ações são expressas no diag dia grama rama por meio de ligações entre os elem el ement entos os que colaboram. As ligações podem, opcionalmente, ter uma seta que não tem valor semânt semântico, ico, ela el a apenas orient ori entaa a leitu l eitura ra do diagrama. diagrama. As colaborações cola borações dos casos cas os de uso são sem se mpre bidirec bi direcionais, ionais, o que quer dizer que pode haver troca de inform informação ação nos dois sentidos da colaboração. Os atores se comunicam, controlam e recebem informações dos casos de uso. Uma colaboração entre os casos de uso e os atores indica que os objetivos do ator são definidos pelos casos de uso. Deve-se verificar se todos os objetivos do ator estão
presentes e são bem definidos. definidos. Um caso de uso pode colaborar colabor ar com co m outros outros casos de uso para conseguir conseguir cumprir cumprir o seu objetivo principal. pri ncipal. Isso quer dizer que um objetivo principal pr incipal pode ser decom de composto posto em objetivos intermediári intermediários os de outros outros caso de d e uso. Esta decomposição fará com que que os casos de uso mantenham entre si uma relação de dependência, representada pela seta tracejada. O caso de uso dependente está na origem da seta, e o independente no destino da seta.
Figura 33 - Colaboração entre os Casos de Uso
3.3.4.
Considerações Considerações Gerais Gerais sobre o M odelo de Contexto Conte xto
Algumas considerações gerais são importantes na formação do diagrama de casos de uso, e podem auxiliar a criar um diagrama correto.
Independência entre Casos de Uso Os casos de uso devem ser escolhidos e scolhidos de modo a serem sere m independent independentes es entre si, apesar de poderem existir relações entre eles. Isso se deve para evitar que hava uma confusão confusão entre entre as a s funcion funcionalida alidades des especificada e specificadas. s. Erros Err os na separação separ ação pode, pod e, alg al gumas umas vezes, levar à inconsistências inconsistências entre entre os casos de uso. Um Um caso de uso pode especificar especi ficar um tipo de responsabilidade que é negada por outro. O modelo de contexto não tem meios de evitar ou lidar com c om estas inconsistências, inconsistências, que serão tratadas por outros outros modelos, posteriormente.
Granularidade dos Casos de Uso Um dúvida frequente durante a construção do modelo de contexto é o grau de detalhes que se deve adotar ao se criar em caso de uso. Por definição, os casos de uso reúnem um conjunto de transações que conduzem à um objetivo do ator. Assim, se por um lado, os casos de uso devem ser mais complexos do que uma simples transação; por outro lado os casos de uso não devem compreender um número muito grande de transações. Um número grande de objetivos, poderiam ser decompostos em alguns casos de uso. uso. A situação situação desejada desejad a é uma uma situação situação interm intermediári ediária. a. Espera-se que os casos de uso escondam um uma complexidade complexidade razoável, que serão ser ão exploradas, exploradas , posteriormente, posteriormente, no no modelos modelos conceituais e detalhados detalhados (pelos (pel os diagramas diagramas de seqüên seqüê ncia e colabor col aboração ação). ). Os fluxos fluxos de informação textu textual al condu co nduzz o leitor lei tor do diagram dia gramaa a uma uma estrutura funcional do sistema. Na análise conceitual, os fluxos de eventos vão conduzir o analista aos conceitos fundamentais do sistema, que serão distribuídas entre as classes do sistema. Não 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 não comprom comprometer eter a aplicaçã apl icaçãoo do paradigm par adigmaa de objetos obj etos no decorrer do projeto. proj eto.
Evi Evitar a decomposi de composição ção de casos de uso
Outro erro comum, na aplicação dos casos de uso, é a tentação de se realizar uma decomposição decomposição de objetivos obj etivos dos do s atores, atores , como é comum comum na na análise anális e estru es trutu turada. rada. Criandose casos de uso int i nterm ermediár ediários ios como como etapas de um processo, process o, transformando-se transformando-se o diagrama de casos de uso em um fluxograma de processos. Pode-se estabelecer uma relação direta entre um diagrama de contexto da análise estruturada e diagrama de casos de uso, mas não se deve transformar um diagrama de casos de uso em um fluxograma. Na decomposição decomposição funcional funcional há um uma grande grande proximidade proximidade com as fun funções, ções, na abordagem de dados, dados , a proximidade proximidade é com os dados, e na abordagem de objetos a proximidade proximidade é com o objetos. Com Comoo os casos de uso tem uma uma naturez naturezaa funcion funcional, al, a mudança para objetos, realizada nas fases seguintes da análise, 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 provavelmentem,, haverá haverá a criação cr iação de objetos o bjetos iguais iguais nas duas equipes equipes com funcion funcionalida alidades des semelhan semelhantes tes e que deveriam deveria m estar estar agrupados agrupados (Berard,1996). (Berard,1996) .
Integrar o cl c liente na modelagem O diagrama de casos de uso deve ser construído em conjunto entre os usuários e demais demais projetistas. A notação notação simples facilita facili ta o en e ntendim tendiment entoo e estimula estimula a crítica c rítica ao modelo, perm p ermitindo itindo validá-lo validá-l o já nas fases iniciais da análise. Como Como o diagram di agramaa de casos de uso traduz uma uma visão vi são de fora para dentro dentro do sistema, sistema, descrevendo desc revendo o que o sistema sistema deve fazer, fazer, é important importantee a aprovação a provação do client cli entee e usuários para par a o sucesso do projeto. Deve-se, entretanto, entretanto, evitar o excesso de d e formali formalism smoo na elaboraçãos elabora çãos dos casos de uso. Desaconselha-se, Desaconselha-se, por ex e xemplo, emplo, o uso de recursos rec ursos comput computacionais acionais na elaboração el aboração dos casos de uso quando da apresentação dele para os seus usuários, que pode afastálos do d o processo proces so de desenvolvim d esenvolviment ento. o. O uso de um retroprojetor, retroproj etor, quadro-branco, flipchart, papel e lápis l ápis é encorajado ao se discutir um modelo com os usuários usuários.. Estas ferramentas são mais familiares e aproximam os usuários leigos em computação com o desenvolvimento do sistema. O computador ou sistemas sofisticados de software podem ser considerados considera dos barreiras barre iras à participação participaç ão dos usuários usuários nesta fase do projeto. A validação valida ção de um sistema sistema pelo client clie nte, e, nas fases iniciais iniciai s so projeto, proje to, garante garante que que está se con co nstruindo struindo o sistem si stemaa correto. corr eto. Isto Isto é, as reais reai s necessidades necessidade s dos usuários usuários estão sendo consideradas e atendidas. Para isso é necessário revisar, iterativamente, o modelo de contexto inúmeras vezes com os usuários. Em alguns casos, pode ser
necessário criar um protótipo da interface, para apresent apr esentar ar ao usuário, usuário, que assim pode se assegurar que o sistema irá atendê-lo, pois visualiza ali a operação do sistema. A identificação identificação dos requisitos r equisitos de interface interface podem ser extraídos extraídos facilment facilmentee do diagrama diagrama de casos de uso, analisando as relações re lações entre entre um ator e os casos de uso com quem quem ele se se comu comunica. É de se esperar espera r que para cada c ada caso cas o de uso deva haver uma uma interface para acionar o objetivo e receber as respostas.
Comprometimento Comprometimento com a implementa mplementação ção O ocultam oc ultamento ento de inf i nformação ormação ( Information Information Hiding ) é o processo de tornar certas partes do sistem sis temaa de software inacessíveis. inacessívei s. Sugere-s Sugere-see que os detalhes detalhes do sistem sis tema, a, as decisões decisõ es de projeto difíceis di fíceis ou que provavelmente provavelmente vão mudar, mudar, devam ser ocult o cultadas adas do sistema. sistema. Assim, o resto res to do sistem si stemaa tem acesso apenas as decisões decisõe s bem definidas, definidas, e inalteradas. Com a especificação descrita pelos casos de uso deve-se evitar expor detalhes em demasia, ou impor decisões que serão tomadas no projeto ou na implem implement entação. ação. Deve-se Deve- se procurar pr ocurar evitar evi tar a tentação tentação de especificar especi ficar a estrutura estrutura interna interna ou caraterísticas de implementação que condicionem, exageradamente, o componente, limitando-o quando da sua implementação.
Casos de Uso em Testes Um caso de uso é descrito por cenários de sucesso, alternativos e de fracasso de um objetivo do ator no sistema. Analisando um caso de uso é possível se criar um conjunto de dados de entrada que simule simule cada um destes cenários. Assim, Assim, para cada caso ca so de uso é possível se construir um caso de teste, que garante que o sistema, ao implementar o caso de uso, será completamente testado. Essa é uma importante característica de um projeto de software com casos de uso, que irão orientar todo o desenvolvimen desenvolvimento to do softwar softwaree atendendo atendendo as necessidades dos usuários. Se houver dificuldade em se estabalecer estes testes, deve-se suspeitar da clareza e da precisão deste caso de uso, ou até mesmo da sua real necessidade.
Cuidados nas descrições textuais Probasco (2001) destaca o cuidado que deve haver, por parte dos desenvolvedores, na redação da descrição dos casos de uso. Em especial, ele destaca uma atenção maior
para a palavra pal avra “deve”. “deve ”. Como Como os requisitos dos casos cas os de uso expressa expressam m a vontade vontade dos usuários, utilizar a palavra “deve” pode gerar obrigações que não podem ser cumpridas, ou limitar, exageradamente, a implementação do sistema. Como prática geral, não se recom r ecomenda enda o usar a palavra palavr a “deve”, “deve ”, sugerindo sugerindo substituí-l substituí-laa por “sugere“sugerese”, “recom “r ecomenda-se”, enda-se”, etc. O important importantee do caso cas o de uso é que ele sirva sir va como como meio meio de comu comunicação entre o client cl ientee e os desenvolvedores. des envolvedores.
3.4.
Exemplo Exemplo de Aplicação: Sistema Sistema de Vendas de Loja
Este exemplo exemplo retom r etomaa o sistema sistema de vendas da loja l oja descri d escrito to no capítulo capítulo an a nterior, para introduzir a formalidade do modelo de contexto e dos diagramas de casos de uso.
3.4.1.
Descrição Descrição de Subsistemas Subsistemas
Em uma loja qualquer, o sistema de vendas deve estar integrado a outros sistemas de informação internos, importantes para o gerenciamento do empreendimento. Pode-se represent repres entar ar cada sistema sistema de inform informação ação como como um subsistema subsistema da loja, loja , caracterizado car acterizado por um pacote, como exemplifica a figura. Na figura mostra que o subsistema de vendas é dependente dependente do sistema sistema de cadastro c adastro do cliente c liente e do sistem si stemaa de estoqu e stoque, e, que poderia ser o responsável por manter uma lista de produtos. A dependência entre estes subsistemas fica clara em um diagrama de pacotes.
Figura 34 - Subsistemas relacionados rel acionados ao sistema da loja Neste exem exemplo, plo, explora-se explora-s e apenas um uma pequena pequena parte do subsistema subsistema de vendas. Da descrição do sistema, elaborada no capítulo anterior, pode-se extrair que:
O caixa faz a venda em um terminal (POS) (POS) O caixa le o código do produto O caixa identifica o cliente pelo CGC CGC O caixa verifica o parcelamento Vemos emos que o ator do sistema s istema é o caixa, e que ele vem ve m ao sistem si stemaa com tres objetivos, ident i dentificados ificados nos três casos c asos de uso da figura figura abaixo, a saber: saber : Identificar Identificar produto, produto, Identificar Identificar client clie ntee e Autorizar Autorizar o parcelamento. parcelamento.
Figura 35 - Diagrama de Casos de Uso dos dos Processos de Venda
3.4.2.
Descrição Descrição dos Casos de Uso
Segue uma descrição textual dos casos de uso identificados acima.
Identi Ident ificar Client Clientee O caixa recebe rece be o número úmero do d o CGC do client cli ente. e. Caso o client clie ntee estiver es tiver present pr esentee no cadastro da loja, verifica-se verifica- se os dados do client clie ntee como nom nomee e o seu crédito. Um Um clien clie nte especial especi al pode ter o dobro do crédito crédi to do client clie ntee comum comum.
Identifi Identificar car Produto O caixa deve ler l er o código no produto, produto, em um leitor de código de barras, barr as, ou deve teclar o código. cód igo. A loja é responsável r esponsável por manter anter uma uma lista li sta de seus produtos, produtos, com os dados de nome e preço, entre outras informações sobre o produto. Com o código identificado, o caixa recebe os dados do produto.
Autoriz Autorizar parce p arcellamento amen to O caixa de posse dos dados do produto e de um cliente, pode verificar se o cliente pode fazer fazer a compra parcelada. parcelada . A venda venda será reali r ealizada zada se a dívida do client cl iente, e, na compra compra parcelada, parce lada, for menor menor do que que o crédito crédi to que que o client clie ntee possui com a loja. loja . O sistema sistema de vendas v endas deve aprovar apro var a venda ou não. não. Este modelo poderia ser enviado para o cliente, irir analisar a especificação e assegurar assegurar que o software, quando desenvolvido corresponde cor responde às suas expectativas. expectativas. Esta é a finalidade do modelo de contexto.
4. Modelo Conce Conceitual itual Este capítulo capít ulo apresenta uma técnica para se desenvolver dese nvolver um modelo conceitual do projeto de software. O objetivo aqui é identificar i dentificar os principais conceitos presentes em um problema e representá-los em classes, dando os primeiros assos na direção da construção de um modelo orientado a objetos do problema. ste objetivo obje tivo é conseguido consegui do utilizando utili zando a técnica dos cartões CRC. Originalmente criada para ensinar orientação a objetos, esta técnica é aplicada aqui como uma orma de transformar os requisitos levantados no modelo de contexto nas classes do modelo conceitual.
4.1.
Introdu Introdução ção ao Modelo Conceitual
Este capítulo descreve o processo proce sso de criação criaç ão de um modelo conceitual conceitual de um sistema de software. Este modelo é obtido a partir dos requisitos levantados pelo modelo de contexto. O analista deve se posicionar suficientemente próximo do sistema para extrair dos requisitos requisi tos do problema problema os conceitos principais, sobre s obre os quais será ser á construída construída a solução. Esta aproxim a proximação ação gradativa do sistem s istema, a, que esta abordagem de modelagem recomenda, evita a sobrecarga de complexidade no modelo nas fases iniciais do processo proc esso de desenvolvim des envolviment ento, o, facilita facili ta o entendim entendiment entoo do problem proble ma e aux auxili iliaa no desenvolvimento do sistema de software. Enquanto Enquanto o model modeloo de contexto contexto descrev desc reve, e, funcionalmen funcionalmente, te, o sistem si stemaa sob o pont po ntoo de vista do usuário usuário externo, externo, o modelo modelo conceitual conceitual dá as primeiras noções de d e como será o interior do sistema. No modelo conceitual são esboçadas as idéias principais que compõem o núcleo do sistema, descrevendo-o de dentro pra fora. A modelagem conceitual conceitual se s e encontra encontra entre entre as a s práticas pr áticas propostas pr opostas por Larman arman (1997) em e m seu livro livr o sobre a aplicaçã apl icaçãoo da UML. ML. Neste trabalho, o modelo conceitual conceitual é definido como a represent repres entação ação de conceitos ou objetos do domínio domínio do problema. A estratégia estratégia recomendada recomendada é de se criar cri ar um rascunho rascunho do diagrama diagrama de classes, cla sses, onde a ênfase ênfase está em descobrir descobri r os requisitos mais evident evide ntes, es, antes de lançar l ançar mão mão de uma uma in i nvestigação aprofundada. Mais tarde nos ciclos seguintes do desenvolvimento, o modelo conceitual poderá ser se r refinado, incremen incrementalm talment ente, e, e estendido para considerar os dem de mais requisitos. O modelo conceitual está também presente em métodos incrementais de desenvolviment desenvolvimentoo de sistemas. sistemas. As primeiras fases do processo pro cesso criam cria m uma uma visão vi são da arquitetura completa do sistema. Uma arquitetura que, nas fases seguintes, orienta a produção de versões do sistem s istema. a. Assim, Assim, cada versão versã o chega, chega, increment incrementalm alment ente, e, mais mais próxima próxima da visão da arquitetura arquitetura completa. completa. O modelo conceitual captura os conceitos do sistema em um diagrama de classes. O diagrama de classes é a representação fundamental da modelagem orientada a objetos, e evolui de uma visão conceitual para uma visão detalhada, com o desenvolvimento do sistema. No modelo conceitual de classes é possível descrever os elementos principais de um sistema, sistema, suas características carac terísticas individuais e com co mo eles ele s se relacionam relac ionam.. A identificação de classes e das suas inter-relações é uma das etapas mais complexas complexas da anális análisee orientada a objetos. Para sistematiz sistematizar ar esta busca, busca, apresenta-se a técnica dos cartões car tões CRC. Esta técnica é um um método eficaz para se fazer a transição do modelo de contexto para o modelo conceitual. Proposta por Beck e Cunningham (Beck,
1989), o uso dos cartões CRC facilita a aplicação do paradigma de objetos na análise de um problema de software, e incentiva o envolvimento de usuários nas fases iniciais da análise. No final final deste capítulo, capítulo, desenvolve-se desenvolve-s e o modelo modelo conceitual conceitual do conhecido conhecido ogo da forca, um dos casos estudados neste trabalho. Este exemplo é retomado no capítulo 6 e tem o seu código construído na linguagem Java no apêndice.
4.2.
Diagrama de Classes Class es
Para se construir algo seguro é importante se ter uma base sólida. Uma afirmação verdadeira tanto para uma construção civil, como, por exemplo, na construção de um sistema de software. Para se obter um sistema de software confiável é necessário criar, inicialmente, uma estrutura sólida e estável. Sobre esta estrutura são armazenadas as informações do sistema, e são desenvolvidos os processos necessários para a solução do problema em questão. A estrutura de um sistema de software é formada pelas classes do sistema. Analogamente ao esqueleto dos animais, as classes formam uma armação que dá a forma ao sistema. As qualidades de um sistema são garantidas por um conjunto de conceitos fundamentais, bem definidos, capturados nas classes e que acompanharão o sistema da concepção à implementação. Classes são matrizes de objetos, elas e las identificam identificam grupos grupos de elementos elementos do sistema sistema que compartilham compartilham as mesmas mesmas proprieda pr opriedades. des. A diferen di ferença ça entre classes clas ses e objetos obj etos já foi assunto assunto do capítulo 2, mas mas aqui esta diferen di ferença ça é revista revis ta à luz da anális análisee de requisitos. r equisitos. Os objetos são sã o os elem el ement entos os concretos envolvidos nas transações dos sistemas, sistemas, criados cr iados a partir das definições abstratas das classes. Os objetos são instâncias das classes. Freqüentemente, a descrição de um sistema descreve um caso, uma situação em particular onde o personagem personagem é o objeto. Na representação, usa-se usa-se escrever e screver os nomes nomes dos os objetos por letras minúsculas e das classes por letras maiúsculas. As classes representam um conceito importante para o problema em questão. Enquanto uma classe descreve um conceito abstrato do domínio do problema, um objeto repres rep resenta enta um um elem ele mento deste conceito, concei to, que é utili utilizado zado no no sistem sis tema, a, de modo modo concreto. concre to. Ao criar cria r um objeto, com base em um uma classe, cl asse, ele assume assume valores val ores para os atribut atri butos, os, definindo um estado e herda um comportamento das classes que permite alterar este estado. Os estados e os comportam comportament entos os são s ão compartilhados compartilhados por po r todos os o s objetos obj etos da mesma esma classe, cla sse, e são definidos na fase de análise. análise . A UML incorporou a representação de classes utilizada na OMT de Rumbaugh (Rumbaugh et al., 1994) com pequenas alterações na notação. As classes são identificadas por retângulos divididos horizontalmente em tres porções, como mostra a figura. figura. No terço superior encontra-se encontra-se o nome nome da classe, class e, no terço médio a lista l ista de atributos e no terço inferior a lista de operações que esta classe pode realizar. Apesar desta ser a forma forma básica bási ca de represent repres entação, ação, existem form formas as altern al ternativas ativas que variam var iam de acordo com o interesse de representação e a precisão desejadas.
Figura 36 - Representação típica típi ca de uma classe A figura figura abaixo mostra mostra algum algumas alternativas alternativas de represe r epresenntação da classe class e Loja do problem proble ma do capítulo 2. Na figu figura ra a classe cla sse Loja possui desde uma uma represent repres entação ação simplificada até uma uma representação re presentação bem detalhada, detalhada, onde os atribut a tributos os e as operações ope rações são descritos com grande precisão e adornados por símbolos que irão definir a sua visibilidade, valor inicial e tipologia. Para efeito do modelo conceitual iremos adotar a represent repres entação ação (a ) ou (b), deixan de ixando do a notação (c) para o modelo detalh de talhado, ado, que é o assunto do capítulo seguinte.
(a)
(b)
(c)
Figura 37 - Formas Formas alternativas alte rnativas de se representar represent ar uma classe Os atributos das classes formam uma estrutura que permite o armazenamento de inform informação. ação. Podemos ter objetos obje tos encapsulados encapsulados nos atributos atributos das classes, class es, com a sua própria própri a estrutu estrutura de atributos, e a sua sua própria própri a capacidade capaci dade de armazenam armazenament entoo de informações. As operações operaçõe s são as mensagen mensagenss que a classe cl asse pode p ode receber, rec eber, e que definem 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 são trocadas. Uma classe isolada é, essencialmente, um depósito de informações nos seus atributos e oferece ao sistema um conjunto de funcionalidades definidas pelas suas operações. Para fazer uso destas potencialidades as classes precisam se relacionar.
No exem exemplo plo da loja, lo ja, do capítu capí tulo lo 2, foram identificados identificados os conceitos c onceitos de Produto, Cliente, ClienteVIP e Loja. Cada um com suas propriedades como o Nome do Cliente, o Código do Produto, etc. O trompete que possui o código 107 é um objeto da classe Produto. Charlie Parker Par ker é o nome nome de um objeto da classe class e Cliente , Charli Charliee Mingus é o nome de outro objeto da classe ClienteVIP. Como é um ClienteVIP possuirá um comportam comportament entoo de crédito crédi to diferente diferente do Cliente, que permite parcelar as compras de maior valor. O exemplo mostra que os conceitos, atributos e comportamentos são 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 definição uma lista de objetos objetos da classe cl asse Cliente (listaClientes ) e uma lista de objetos da classe Produto exemplo plo mostra mostra como como os conceitos podem se relacionar rel acionar para criar cr iar (listaProduto ). Este exem conceitos mais complexos.
4.2.1.
Relacionamento Relacionamento entre as classes classes
Sistemas Sistemas orient or ientados ados a objetos são sã o formados formados por p or conjuntos conjuntos de classes. cl asses. Uma classe cl asse não pode atender isoladamente todas as necessidades do problema, e por isso ela se integra às outras, para juntas apresentarem uma solução ao problema. Em conjunto, as classes class es trocam mensag mensagens ens para realizar reali zar os objetivos do sistem s istema. a. O relaci r elacionam onament entoo entre as classes cl asses serve de caminho caminho para esta troca de mensagens, ensagens, permitindo permitindo que que as classes class es se “conheçam”, e criando um caminho que possibilita a comunicação. As classes podem se relacionar de modos que variam de acordo com as afinidades existentes existentes entre entre as classes. cl asses. Os relacionam rel acionament entos os podem pode m ser fracos, indicando que as classes não possuem uma grande afinidade, ou fortes atestando uma grande interdependência interdependência entre entre elas. el as. Seguindo Seguindo esta escala, escal a, podemos classificar classi ficar os relacionamentos como: Dependência Dependência (m ( mais fraco) Associação Agregação Herança (mais forte)
4.2.2.
Dependência
O relacionamento mais fraco é a dependência. Representada por uma uma seta tracejada trace jada ligando as classes, a dependência parte da classe dependente e aponta para a classe independent independente. e. Na figura figura abaixo, a baixo, a classe cl asse A depende da classe cl asse B, o que quer dizer que, de alguma forma, não especificada pela relação, os atributos ou as operações da classe A dependem da classe clas se B. A dependência dependência não indica como ocorre esta dependência, dependência, mas serve para indicar que estas classes devem participar juntas do sistema.
Figura 38 - Exemplo de dependência: A depende de B
No exem exemplo plo da loja lo ja do capítu capí tulo lo 2, podemos podemos dizer que a classe Loja depende das classes Produto e Cliente . Esta dependência dependência é represent repres entada ada pelas pel as setas se tas que ligam estas classes class es na figura figura abaixo. a baixo. A dependência dependência pode evoluir, evol uir, em um uma fase posterior po sterior da modelagem, para outro tipo de relacionamento que defina melhor a afinidade entre as classes.
Figura 39 - Exemplo de dependência entre as classes. classe s. A dependência é um relacionamento comum entre os pacotes. Ela representa o fato de que existe algum tipo de relacionamento entre as classes que compõem os pacotes e, conseqüentemente, os pacotes estão também relacionados. Como o relacionamento entre entre os o s pacotes não está es tá claram clara mente ente determinado determinado porque depende das classes class es que eles el es contém contém,, usa-se represent repres entá-lo á-lo pela dependência. dependência.
Figura 40 - Exemplo entre dependência entre os pacotes pacote s
4.2.3.
Associação
As associações aparecem quando há um nível maiorde envolvimento, e mais bem definido do que na dependência, entre as classes. Na associação as classes estão ligadas semanticamente umas às outra. Ou seja, as classes mantém-se independentes, mas guardam uma algum tipo de significado na sua relação. Esta relação já permite a troca de mensagens entre as classes na ajuda para o cumprimento de suas responsabilidades. Na figura abaixo a classe R está está associada à classe S. A classe R pode chamar chamar as operações oper ações de S por intem intemédio édio do objeto obje to varS que é um objeto da classe c lasse repre sentaa a associ a ssociação. ação. A represent repr esentação ação da associação associ ação é uma uma linh li nhaa que S, e que represent interli interliga ga as classes. clas ses. Esta linh l inhaa pode possuir p ossuir uma uma seta indicando a direção di reção da da associação. associ ação. Outros Outros adornos a dornos das associações ass ociações serão vistos mais à frente frente no texto. texto.
Figura 41 - Exemplo de associação entre as classes class es Deve-se observar que um uma associaçã ass ociaçãoo sign si gnifica ifica que existe um objeto do tipo da classe associada na classe de origem. Assim o objeto varS, que é do tipo S, está presente na na classe clas se R através através da associação. ass ociação. Estando Estando present pres ente, e, R pode se s e comunicar comunicar com S através de varS.
4.2.4.
Agregação
Alguns tipos de associação podem exigir um aumento no grau de envolvimento entre as classes o que cria a agregação. A agregação é equivalente à associação mas indica que as classes cl asses possuem uma uma dependên depe ndência cia existencial, existencial, isto é, uma classe cl asse só existe em conjunt conjuntoo com as suas agregadas. agregadas. A classe cl asse todo é composta composta pela(s) pela( s) classe( cl asse(s) s) parte. par te. Na figura figura abaixo a classe cla sse X é composta pela classe Y, o que quer dizer que a classe X possui um um objeto da classe clas se Y, identificado por varY, que também é o nome da relação. A agregação é representada por uma seta unindo as classes com um losango indicando a classe todo.
Figura 42 - Exemplo de agregação No exem exemplo plo da loja lo ja apresent apre sentado ado no capítulo capítulo 2 a classe cla sse POS possui um objeto da classe Produto chamado de oProduto e um objeto da classe cl asse Cliente chamado re presentam o produto que que será ser á vendido e o client cli entee interessado oCliente . Estes objeto representam em comprá-lo. O POS os utiliza utiliza para o processam processa mento ento das ações de venda. Estes objetos foram criados e transmitidos transmitidos ao a o POS pela classe Loja, mas fazem parte par te da classe POS e por isso são representados r epresentados como como uma uma agregação onde o todo é o POS e as partes são oProduto e oCliente . Supondo, por hipótese, que o POS venha a ser desligado, os objetos da venda que não foi ainda concluída serão perdidos. Assim também a lista de clientes e a lista de produtos fazem parte da Loja. Supondo que a loja seja vendida, o novo dono dono recebe rec ebe também também a lista li sta de client cl ientes es e a lista li sta de produ prod utos, eles são indissociávei i ndissociáveis. s. No exemplo, exemplo, as listas de client cli entes es e de produtos são fortement fortementee dependentes da Loja. Sendo este o fator determinante na decisão na modelagem deste relaci rel acionam onamento ento como uma uma agregação. a gregação.
Figura 43 - Exemplo de Associação Associação entre entr e Classes Pode-se considerar a agregação como como um caso especial es pecial da associação, ass ociação, onde há há um vínculo vínculo maior entre entre as classes. class es. Este vínculo pode crescer cres cer a ponto ponto de uma uma classe cl asse depender existencial existencialm mente ente da outra. outra. O que sig si gnifica nifica dizer que se a classe class e todo deix dei xar de de existir, as classes partes deixam também de fazer sentido para o sistema. Na associação, associ ação, as classes class es se mantem antem independent independentes, es, isto i sto é, elas podem participa participarr de outras outras associações associ ações no projeto onde não não haja esta depedência depedê ncia e podem ser instanciadas instanciadas isoladamente.
4.2.5.
Herança
Um tipo de relacionamento importante para o desenvolvimento de sistemas orientados a objeto é a herança. O conceito de herança também foi apresentado no capítulo 2 e se caracteriza por criar uma hierarquia entre as classes do sistema. Nesta hierarquia, algum algumas classes, cl asses, chamadas chamadas de superclasses, superclasses , servem serve m de matriz matriz para a criação criaç ão de outras classes, as subclasses, que especializam as superclasses originais. Constrói-se uma hierarquia de generalização-especialização indo de superclasses mais gerais para subclasses mais específicas. Ao se especificarem, as subclasses aproveitam tudo o que já foi definido pelas superclasses pela herança. As subclasses herdam atributos, atributos, operações ope rações e relaci r elacionam onament entos os da d a classe cl asse mãe, mas podem modificar modificar o material herdado, sobrescrevendo sobresc revendo os atributos e operações opera ções ou criando cri ando novos novos atributos ou operações. A herança é representada por uma linha unindo as classes com um triângulo indicando a superclasse. No exemplo da loja do capítulo 2 a classe Cliente é superclasse superclasse para a classe cl asse ClienteVIP, com co mo mostra a figura. figura.
Figura 44- Classes Cliente Clie nte e ClienteVIP Client eVIP com operações operações e atributos atr ibutos A classe ClienteVIP herda da classe Cliente todos os atribut a tributos os e todas as operações como a setCGC, getNome entre outras. Entretanto, a classe ClienteVIP modifica a classe Cliente alterando al terando a operação oper ação getCredito. getCredito. Conform Conformee as regras no negócio neg ócio o crédito crédi to do ClienteVIP possui o dobro do crédito do Cliente. A figura mostra as classe com as operações sobrescritas e a tabela mostra a diferença entre a implem implement entação ação das duas operações. operaçõ es.
A implement implementação ação das operações getCredito() getCredito() apresentadas acim ac imaa foram foram escritas na linguagem Java, e retornam um valor inteiro referente ao crédito do cliente, armazenado no atributo credito. A referência à super.getCredito() na implementação da classe ClienteVIP indica que será usada a operação getCredito() da superclasse Cliente , que é multiplicado por dois, como manda a regra de negócio.
Operação getCredito do Operação getCredito do [4] Cliente ClienteVIP
public int getCredito() getCredito() { return(credito); }
public int getCredito getCredito () { return (2*super.getCredito()); }
A herança é uma forma eficiente de distribuição de funcionalidades. As subclasses dispõem de todas todas as fun funcionalidades cionalidades que as superclasses oferecem. Assim a criação de um modelo orientado o rientado a objetos é um processo process o de classi c lassificação, ficação, busca-se criar uma hierarquia de classes class es que compartilhem compartilhem as operações umas das outras. outras. No exem exemplo, plo, é importante importante notar notar que que uma uma classe class e ClienteVIP é também 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 definição definição das classes class es foi feita quando quando do carregam car regament entoo das classe c lassess ao iniciar o sistem sis tema. a.
4.3.
A técnica dos cartões CRC
Uma das maiores dificuldades enfrentadas por quem está iniciando na técnica da orientação a objetos obj etos é encontrar encontrar as classes. cl asses. É desejado desej ado sem se mpre manter anter uma uma boa correspondência entre o modelo conceitual e o domínio do problema, e também uma grande estabilidade dos conceitos expressos pelas classes. No entanto, as classes são conceitos abstratos e as vezes de difícil compreensão por parte da equipe de projeto, ainda mais mais por parte par te de client cl ientes es que por algum alguma razão devem dev em estar envolvidos nesta 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 fundam fundament entais ais do sistem si stemaa capturados pelas pel as classe c lasses, s, mas mas o trabalho ainda assim assi m não é dos mais simples. A proposta da técnica técnica dos cartões CRC é tornar tornar o conceito abstrato abstrato das classes em em algo concreto e manipu manipulável lável pelos analistas, tornar a identificação identificação das classes cl asses um processo process o interativo interativo com a participação participa ção efetiva dos usuários. usuários. A idéia, proposta pr oposta por Beck e Cunnigham (1989), utiliza cartões de papel, muito utilizados em bibliotecas, para representar re presentar as classes classe s e organizar organizar um um trabalho em equipe para identificar e descrever as classes de um sistema.
A modelagem CRC CRC é uma uma técnica muito efetiv ef etivaa para identificar identifi car e validar vali dar os requisitos dos usuários. Ele pode ir de mão em mão como os use case e os protótipos, e conduz diretamente ao modelo de classes. O objetivo do desenvolvimento de aplicações é resolver problemas de negócio, e não satizfazer a curiosidade intelectual dos desenvolvedores que só querem brincar com novos brinquedos. Trabalhe com os seus usuários, e não contra eles (Scott Ambler, 1998)
Figura 45- Exemplo de Cartão Cartão CRC
4.3.1.
Históri Histórico co do cartão CRC
Os cartões ca rtões CRC foram introduzidos introduzidos por Kent Beck e Ward Cun Cunnin ningh gham am em 1989 na [5] OOPSLA . A técnica atraiu a atenção da comunidade por ser uma técnica de fácil aplicação para um problema difícil, que é o de descobrir e definir classes. No livro Rebecca Wirfs-Brock (1991) detalhou o processo proc esso dos cartões ca rtões que se tornou tornou conh conhecido como como a técnica de projeto pr ojeto “por responsabilidades”. responsabili dades”. Nancy Wilkinson Wilkinson (1995) publicou sobre suas experiências com CRC na na AT&T. Bellin (1997) oferece uma uma visão vi são abrangente da técnica e da sua aplicação. Mais recentemente Kent Beck (1999) referese novament novamentee à tecnica tecnica dos cartões ca rtões CRC nas nas fases de modelagem modelagem da aplicação aplica ção do seu método XP (eXtreme Programming ) de desenvolviment desenvolvimentoo rápido. ráp ido. [6]
A palavra CRC é uma abreviação para :Classe, Responsabilidade e Colaboração, conceitos básicos da modelagem modelagem orientada a objetos. obje tos. Os cartões de CRC são cartões de índice muit muitoo utili utilizados zados em arquivos e bibliotecas, bibli otecas, que são utili utilizados zados para registrar r egistrar as classes sugeridas, as coisas que elas fazem, e as relações com as outras classes. Enquanto se escreve o nome da classe, pode-se pensar no que aquela classe deve saber de si mesma esma (responsabili (r esponsabilidade dade de conh conhecimen ecimento) to) e o que ela deve saber sab er 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 idéia de encapsulamen encapsulamento to e polimorf po limorfismo ismo são reforçadas, r eforçadas, ao a o se mover uma responsabili r esponsabilidade dade de de uma uma classe cl asse para pa ra outra e criar cri ar uma uma colaboração. col aboração. Os cartões foram criados para pa ra dar uma uma resposta res posta à necessidade necessida de de docum d ocument entar ar as decisões do projeto colaborativo. Projetar com cartões tende a progredir a modelagem do conhecido conhecido em direção direç ão ao desconhecido, desconhecido, em oposição à abordagem top-down de decomposição decomposição usada na análise funcion funcional. al. Os cartões car tões de CRC representam expícitamente múltiplos objetos ao mesmo tempo. Entretanto, ao contrário de simplesmente acompanhar os detalhes da colaboração na forma de envio de mensagens, os cartões CRC colocam o projetista no foco da motivação motivação para colaboração col aboração repres rep resentan entando, do, potenciamente, potenciamente, muitas muitas mensagens ensagens com frases frase s em linguagem linguagem natural. natural. (Beck e Cunningham, 1989) A naturez naturezaa visual vi sual dos cartões de CRC é um um importan importante te catalisador catalisad or para par a a solução do problem proble ma. Ao mover mover um cartão sobre a mesa pode-se obter novas idéias da equipe de projeto. Talvez mais mais im i mportante portante que as tarefas tarefas básicas, básic as, os cartões car tões ajudam na solução solução dos problemas porque favorecem o trabalho trabal ho em equipe.
4.3.2.
Vantagens do trabalho trabalho em equipe equipe
Necessitamos Necessitamos de uma uma ferrament ferramentaa que nos nos ajude a resolver resolv er problem probl emas. as. Um Um resolvedor de problemas trabalha com alternativas, se uma delas é escolhida é porque um número maior de associações lógicas levaram a esta escolha. Quando um grupo de pessoas estão e stão tentan tentando do resolver resol ver um problem proble ma, eles estão es tão engajados engajados em um processo process o que leva a uma associação lógica. As ferramentas que suportam e facilitam este tipo de solução de problem pr oblemas as são sã o valiosas. vali osas. A ferramenta ferramenta é projetada proj etada para ser s er um catalizador de novas idéias, idéi as, a equipe deve ser se r ao mesmo esmo tempo tempo pacient paci entee e aberta a berta a novas idéias. idé ias. Se a técnica for usada somente como um meio para anotar as idéias velhas, a chance de um insight, de uma nova idéia está drasticamente reduzida. Quanto mais se entende como trabalhar em equipe, mais chance de se ter de um sucesso na solução. Estudos mostram que um grupo terá mais chance de sucesso na solução de um problem proble ma se este grupo grupo for treinado treinado na lógica lógica de solução so lução do problema antes antes de ser apresen aprese ntado ao problem probl ema. a. As pessoas pess oas que estão concientes concientes sobre sob re a sua estratégia estratégia de solução de problemas vão melhores do que aquelas que dependem de uma resposta insconsciente insconsciente ou da sorte. Isso sign s ignifica ifica que o grande grande poder do uso dos cartões CRC está na equipe de desenvolvedores d esenvolvedores que não não somente somente sabe o que eles deve fazer, mas mas tambem sabem como resolver problemas complexos. Por isso, recomenda-se uma abordagem de aplicaçã apl icaçãoo da técnica técnica dos cartões ca rtões CRC que envolvem envolvem duas duas estat es tatégias égias para facilitar a solução de problemas: brainstorm e interpretação. ( role play).
4.3.3.
Objetivos Objetivos dos cartões cartõe s CRC
A técnica técnica dos cartões car tões CRC tem tem como como prin pri ncipal objetivo o de facilitar facili tar o trabalho de indentificação indentificação das classes de um sistema sistema e das suas suas inter inter relações rela ções principais. principais . Ao mesmo tempo, a técnica serve como meio para o aprendizado da prática da modelagem orientada a objetos obje tos e para o ensino dos conceitos envolvidos. Sendo uma uma técnica de fácil utilização, ela incentiva incentiva o envolvimento envolvimento dos usuários usuários no processo de análise e projeto dos sistem si stemas. as. Os fundamentos da técnica dos cartões CRC são os mesmos fundamentos da orientação a objetos, e serão revisados aqui. Considera-se que os sistemas sejam formados formados por objetos, categorizados em classes. As classes clas ses encapsu e ncapsulam lam atributos atributos e operações operaçõe s que caracterizam caracteri zam responsabilidades responsabili dades que os objetos devem execut executar ar para par a o sistema. A análise orientada a objetos deve identificar estas classes e distribuir entre elas as responsabilida re sponsabilidades des ident i dentificadas ificadas no levantam levantament entoo de requisitos r equisitos do sistem si stema. a. Para cumprir cumprir integralm integralment entee as suas responsabilidades, responsabil idades, as classes class es podem p odem contar contar com a ajuda aj uda de outras classes. A técnica técnica dos cartões car tões CRC procura responder às à s pergu per gunntas: Quais são os componen Quais componentes tes (Classes) (Class es) do sistem si stemaa ? O que que cada um deles deve fazer (Responsabilidades) (Responsabili dades) ? Como eles trabalham em conjunto (Colaboração) ? As respostas à estas perguntas são registradas em um cartão como na figura:
Figura 46 - Estrutura de um cartão 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 missão no sistema. Cada classe é representada por uma cartão CRC, com o nome da classe ocupando a linha de topo do cartão. Parte-se de requisitos do sistema, previam previa mente ente levantados, que que são transform transformados ados em responsabilidades responsabili dades nas classes. class es. As responsabilidades são listadas à esquerda do cartão, e eventuais colaborações de outras classes para aquela responsabilidade à direita. Ao mesmo tempo que é um modo eficaz para se anotar informação sobre classes, os cartões CRC criam cri am um motivo para as pessoas pes soas envolvidas com c om o problem prob lemaa se agruparem para trocar idéias. É uma técnica infomal que reduz o conflito e amplia a socialização no desenvolvimento de software. Um dos elementos fundamentais para o sucesso de projeto pr ojeto de software é o trabalho trabal ho em equipe e o aprendiz ap rendizado ado ativo. Ao contrário de ler um relatório de outra pessoa, uma equipe de CRC está sempre fazendo algo que contribui contribui para par a o modelo do sistem si stema, a, isto i sto é, eles el es estão e stão sempre sempre aprendendo aprendendo algum alguma coisa. coi sa. (Bellin, ( Bellin, 1997)
4.3.4. 4.3 .4.
Organização Organização para aplica aplicação ção da técnica
Baseado em Bellin (1997) propõe-se uma organização para aplicação da técnica, apresen aprese ntada aqui para ser aplicada apli cada após ap ós a modelagem de contexto contexto em um processo process o de desenvolvimento de um sistema. O método é organizado nas seguintes etapas: 1.
Formação Formação da equipe de trabalho,
2.
Uso de brainstorm para descrição dos requisitos do sistema,
3.
Identificar Identificar classes class es candidatas,
4.
Analis An alisar ar os requisitos
5.
a.
Identificar Identificar e Distribuir as responsabilidades, responsabili dades,
b.
Caracterizar os colaboradores colab oradores,, e
c.
Simular Simular a dinâmica dinâmica do cenário, validando valida ndo o modelo.
Tradução dos cartões em modelo conceitual conceitual de classes class es
Figura 47 - Esquema da aplicação da técnica de CRC
4.3.5.
Formação da equipe equipe de trabalho trabalho
Uma das principais vantagens do uso dos cartões CRC é a integração dos usuários no processo de modelagem do software. Para explorarmos esta possibilidade é necessário criar uma equipe de trabalho composta composta de analistas a nalistas e usuários. Uma Uma boa proporção proporçã o é a de um analista ou desenvolvedor para par a cada usuário usuário especial es pecialistas istas no problem proble ma em estudo. estudo. É importan importante te mant manter er pequena pequena a equipe pequena, pequena, entre entre 5 a 6 pessoas, pessoas , o que que leva a se compor compor a equipe com 2 a 3 analistas e 2 a 3 usuários usuários.. Um Um analista deve fazer o papel de facilitador e atuar como coordenador dos trabalhos, cuidar da agenda e da in i nfra-estrutura fra-estrutura para apoiar apoi ar a reunião reunião de trabalho. Entre os analistas deve haver pelo menos um especialista em modelagem orientada a objetos, que deve orient or ientar ar os questionam questionament entos os e tomar tomar as decisões decisõe s relativas rel ativas à represent repres entação ação das da s classes cl asses.. Alguem Alguem deve, durant durantee a reunião, reunião, assumir assumir o papel de secretário da reunião e fazer os registros necessários. O quadro abaixo pode ajudar na formação das equipes de modelagem.
Reunião CRC Projeto:_______________ Usuário Usuário Usuário Usuário Analista Analista Anali Local:_________________ 1 2 3 4 1 2 3 Data:____/ ____/ _____ Especialista do Problema Especialista Especial ista em Objetos Objetos Coordenação Facilitador Secretário Agenda Material de Apoio Coffe break Outros As reuniões devem ter uma agenda definida com antecedência, e devem ser precedidas precedi das sempre com um breve revisão re visão da figura figura do cartão e da técnica que que se está aplicando, esta introdução visa garantir que todos tenham um entendimento, ao menos
superficial, sobre sobr e o método. método. Os cartões devem ser sempre sempre escritos escr itos utilizan utilizando do a terminolog terminologia ia do usuário. Para Par a explicar explica r termos técnicos técnicos e pouco com co mun unss pode-se pode -se criar cria r um glossário de termos que será útil para os desenvolvedores terem uma melhor compreensão compreensão do significado significado dos cartões. Durantee as reuniões Durant reuniões deve-se manter anter baixo ba ixo o nível tecnológico, isto é, deve-se evitar o uso de comput computadores adores e prog pro gramas ramas de modelagem. odelagem. Com eles corre-se corre- se o risco risc o de aumentar a distância entre os usuários, que não tem familiaridade com estes meios, e os analistas. Entretant Entretanto, o, o uso de protótipos e rascun r ascunhos hos de telas e relatórios re latórios podem ajudar ajudar a mostrar para os usuários as possibilidades de implementação dos cartões. Na maioria dos casos ca sos uma uma única reun r eunião ião não será suf s uficie icient nte, e, o qu q ue dá a oportunidade oportunidade para a preparação prepar ação do material material nos espaços de d e tempo tempo entre entre os encontros. encontros. Se não houverem houverem reuniões produtivas o desenvolvimento pode tornar-se demasiadamente lento. Portanto, para ter uma uma reunião reunião mais mais din di nâmica âmica e produ prod utiva: Organize os cartões e os protótipos entre uma reunião e outra, Inicie Inicie a reunião revisando revi sando o que foi obtido na reunião reunião anterior anterior,, Encerre a reunião resumindo o que foi discutido até aquele ponto, Ao final, agende uma nova reunião, se necessário. Divulgu Divulgue os resultados da reun r eunião ião o mais rápido possível. possíve l.
4.3.6.
Brainstorm Brainstorm para especi espec ificação ficação do sistema sistema
uma estratégia utili utilizada zada para levant l evantar ar os requisitos de projeto p rojeto em O brainstorm é uma um trabaho em equipe, que tem sido usada em várias equipes de trabalho, desde equipes de publicidade até grupos grupos de teatro. teatro. Quando Quando uma uma equipe de analistas se propõe a trabalhar em um sistema, a troca de idéias de um modo rápido e desinibido, como deve ser no brainstorm, pode levar a um resultado melhor melhor do que o trabalho individual. (Bellin; Simone, 1997) O modelo modelo de context contextoo oferece uma uma descrição descr ição dos objetivos obj etivos dos casos de uso para dar a partida para a modelagem conceitual. Mesmo quando não existe material para dar início à modelagem pode-se utili utilizar zar do brainstorm com a equipe de projeto para detalhar a descriçã des criçãoo funcion funcional al do sistema. sistema. O brainstorm é uma técnica útil até mesmo para a elaboraçã el aboraçãoo do próprio própri o modelo modelo de contexto. contexto. Uma reunião para modelagem do sistema se inicia com uma descrição deste sistema. Esta descrição descri ção pode pod e partir par tir da leitura do modelo de context contexto, o, ou na inexistência inexistência deste, do material disponível sobre o problema. Na reunião de trabalho a participação de todos deve ser se r estimulada. estimulada. O objetivo obj etivo desta etapa do trabalho é levantar as funcion funcionalida alidades des que o sistema sistema deve possuir para pa ra atender os seus usuários usuários.. A experiência dos especial es pecialistas istas é importan importante te pois é deles o conh conhecimen ecimento to das necessidades reais a serem atendidas. É importante um papel de questionamento, por parte dos analistas, para obter um modelo completo e preciso. A palavra, palavra , em uma uma reunião reunião de análise, análise , deve ser dada a todos. Pode-se registrar tudo em um gravador, ravador , mas mas como como a transcrição deste material material é difícil, difíci l, é preferível registrar a reun r eunião, ião, diretam di retament ente, e, em papel. No decorrer do brainstorm se contrói uma descrição do sistema na forma de uma lista lis ta organiz organizada ada de requisitos. O produto produto final final da etapa do brainstorm é esta descrição refinada pela análise, discussão e ponderação da equipe de projeto. O papel do facilitador e do secretário são essenciais na elaboração da lista de requisitos, quando algun alguns dos requisitos listados li stados podem ser retirados, retirado s, assim assi m como como novos requisitos podem ser incluídos.
4.3.7.
Identifi Identificar car as classes classes candidatas
De posse da lista de requisitos obtidas pelo brainstorm, e da descrição dos casos de uso do modelo de contexto é possível iniciar a procura pelas classes. As classes definem definem um um nível de abstração abs tração do problema. Como Como reg re gra geral, as classes cl asses aparecem aparece m como como sujeitos nas ações listadas nos requisitos. re quisitos. Analis Analisando, ando, por exemplo, exemplo, os requisitos abaixo:
O cliente pede empréstimo; O pedido possui um prazo previsto para entrega.
identificam-se identificam-se : cliente e pedido como conceitos importantes e candidatos à se tornarem um cartão car tão e portanto portanto um uma classe. clas se. Essa não é a única fonte fonte de classes. class es. As classe c lassess podem pode m estar nos document documentos os e relatórios relatóri os do sistema, sistema, nos papéis dos personag per sonagens ens envolvi envolvidos dos nas ações, assim assi m como como em qualquer outro elemento importante que guarde alguma informação, ou que tenha alguma ação no problema estudado. Uma grande barreira na modelagem é a tendência em se manter preso aos mesmos modos de ver o mundo. O analista habituado a uma abordagem funcional ou de dados tem a tendência a continuar pensando em termos de bancos de dados e funções, e será mais difícil di fícil ver as classes, cl asses, e se utili utilizar zar das vantag vantagens ens da orientação orientação a objetos. Analis Analisar ar um conjun conjunto qualquer qualquer de letras para identificar identificar as palavras pa lavras que podem ser formadas, formadas, é mais fácil, as vezes, criar cria r uma uma palavra pal avra nova, se as letras não formarem formarem um uma palavra pal avra evidente. Pode-se ficar olhando olhando as letras e não não ver as palavras. palavras . Assim, Assim, para ter sucesso no encont encontrar rar e dar nomes nomes às classes, class es, usando usando os cartões CRC, deve-se trein trei nar o olhar. Deve-se ter um cuidado especial especi al ao dar nomes nomes para par a as classes. class es. Os nomes nomes devem deve m ser significativos significativos e bem be m específicos, extraídos do con co ntexto texto do problema. pr oblema. Um Uma boa prática é evitar nomes nomes genéricos dem de mais como: como: sistem s istema, a, usuário, usuário, controlador controlador e operador. oper ador. A menos não ser, é claro, que estes nomes tenham um significado próprio no domínio do problem proble ma estudado. estudado. O nom nomee da classe clas se e de um objeto criam um um vocabulário para par a 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 programação procedural. É
imperativo imperativo que se encon e ncontre tre um conjunt conjuntoo sign si gnificativo ificativo de palavras palavr as para descrever descreve r 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 expressões dos diversos domínios de projeto,
Ambulatório, Ambulatório, Enfermaria, ProntuárioMédico ProntuárioMédi co PassagemAérea, PassagemAérea, Balcão, Bagagem, Bagagem, Avião Avião FichaDePresença, RelogioDePonto Nem sempre sempre identificar objetos é simples e intuit intuitivo. ivo. Particularment Particularmentee em grandes aplicações classes mais genéricas podem gerar classes mais específicas cuja seleção adequada é um dos segredos do sucesso da boa modelagem. O uso de técnias como o CRC podem ajudar a testar e revisar revis ar diferent di ferentes es diagram di agramas as de classe class e durante durante as fases de projeto. Nenhu Nenhum ma técnica, técnica, entretant entretanto, o, substitu substituii a investigação, as entrevistas entrevistas e a experiência em campo.
4.3.8. 4.3 .8.
Anali Analisar os resquisitos resquisitos
Identificado Identificado um um conjunt conjuntoo de classes candidatas, c andidatas, passa-se a avaliar avali ar os cenários descritos descri tos nos nos requisitos. re quisitos. Cada cenário representa r epresenta um uma responsabilidade res ponsabilidade que o sistema sistema deve assum a ssumir, ir, que devem ser distribuídas entre entre as a s classes, cl asses, na form formaa de atributos atributos e operações. No cumprimento de uma função uma classe pode chamar outras para ajudála, caracterizan caracteri zando do assim uma uma colaboração colaboraç ão entre entre elas. A dinâmica desta técnica é a seguinte: escolher um cenário, imaginar e simular a lógica do processo, distribuir as responsabilidades determinando o cartão que deve cumprir esta responsabilidade, atualizar o cartão sempre que necessário, colaborar com outras classes se for preciso.
4.3.9 4. 3.9..
Distribuir Distribuir as respons resp onsabil abiliidade dad e
A responsabilidade de uma classe é uma função que o sistema exige que a classe cumpra. Tais funções são decorrentes dos objetivos listados pelos usuários (atores), nos requisitos do modelo de contexto.A contexto.A responsabilidade responsabilidad e é algo que um uma classe cl asse sabe ou faz. faz. O que a classe class e sabe está expresso nos seus atributos, atributos, e o que a classe class e sabe fazer fazer são funções funções que a classe cl asse oferece o ferece ao sistem s istema. a. Responsabilidades expressão ações que identificam problemas a serem resolvidos. As soluções existirão no interior da implementação destas ações. Uma responsabilidade serve para levar à discussão das potenciais soluções. Quanto mais se puder exprimir exprimir com essas frases, frases , mais mais poderoso poder oso e consiso será ser á o projeto. Aqu Aquii também também encontrar encontrar as palavras palavr as certas cer tas é um valioso vali oso uso de tempo tempo no projeto (Beck, 1989). Em geral, as responsabilidades são expressas por uma série de frases verbais curtas, cada uma contendo um verbo de ação e algum objeto, como mostam os exemplos abaixo:
Fazer Pedidos Definir o preço preç o ConsultarViagens Calcular Calcular salario Se um requisito pedir por uma responsabilidade ainda não coberta por nenhuma das classes, pode-se adicionar a responsabilidade em uma das classes existentes ou, excepcionalment excepcionalmente, e, criar cri ar uma uma nova classe class e para receber esta responsabilidade. responsabil idade. Anota-se Anota-se a responsabilidade em uma linha do cartão, como já mostrado nas figuras. O número limitado de lin li nhas do cartão car tão é proposital, pr oposital, porque se uma uma das classes class es se s e torma torma muito muito complexa, durante este processo, copia-se a informação deste cartão em um outro cartão procu proc urando meios meios mais concisos de represent repres entar ar o que o objeto deve fazer. Se ainda assim ass im a classe clas se continu continuar ar complexa, complexa, identifica-se uma uma nova classe cl asse para assumir assumir as responsabilidades, se não existir pode-se criar uma nova classe.
4.3.10. 4.3.10 .
Caracteri Caracte rizzar os colaboradores
Uma classe é incapaz de cumprir sozinha todas as responsabilidades de um sistema. No cum cumprimento primento de um uma responsabilidade responsabili dade que lhe lhe foi atribuída, atribuída, ela el a pode solicitar soli citar a colaboração de outras classes. Isso quer dizer que em algum ponto do cumprimento da sua função, a classe invoca uma outra responsabilidade da classe colaboradora. Este fato fato é indicado i ndicado no cartão se escrevendo es crevendo o nome nome da outra classe clas se ao lado da responsabilidade. A existência existência da colaboraçã col aboraçãoo é própria própri a da naturez naturezaa dos objetos, e do fato que que nenhu nenhum m objeto é uma ilha isolada, mas faz parte de um sistema. Os objetos se relacionam uns aos outros e criam as redes de colaboração. Colaboradores são os objetos para os quais se envia mensagens para satisfazer uma determinada responsabilidade. Um objeto pode colaborar colabo rar com vários outros, outros, e não possuir nenh nenhuum colaborador. colabor ador. Assim como como alguns objetos podem exigir muitos colaboradores e não 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 preço do pedido deve ser estimado com base na lista de produtos ... Representa-se na modelagem de um cenário foi atribuída a esta classe a responsabilidade EstimarPreco da classe pedido, que calcula o preço estimado do pedido com base no no preço de cada cad a produto, produto, individualment individualmente. e. Para isso, is so, a classe clas se Pedido pede a colaboração cola boração da classe c lasse Produto, que possui a responsabilidade CalcularPreco, que calcula o preço pre ço do produt pr odutoo com base na quant quantidade idade a ser adquirida e no preço unitário, também presente na classe Produto. Estas relações são representadas nos cartões CRC como mostra a figura:
Figura 48 - Exemplo de colaboração entre cartões CRC
Ao final da análise dos cenários, tem-se cartões ricos em responsabilidades e colaborações. Cada cartão representa um elemento importante do sistema e a união destes cartões ca rtões representa, r epresenta, conceitualm conceitualment ente, e, o sistema sistema a ser constuído. constuído. Pode-se ainda, validar o sistema simulando a dinâmica de cada cenário, para saber se a distribuição de funcionalidades e as colaborações são adequadas e suficientes.
4.3.11 4.3 .11..
Simul Simular ar a dinâmica dinâmica do cenári ce nárioo
Na simulação simulação do sistema, sistema, cada participant partici pantee da reunião, reunião, desen dese nvolvedor ou cliente, cliente, assum ass umee o papel pape l de algu al guns ns cartões enqu e nquanto anto se executa executa o cenário. cenári o. Semelhantem Semelhantemente ente a um um teatro, os projetistas proj etistas assumem assumem o papel das classes class es e respondem aos estím e stímulos ulos externos externos como aquela classe responderia. Uma boa estatégia estatégia para dar início i nício à simulação simulação é arranjar os cartões car tões adequadament adequadamentee sobre a mesa. Esta visão espacial dos cartões é muito valiosa, pois ela ajuda a identificar identificar um projeto ainda a inda incompleto incompleto ou ainda pouco entendido. entendido. A relação rel ação espacial espaci al permite permite destacar famíli famílias as de classes, clas ses, e grupos grupos de classes clas ses que devem atuar atuar em conjunt conjunto, o, ou até mesmo a necessidade de uma colaboração maior entre duas ou mais classes. A possibilidad possibi lidadee que os cartões car tões CRC oferecem oferecem de manipu manipular lar as classes, cl asses, antes antes abstratas, e agora concretizadas concretizadas nos cartões, é muito uito im i mportante portante para o analista analis ta e, especialm especi alment ente, e, para os usuários usuários.. Pode-se Pode-s e olhar os cartões envolvidos em um cenário e tentar ver o que eles tem em comum. Pode-se tentar rearranjar estruturas atuais em uma nova estrutura. Os cartões CRC não irão fazer este trabalho para o analista, mas ao focar as classes, usando a linguagem das classes eles podem ajudar a descobrir o que é crítico para o sucesso de um sistema sistema orient ori entado ado a objetos. Beck e Cunningham (1989) reforçam ainda a importância em não se criar objetos para atender necessi necessidades dades futu futuras ras do sistem si stema, a, mas mas somente somente para atender atender as necessidades do present pres ente, e, expressas nos requisitos dos cenários. cenários . Isto garante garante que que o projeto contém contém apenas a quant quantidade idade de inf i nform ormação ação 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 cenários destinados, especificam especi ficament ente, e, a localizar local izar falhas, fraquezas fraquezas e omissões do sistema sistema proposto. pr oposto.
4.3.12. 4.3.12 .
Traduz Traduziindo os cartões cartõe s em classes classes UML UM L
Ao final da aplicação da técnica CRC o analista tem nas mãos um conjunto de cartões que representa conceitualmente o sistema. O destino dos cartões depende do método adotado. Dando seqüência à abordagem de modelagem proposta aqui, os cartões devem ser traduzidos em classes na notação da UML. O diagrama de classes, ao final desta tradução é o model modeloo conceitual do sistem sis tema. a. Este processo proce sso é uma uma tradução porque apenas apenas a lin li ngu guagem agem está sendo alterada, não não é acrescida acres cida nenh nenhuma uma nova informação na representação do novo modelo. A tradução segue as seguintes regras: 1.
Para cada cartão cria-se cria -se uma uma classe, class e,
2.
O nome nome do cartão car tão é o nome nome da classe cla sse,,
3.
As classes class es podem ter superclasses superclasse s que são represent repres entadas adas no modelo.
4. As responsabilidades responsabil idades atribuídas atribuídas a cada cartão são traduzidas traduzidas em atributos atributos ou operações: a. As responsabilidades responsabili dades que que estão associadas associ adas ao armazen armazenam ament entoo de uma uma informação da classe são traduzidas em atributos, e b. As responsabilidades responsabili dades que estão associadas a ações que a classe class e deve executar executar para o sistem si stema, a, são traduzidas traduzidas em operações. 5. Havendo Havendo colaborações colabora ções entre entre duas classes é uma uma indicação que pode haver haver algum tipo de relacionamento entre as classes. O tipo de relacionamento irá depender, a critério c ritério do projetista, proj etista, da forma forma como serão implem implement entadas adas as colaborações. ·
4.3.13. 4.3.13 .
Vantagens da técnica técnica dos cartões cartõe s CRC
Uma das maiores vantagens da aplicação da técnica dos cartões CRC em projetos de software é que com um pequeno investimento em treinamento, tem-se os especilistas de uma área fazendo a análise e descrevendo o software e usando efetivamente o paradigm paradi gmaa de objetos. Esta descrição descri ção não é meram merament entee um relato mas mas sim um um modelo conceitual consistente do sistema.
Uns poucos minutos de introdução é suficiente para preparar a audiência para uma apresentação baseada em cartões. Os cartões podem ser feitos antecipadamente ou escritos na hora. Esta última forma permite que a complexidade do projeto seja revelada aos poucos. Os cartões estão sendo usados como meio para contar a história do processamento. Os cartões permitem contar esta história sem o recurso da linguagem de programação, sua sintaxe ou idioma.(Beck,89) idioma.(Beck,89) Resumindo, a técnica dos cartões CRC: É um método eficiente para localizar local izar objetos, obj etos, Favorecem ao entendimento do método orientado a objetos, É uma uma ferramenta ferramenta de análise e projeto pr ojeto usada nas fases iniciais, i niciais, Quee pode ser apresentada Qu a presentada a usuários usuários,, Incent Incentiva iva a integração integração com os usuários usuários e especialis especi alistas tas na análise, É simples e direta di reta e não assusta os usuários usuários É barato e portável, Pode ir de mão em mão como um protótipo e Leva diretamente a um diagrama conceitual de classes.
4.4.
Estudo Estud o de Caso: Jogo da Forca
Para exemplificar a aplicação da técnica dos cartões 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 permite que que qualquer qualquer um possa ser considerado um especialis especi alista ta do assunto, assunto, propor e analisar as suas funcion funcionalida alidades. des. Segue uma breve descrição 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 negócio: computador, ador, o jogador é desafiado des afiado a descobri de scobrirr as letras que No jogo da forca em comput formam uma palavra secreta, escolhida automaticamente pelo computador. A cada letra errada, sugerida pelo jogador, ele perde uma parte do corpo: cabeça, tronco e membros, desenhada no boneco na forca. Ao se desenhar todas as partes deste boneco, o jogador perde o jogo enforcado. Por outro lado, ao acertar todas as letras e descobrir a palavra secreta, o jogador vence o jogo. Deseja-se desenvolver o modelo conceitual conceitual orientado a objetos deste de ste jogo para par a se s e construir construir um program programaa de computador que seja executado na internet. A figura abaixo ilustra esta descrição:
Figura 49 - Esquema típico típi co do jogo da forca. O desenvolvimento desenvolvimento do modelo modelo conceitual conceitual do jogo da forca é dividi d ividido do na fase de brainstorm, na seleção de classes, e distribuição de responsabilidades entre o conjunto
de cartões. O modelo modelo conceitual do jogo jogo da forca, represent repres entado ado pelo diagram di agramaa de classes, class es, é obtido traduzindo-se traduzindo-se os cartões em e m classes class es na notação notação da d a UML UML.
4.4.1.
Model Mo deloo de Contexto
O modelo de contexto objetiva organizar em um modelo a descrição informal apresentada anteriormente. Neste exemplo, apenas o jogador é um ator, que possui como como grande grande objetivo o de jogar j ogar a forca. forca. O jogo da forca forca é representado re presentado por um um sistema, que interage com este ator, como mostra a figura:
Figura 50 - Representação do sistema sist ema de forca com uso de de um pacote
Diagrama de Casos de Uso O modelo modelo de context contextoo do jogo j ogo da forca é representado re presentado pelo diagram di agramaa de casos c asos de uso e pela pel a descriçã descr içãoo textu textual al de cada cad a caso de uso. Para aumentar aumentar o detalhamento detalhamento do modelo, divided ivide-se se o objetio de jogar a forca cont c ontra ra o comput computador ador em dois objetivos obj etivos no sistema: sistema: iniciar um novo jogo e chutar chutar letras para adivinh adivi nhar ar a palavra palavr a secreta. sec reta. Optou-se Optou-se por represent repr esentar ar a lista li sta de palavras palavra s como como um ator, porque ela pode ser considerada considera da como um elemento imutável, externo ao sistema. Esta situação é representada pelo diagrama:
Figura 51 - Diagrama de Casos de Usodo Jogo da Forca Forca
Ator: Jogador representa os jogadores (usuários) do sistema de jogo da forca.
Ator: Lista de Palavras representa a lista de palavras armazenadas para alimentar o jogo. É um ator passivo, imutável, imutável , que só fornece informações. inf ormações.
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 uma lista lis ta de palavras já existente. exist ente. Cenário de exceção A lista lis ta de palavras não existe exist e ou não pode pode ser encontrada, encontr ada, impedindo a continuidade do jogo.
Caso de Uso: Chutar Letras Objetivo principal: O jogador chuta letras para tentar acertar a palavra secreta. Cenário Cenário altern alte rnativo ativo 1 A cada letra errada, err ada, ele perde uma parte do corpo do boneco. Ao Ao completar todas as partes do corpo do boneco o jogador perde. Cenário Cenário altern alte rnativo ativo 2 A cada letra certa cer ta a palavra vai se desenhando des enhando na tela. Ao descobrir descobrir todas as letras e descobrir a palavra secreta, o jogador vence o jogo.
4.4.2.
M odelo Concei Conce itual
O desenvolvimento do modelo conceitual do jogo da forca segue a proposta dos cartões CRC se divide na fase de brainstorm, na seleção de classes, e distribuição de responsabilidades responsabil idades entre entre o conjunt conjuntoo de cartões ca rtões CRC. Como Como result res ultado ado da aplicação aplic ação desta des ta técnica, técnica, tem-se tem-se um modelo conceitual do jogo, represent repres entado ado pelo diagrama diagrama de classes cl asses,, que é obtido da tradução dos cartões c artões em classes represent repres entadas adas pela pe la UML UML. Brainstorm Brainstorm
A obtenção obtenção de uma uma listagem l istagem das funcionalidades funcionalidades previstas previs tas para o jogo da forca vem de um estudo estudo das diversas divers as ações a ções execu e xecutadas tadas durante durante uma uma partida. par tida. Pode-se Pode-s e considerar considera r 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 é represent repres entado ado pela pel a classe cl asse Forca. As ações que se seguem seguem reproduzem reproduzem um jogo típico, entre entre a forca e o jogador. j ogador.
O jogo da forca possui uma lista de palavras secretas armazenda, O jogador inicia um novo jogo, A forca escolhe escol he uma palavra palavra da lista, lis ta, Uma Forca Forca vazia é desenhada, O jogador chuta uma letra da palavra, O jogador deve saber as letras que já foram chutadas, Se a palavra possuir possuir a letra l etra estiver a letra é desenhada, desenhada, Se a palavra não possuir a letra, uma parte do boneco é desenhada, Se a letra é a crescentada na lista de letras erradas se não estiver na palavra, Quando a palavra estiver completa o jogador ganhou, Quandoo o boneco estiver Quand est iver completo o computador ganhou
Candidatos Candi datos a cl classes asses Uma leitura atenta das funcionalidades acima mostra que as ações são comandadas pelos segu s eguint intes es elem ele mentos: entos: Forca Jogador Palavra
Boneco E que por isso são candidatos a classes deste sistema. Estas escolhas se confirmarão com a distribuição das responsabilidades, realizada a seguir.
Distribuição das Responsabildiades Cria-se um cartão para cada classe e passa-se a analisar as funcionalidades ident ide ntifica ificadas, das, uma uma a uma: uma:
O jogo da forca possui uma lista de palavras secretas armazenda, Esta funcionali funcionalidade dade identifica id entifica que o jogo da forca forca possui, po ssui, internamente, internamente, uma uma lista lis ta 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 Forca vazia vazi a é desenhada A responsabilidade responsabil idade de iniciar inicia r um novo jogo, que que é solicitada soli citada pelo pel o jogador humano, humano, é atribuída à Forca, que faz a interface interface com o usuário usuário e controla o início i nício do jogo. j ogo. Iniciado o jogo, a forca seleciona, automaticamente, uma palavra da lista, e desenha a forca vazia e o número de letras da palavra onde o jogo será desenvolvido. A palavra é desenhada com espaços indicando as letras. Para desenhar a palavra e o boneco a Forca usa métodos apropriados das classes Palavra e Boneco. Este métodos são dependentes da tecnologia empregada para a interface.
O jogador chuta uma letra da palavra A classe Forca faz a interface interface com o usuário usuário recebendo rec ebendo a letra sug s ugerida erida pelo usuário 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 início da definição do cartão Forca A figura acima mostra o cartão da Forca até este momento do estudo. A seguir dá-se prosseg prosse guiment uimentoo ao processo process o de distribuição das responsabili r esponsabilidades: dades:
O jogador deve saber as letras que já foram chutadas A responsabilidade de chutar uma letra é atribuída ao Jogador, que também 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 desenhar a letra, que podem ser atribuídas atri buídas à palavra pa lavra,, já que esta possui conhecimen conhecimento to das suas próprias letras. l etras.
Se a palavra não possuir a letra, uma parte do boneco é desenhada Nesta responsabilidade responsabilidad e vemos vemos que quando quando a palavra verifica veri fica que a letra não não está na palavra palavr a ela precisa pr ecisa da ajuda a juda do boneco, boneco, porque será desenh dese nhada ada uma uma parte do boneco. Assim atribui-se uma colaboração do boneco na palavra e a responsabilidade de desenhar desenhar uma uma parte par te para o boneco. As partes par tes do boneco devem deve m ser gu guardadas ardadas na própria própri a classe clas se boneco, que que deve sabe qual a parte (Cabeça, tronco ou membros embros que irá desenhar em seguida)
Se a letra é a crescentada na lista de letras erradas se não estiver na palavra A lista de palavras erradas é mantida pelo Jogador
Quando a palavra estiver completa o jogador ganhou Quando o boneco boneco estiver est iver completo o computador ganhou Aqui vemos que a classe palavra deve ter uma responsabilidade para saber se ela está completa, completa, assim assi m como como o boneco, que deve saber sabe r se ele está e stá completo. completo. Associadas Associada s à estas responsabilidades responsabili dades temos temos a funcion funcionalida alidade de do jogador em ganh ganhar ar ou o u perder, respectivam respec tivament ente. e. Represent Represe ntam am-se -se as responsabili r esponsabilidades dades de ganhar ganhar e perder per der no cartão car tão da classe Jogador, com a ajuda das classes Palavra e Boneco.
4.4.3.
Cartões CRC
Abaixo estão os cartões CRC resultantes da distribuição de responsabilidades. Optou-se Optou-se por manter anter o nome nome das responsabilidades responsabili dades próximo próximo da descrição descri ção da funcionalidade levantada na fase de brainstorm. Posteriormente, o nome das responsabilidades serão traduzidos em nomes de operações e atributos das classes e podem se alterar. alterar .
4.4.4.
Tradução Tradução dos Cartões em Classes Classes
Para construir o modelo conceitual, utilizando a notação da UML, deve-se traduzir cada cartão c artão em um uma classe, cl asse, onde o nome nome do cartão será ser á o nome nome da classe. class e. Assim, para o cartão car tão Boneco Boneco cria-s cr ia-see a classe class e Boneco, como como mostrado mostrado na figura figura abaixo. a baixo. As responsabilidades descritas no cartão são traduzidas em atributos e operação. Observase que a responsabilida re sponsabilidade de que corresponde corres ponde a guardar guardar as partes par tes do boneco é um atributo atributo (um dado) arm ar mazenado azenado pela pel a classe, cla sse, assim as sim cria-se o atributo parte na na classe cl asse Boneco. As outras outras duas responsabilid re sponsabilidades ades correspondem cor respondem a ações 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 operações na classe Boneco: bonecoCompleto bonecoCompleto e desenha, desenha, respectivam respec tivament ente. e. A figu figura ra abaix abai xo compara compara o cartão car tão da classe Boneco com a classe representada na UML.
Analogament Analogam ente, e, são traduzidas as classes cl asses Forca, Jogador J ogador e Palavra. Palav ra. Nesta são identificadas as responsabilidades que se transformam em atributos e as que se tornam operações. Ao dar os nomes para as operações e atributos procura-se seguir as restrições restriçõe s das lingu linguagens agens de programação programação evitan ev itando do acentuação acentuação nas palavra pa lavras, s, caracteres car acteres especiais e espaços em branco na formação dos nomes. A tabela que se segue mostra a correspondência entre a responsabilidade descrita no cartão e os atributos e operações nas classes: cl asses:
O diagrama diagrama de classe c lassess deve refletir a comun comunicação icação entre entre os objetos. Deve-se observar que de posse do diagrama de classes e da especificação das classes, descrita no verso dos cartões, é possível possíve l se s e construir construir o sistem si stema. a. Como Como este é um sistema sistema simples, o modelo conceitual é quase auto-suficiente. No entanto o programador deverá ainda tomar tomar uma uma série sér ie de d e decisões deci sões de projeto pr ojeto na fase de implemen implementação. tação. O programador programador deve decidir dec idir sobre uma uma série séri e de objetos auxili auxiliares, ares, em como como será implementada a interface e como serão implementadas as comunicações entre as classes. class es. O modelo detalhado, estudado estudado no próximo próximo capítu capí tulo, lo, será s erá utilizado para definir definir mais precisamente os detalhes da implementação dos sistemas. No capítulo 6 retoma-se o jogo da forca, lá se desenvolve o modelo detalhado que conduz à implementação.
Figura 53 – Diagrama Diagrama de Classes Conceitual do Jogo da Forca
5. O Modelo Detalhado Este capítulo capít ulo descreve técnicas t écnicas para construção constr ução dos modelos modelos orientados orie ntados a objetos. Nele são descritos, em detalhe,os seguintes diagramas da UML: classes, seqüência, colaboração, estados, atividades, ati vidades, componentes e distribuição. dist ribuição. Estes diagramas são apresentados como formas de descrever os detalhes da estrutura, da dinâmica interna e da construção de um sistema sist ema em componentes componentes de software.
5.1.
Introdu Introdução ção aos modelos detalhados da UML
O desenvolvimento desenvolvimento de sistem si stemas as de software software é apoiado apoi ado em visões que evoluem com o entendimento do problema e com a aproximação da fase de construção. Este capítulo leva o modelo modelo do sistem si stemaa ao seu nível nível mais alto de detalhes. Apresenta-se Apresenta-se aqui como como criar, criar , a partir par tir do modelo de contexto contexto e do modelo conceitual conceitual das classes, class es, uma uma visão vis ão mais rica r ica em e m detalhes detal hes e integrada integrada do sistem si stemaa de software softwar e com os diagram dia gramas as da UML. UML. [7]
A OMG (2001) define a UML como “ Uma linguagem padronizada para especificar, visualizar, construir e documentar documentar todos os artefatos de um sistema de software .” É uma proposta para unificar, em torno de uma notação padronizada, as diversas divers as representações r epresentações gráficas dos sistem s istemas as de software software.. A ampla ampla aceitação a ceitação da UML pela comunidade comunidade de desenvolvedores, e pela pel a própria própri a indústria de software, é uma uma prova da sua força e um uma avaliação avali ação da sua importân importância.Segu cia.Seguee um breve histórico da evolução da notação, que é útil para compreeender compreeender o seu s eu estágio estágio atual de evolução. evol ução.
5.1.1.
Históri Histórico co da UML UM L
Atualm Atualment ente, e, qualquer projeto proje to de software que decida pela orientação a objetos ob jetos como como paradigm par adigmaa de desenvolvimento, desenvolvimento, deverá ser represent repres entado ado pela pe la UML assim encontrará apoio em um grande número de ferramentas CASE disponíveis no mercado. A adoção de uma notação padronizada permite, entre outras vantagens, a separação entre a análise, o design e a construção. O contingente de pessoal técnico 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 sempre foi assim assi m, nos anos 80, apesar apes ar da tecnologia tecnologia a orientação a objetos ob jetos á ser bem conh conhecida, uma uma diversidade divers idade de metodologias metodologias e notações notações procuravam proc uravam represent repres entar ar os sistemas sistemas de software orient ori entados ados a objetos de diferentes diferentes formas. formas. Ao se iniciar um novo projeto de software era er a preciso pre ciso selecionar selec ionar um método e, quase sem se mpre treinar uma uma equipe para par a utili utilizar zar aquela notação notação e poder desenvolver de senvolver os modelos. A falta de um padrão criava cria va um problema adicional adici onal para a difu di fusão são da tecnologia tecnologia de orientação a objetos. Dentre as muitas metodologias existentes, datacaram-se o OOSE de Jacobson (1992), o OMT de Rumbaugh (1994) e o método de Booch (1994). Em 1993, Booch já estudava uma aproximação com o trabalho de Rumbaugh e untos, na empresa Rational, iniciam o esforço de unificação das duas metodologias. No final de 1995, introduziram o conceito do UM - Unified Method - que se tornou em seguida, após a entrada de Jacobson na equipe, na UML - Unified Modeling Language - com a separação entre a linguagem de modelagem e o processo de desenvolvimento. Os esforços esforç os de Booch, Rumbaugh Rumbaugh,, e Jacobso Jac obsonn resultaram, res ultaram, em 1996, na na emis emissão são da versão UML 0.9 quando os autores convidaram a comunidade em geral para opinar. A lista lis ta de tecnologia tecnologia de objetos obj etos patrocinada pela Rational, Rational, a OTUG OTUG – Object Technology User´s Group - foi um ambiente de aprendizado colaborativo e um grande motivador da ampla ampla adoção a doção atual da UML UML. Os subsídios da discussão dis cussão pública públic a pela pel a internet criaram criaram as revisões 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 p assa a ser gerenciada pela pel a OMG, OMG, que a incorporou na na sua sistem sis temática ática de padronização e revisões. revisões . 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 notação da UML é padronizada, e deve ser assim assi m para poder descrever descre ver com precisão precis ão cada parte do software, de forma única e de um modo onde qualquer um, que conheça a UML, possa
ler o mesmo software. Por outro lado, o software é uma tecnologia em evolução, uma notação que resistisse à esta evolução, estaria fadada ao insucesso. A dificuldade em conciliar uma notação precisa, rigorosa e padronizada com uma notação que possa evoluir com c om a tecnologia tecnologia foram os maiores desafios de safios enfrentados enfrentados pela equipe de desenvolvi dese nvolvim mento desta des ta ling l inguag uagem em.. A UML é o resultado de um processo de convergência dos principais métodos para desenvolvimento de sistemas orientados a objeto existentes na primeira metade da década de 90. Cada método deu a sua contribuição para a formação da UML, sendo que o resultado é mais preciso e mais homogêneo que as linguagens anteriores. Ela consegue descrever os sistemas de forma mais abrangente, levando a modelagem mais próxima próxima da implemen implementação. tação. Possui element elementos os de expansão expansão que permitem permitem acomodar acomodar novos sistemas, assim como novos elementos na modelagem. Os objetivos inicias da UML, descritos pela OMG (2001), são:
Fornecer aos desenvolvedores desenvolvedore s uma linguagem de de modelagem visual, pronta para o uso no desenvolvimento e comunicação de modelos modelos ricos ri cos em significados. signif icados. Oferecer mecanismos de extensibilidade e especialização para ampliar os conceitos principais. Dar suporte à especificações especif icações de projeto proj eto independentes da linguagens l inguagens de programação e do processo de desenvolvimento. desenvol vimento. Prover uma base formal para o entendimento de uma uma linguagem de modelagem Encorajar o crescimento cresci mento do mercado mercado de ferramentas ferr amentas de software orientadas a objeto. Dar suporte aos conceitos de desenvolvimento des envolvimento de alto alt o nível como componentes, colaboração, frameworks e padrões. Integrar as boas práticas práti cas de projeto. A UML especifica uma linguagem de modelagem que conseguiu o consenso da comu comunidade de especia e specialis listas tas em orientação orientação a objetos nos conceitos chave da modelagem. Com a UML se é capaz de atender os mais variados problemas de modelagem odel agem atuais, de uma uma form for ma dir d ireta eta e econômica econômica.. Alguns Alguns probl p roblem emas as futu futuros ros esperados, espera dos, especial es pecialm mente ente os relacionados rela cionados com a tecnologia tecnologia de com co mponen ponentes, tes, comput computação ação distribuída, frameworks e executabilidade já são abordados pela notação. Com a UML, é possível a troca de modelos entre uma variedade de ferramentas, além da criação cri ação de repositórios reposi tórios para par a armazenag armazenagem em e troca de modelos. A notação da UML é uma notação gráfica, onde a descrição de um software é feita
com símbolos gráficos padronizados que se relacionam formando diagramas. Cada diagrama diagrama apresent apr esentaa uma uma visão vi são parcia pa rciall do sistema sistema de software software,, e a união união dos diagram di agramas as deve represe r epresent ntar ar um único sistema sistema de software. Os diagram di agramas as são s ão descritos des critos por nomes omes e termos padronizados, que compõem um glossário próprio de termos que também faz parte da UML UML..
5.1.2.
Os diagramas diagramas da UML UM L
Os modelos detalhados descrevem mais precisamente os fenômenos observados no problem proble ma, assim como como pemitem pemitem,, encaminh encaminhar ar o sistem sis temaa à sua implemen implementação tação em uma linguagem de programação. Algumas metodologias preferem distinguir os modelos desenvolvidos nas diversas fases, como modelo de análise, modelo de projeto, modelo de im i mplementação plementação e assim assi m por diante. Aqui Aqui eles e les serão chamados chamados apenas de modelos detalhados, independentemente da sua finalidade. O diagrama diagrama de classes, class es, desenvolvido des envolvido como modelo modelo conceitual conceitual do sistem si stema, a, é insuficient insuficientee para par a descrever des crever todos os detalh de talhes es do projeto. Os cartões CRC mostram mostram que para se ter um sistema sistema é importan importante te definir definir como como as classes clas ses irão ir ão colaborar. colabor ar. Entretant Entretanto, o, a colaboração, ainda é pouco explorada neste modelo, e precisa ser detalhada para considerar outros fenômenos presentes no sistema, descrever mais precisamente a troca de mensagens entre as classes, assim como para acrescentar elementos importantes da implementação. O diagrama de classes traduz uma visão estática, sem movimento, equivalente à uma foto do sistema, e por isso não permite avaliar caractersísticas dinâmicas do comportamento interno e externo da classe. Assim, é necessário desenvolver outras visões da dinâmica do problema, para descrevê-lo com precisão. As visões dinâmicas e estáticas do problem prob lemaa devem se int i ntegrar, egrar, e se complement complementar, ar, para pa ra representar r epresentar um sistema passível de ser contruído. O modelo modelo detalhado de objetos, obj etos, descrito descri to neste neste capítu capí tulo, lo, é formado formado pela pel a reu re união destes diversos di versos diagramas, diagramas, que permitem observar o problem probl emaa sob âng ângulos ulos particulares, e que exploram exploram características im i mportantes portantes do problema estudado. estudado. As visões utilizadas no modelo modelo detalhado de objetos, são listadas lis tadas a seguir e podem ser organizadas como mostra a figura:
Figura 54 - Exemplo de navegação entre os diagramas da UML
A visão da estrutura estrutura de um modelo detalhado é dado pelo diagrama diagrama de classes. class es. As classes, class es, ident i dentificadas ificadas no modelo modelo conceitual, conceitual, formam a base bas e sobre sobr e a qual são ergu e rguidos idos os componentes do sistema. As classes mostram apenas uma visão estática do sistema. A visão dinâmica complementar é oferecida por um conjunto de diagramas de interação entre as classes e pelo diagrama de estados. A interação entre as classes de um sistema sistema é mostrada pelos pe los diagramas diagramas de seqüência e diagrama diagrama de colaboração, colabor ação, que repres rep resentam entam as mensagens mensagens trocadas trocad as entre entre as classes clas ses.. Os Os diagram dia gramas as de estado mostram mostram o ciclo cic lo de vida de d e uma uma classe, cl asse, represe r epresent ntando ando a sua dinâmica dinâmica int i nterna. erna. Para serem ser em construídas, as classes podem ser agrupadas em componentes de software que são então distribuídos pelos servidores. Estas situações são descritas pelos diagramas de componentes e de distribuição. O modelo de contexto define o comportamento externo do sistema, que é distribuído, na modelagem modelagem conceitual, conceitual, para par a as classes class es do sistema. sistema. Estas classes cl asses participam de processos process os que podem ser modelados pelos diagram di agramas as de seqüência, atividades ativida des ou de colaboração. colabor ação. Intern Internam ament ente, e, as classes class es tem seus ciclos de vida modelados pelo diagrama de estados. Assim, o comportamento interno do sistema implementado nas classes por suas operações, forma a base das mensagens trocadas entre as classes, assim como implementam as transições de estado em uma classe. A coerência entre as classes e suas operações garantem a coerência do modelo e do sistema como um todo.
Figura 55 - O analist analistaa e o modelo modelo conceitual conceit ual
Nos modelos modelos de cont c ontext extoo e no modelo modelo conceitual conceitual o analista se coloca col oca em uma posição posiçã o de algum alguma distância com relação rela ção ao sistem sis tema, a, para não perder a visão vi são 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 são separados em características estruturais, estruturais, que são representadas rep resentadas nos diagramas diagramas de classes, class es, características car acterísticas dinâmicas dinâmicas que podem ser representadas r epresentadas nos diagramas diagramas de interação interação e de estado, e stado, ou características de implementação que são representadas nos diagramas de componentes ou de distribuição.
5.2.
Diagrama de classes classes
O diagrama diagrama de classes, class es, já j á introduzido introduzido no modelo modelo conceitual, conceitual, deve d eve agora ser s er detalhado para poder descrever com precisão o sistema a ser construído. Os sistemas orientados a objetos organizam-se ao redor de classes de objetos, que representam tanto os elementos do domínio do problema, incorporados ao modelo, como os elementos elementos propostos para pa ra a implemen implementação tação da solução. O diagrama diagrama de classes class es represent repres entaa a planta baixa do sistema, sistema, estabelecendo es tabelecendo uma uma relação r elação entre entre os elem e lement entos os do problem proble ma e o código que que os implement implementa. a. Para implement implementar ar um diagrama diagrama de classes clas ses é necessário que a ling l inguuagem de program pr ogramação ação dê pleno pl eno suporte suporte à orientação a objetos, como a linguagem de programação Java, que será utilizada como exemplo neste estudo. As classes formam uma unidade que encapsula atributos e operações. Uma classe define um conceito importante para o problema e pode se relacionar com as outras. Mas são os objetos, instâncias instâncias das classes cl asses,, que interagem interagem nos programas, programas, disparam di sparam mensagens, podem até ser transmitidos em uma mensagem pela rede ou mesmo armazen armazendos dos em e m bancos de dados. dados . A identificação das classes class es do sistema, sistema, sua constitu constituição ição e relacio re lacionnament amentos os é a essência es sência da modelagem orientada a objetos, obj etos, e já j á foi desenvolvida, em grande parte, com a modelagem conceitual no capítulo anterior. Este capítulo detalha detalha o diagrama diagrama de classes clas ses e todos as suas nuanças nuanças e o relaciona rela ciona com os diagramas dinâmicos e de implementação, criando uma visão detalhada do sistema de software. Uma classe é representada por um retângulo dividido em 3 partes onde se representa o nome, nome, seus atributos e suas operações. operações . Estas partes são s ão apresent apre sentadas adas nos terços do retângulo com maior ou menor quantidade de detalhes, em função do grau de abstração desejado ou da fase de detalhamento do modelo, como mostram os exemplos da figura:
Figura 56 - Exemplos de representação represent ação 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 classe c lasses, s, atributos, atributos, operações operaçõe s e também também para as relações r elações.. A escolha de um um nome nome adequado pode facilitar muito o entendimento do problema, enquanto uma escolha incorreta de um nome pode tornar o modelo incompreensível. Os nomes devem ter significado para o domínio do problema em questão, descrevendo elementos importantes do sistema e aproximando o modelo do problema real. As classes class es devem ser nomeadas nomeadas com c om expressões subst s ubstant antivas ivas breves, iniciadas por uma letra maiúscula para que representem um nome próprio do vocabulário do problem proble ma em estudo. estudo. O nom nomee da classe class e deve ser único no âmbito âmbito do subsistema subsistema que a contém. O nome da classe deve ser escolhido de modo a ter um significado relacionado com a sua responsabilidade responsabil idade do sistem s istema. a. Assim Assi m, Funcionario, Funcionario, Livro, CartaoDePonto CartaoDePonto e [8] ProntuarioMedico ProntuarioMedico são nomes nomes adequ adeq uados para par a classes. cla sses. Os atributos são nomeados da mesma forma que as classes. Com a diferença que os atributos são iniciados por letras minúsculas e representam propriedades das classes. São bons nomes para as classes outros substantivos associados às classes, frases adjetivas curtas curtas ou adjetivos substant substantivados ivados que podem qualificar as classes, class es, por exemplo: cor, nome, baixo, tamanho, tempoDeEspera, dataDeAniversario, menorIndice e maiorValor. As operações indicam ações que a classe pode executar. As operações devem ser nomeadas nomeadas com c om nomes nomes relativos r elativos às à s responsabilidade res ponsabilidadess que a classe cla sse assum as sumee para o sistema. sistema. Verbos Verbos ou frases frases verbais verbai s curtas são bons exemplos exemplos de d e operações. opera ções. As operações operaçõe s assim ass im como como os atribut a tributos os são iniciadas por letras l etras minúscu minúsculas, las, com c omoo por exemplo: exemplo: calcularV cal cularValor, alor, fazerPedido, vender, investir investir e comprar comprar . Analogamente aos atributos, a classe ou o objeto que é criado a partir dela, será o sujeito das operações Com exceção da herança, todos os relacionamentos entre as classes de um sistema podem ser nomeados. nomeados. Os detalhes da represen represe ntação de cada tipo de relacionam rela cionament entoo são apresentados juntamente com os adornos disponíveis para um relacionamento.
5.2.2.
Visibilidade
Uma das características das classes é a capacidade de envolver em uma cápsula atributos atributos e operações o perações e poder, a seu critério, critéri o, ocultar estas informações informações de d e outras outras classes. Para controlar quais atributos e operações 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: pública, privada ou protegida, é indicada por um símbolo na frente do nome do atributo ou da operação, como mostra a tabela. Como Como uma uma boa prática de projeto, pro jeto, uma uma classe cl asse só deve oferecer ao sistem si stemaa suas operações operaçõe s públicas. públi cas. Assim Assi m, oas outras classes cla sses só podem invocar invocar as mensagen mensagenss relacionadas às operações públicas e apenas estas operações podem ser herdadas. As operações privadas e os atributos servem para atender as necessidades internas da classe, são visíveis por toda a classe mas não são visíveis externamente.
Esta boa prática de projeto evita que outras classes tenha acesso direto, e descontrolado, aos valores dos atributos da classe. Se uma classe oferece atributos públicos públic os ela perm per mite que seu estado seja alterado al terado sem que ela possa tomar tomar uma uma ação a esse respeito. respei to. Dando Dando acesso aces so aos atributos atributos unicamen unicamente te por int i nterm ermédio édio de operações oper ações de acesso, a classe cl asse pode controlar o que ocorre ocorr e quando quando um atributo atributo seu se modifica alterando, por exem e xemplo, plo, o seu estado. Para dar acesso aos atributos privados são criadas as chamadas de operações de acesso. Os nomes destas operações de acesso devem ser padronizados para facilitar a sua construção por ferramentas automatizadas, e para dar um acesso padronizado por outras outras classe c lasses. s. A tabela abaixo aba ixo exem exemplifica plifica as operações oper ações padrão p adrão de acesso em uma uma classe de Produto mostrada na figura: figura:
Figura 57 - Exemplo de operações de acesso A classe Produto, do exemplo, possui os atributos privados: nome do tipo texto (String), (String), qtd do tipo inteiro (int (i nt)) e outro outro chamado chamado disponível di sponível do tipo boolean boole an (falso ou verdadeiro). A tabela descreve algumas operações
Como Como o atributo atributo disponível dis ponível é um atributo atributo booleano bool eano usa-se usa-se a operação oper ação isDisponível i sDisponível no lugar do getDisponível como forma padronizada de acesso. Supondo que a disponibilidade disponibil idade do produto depende depende da quan quantidade tidade do produt pr oduto, o, podemos podemos definir o valor va lor do atributo se ele el e está disponível di sponível ou não com base na quantidade quantidade atribuída ao Produto. Assim o pseudocódigo do método 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, Assim, se os atributos atributos qdt ou disponível forem públicos, é possível possíve l modificar modificar os seus valores valor es direta di reta e independent independentem ement ente, e, e ter-se a quantidade quantidade zero (qtd=0) (q td=0) e valor val or
disponível ainda verdadeiro verdade iro (diponivel="true"), criando uma uma condição inconsistent inconsistentee para o produ prod uto. O parâmetro parâmetro disponível é alterado al terado alterando-se a quantidade, quantidade, por esta razão, não faz faz sentido sentido ter-se a operação setDisponivel setDisponivel.. Confirm Confirma-se a-se assim assi m a boa prática pr ática de adotar usar métodos métodos de acesso públicos públi cos e atributos atributos privados. pri vados. Uma Uma exceção a esta e sta regra são as a s constantes constantes globais, que por serem se rem constan constantes tes serão lidas lida s e não podem ser modificadas, não necessitando de um método de acesso. Outra operação muito útil é a operação que gera uma seqüência de caracteres para testar a classe e apresentado o seu conteúdo conteúdo im i mpresso, presso , por exemplo. exemplo. Cria-se Cri a-se assim a operação oper ação toString() toString() que retorna retorna um texto texto que descreve o objeto. obj eto.
5.2.3.
Instanciamento Instanciamento de Classes Classes em Objetos
Uma classe cla sse pode p ode ser se r instanciada em e m um objeto, obj eto, como mostra mostra a figura. Com os objetos pode-se pode -se construir construir um diagrama diagrama de objetos, relaci r elacionan onando do os objetos como se relacionam as classes que os formam.
Figura 58 - Exemplo de um objeto Para instanciar instanciar o produ prod uto lampada, lampada, por exemplo, exemplo, deve-se de ve-se criar cria r um objeto com base na classe EquipEletrico, que é traduzido em código por métodos chamados de construtores: lampada= new EquipEletrico(110, 5.00)
Neste exem exemplo, plo, escrito escr ito em Java, o método método EquipEletric EquipEletrico(ten o(tensao, sao, valor) valor ) é um método constutor da classe EquipEletrico, e é um executado em associação ao comando new para criar o objeto livro livr o com base na na classe.
5.2.4.
Classes Classes concretas, conc retas, abstratas e interfaces nterfac es
As classes são instanciadas em objetos, dos quais se pode invocar as operações públicas públic as na form formaa de mensag mensagens. ens. No No entant entanto, o, nem todas as classes clas ses permitem a sua instanciação instanciação direta em objetos, as classes class es que perm pe rmitem item a su s ua inst i nstanciação anciação em objetos são chamadas classes concretas. Em muitos casos, pode ser necessária a criação de classes class es que apenas descrevem des crevem conceitos conceitos abstratos a bstratos e que não são transform transformados ados em objetos diretamente, as chamadas de classes abstratas. class es devem ser abstratas. Estas classes herdadas por outras outras classe c lassess concretas, que irão im i mplement plementar ar os conceitos abstratos criando uma uma classe cl asse concreta que que pode ser instanciada. instanciada. As classes class es abstratas são muito uito úteis nas primeiras etapas da modelagem, modelagem, na fase da modelagem conceitual conceitual e na criação de famíli famílias as de classes class es reut r eutili ilizáveis. záveis. As classes cla sses abstratas não podem ser instanciadas instanciadas porque algun alguns de seus métodos métodos são abstratos, isto is to é, existe ainda algo na classe abstrata que não foi definido. Um método abstrato é um método do qual se conhece apenas a sua chamada, a sua assinatura, e que ainda não foi construído. Isto é, uma classe abstrata tem pelo menos um dos métodos da classe apenas declarado, declar ado, e ainda a inda não não existe sua implem implement entação ação concreta para ele. Nas primeiras fases da modelagem de um sistema é possível que alguns métodos de uma classe ainda não tenham sido completamente definidos o que a caracterizaria como abstrata. A assinatura de uma operação ou método é o nome da operação e seu conjunto de parâmetros. parâmetros. Um método abstrato não não possui o corpo do método método onde se encont encontra ra o algoritm algori tmoo que o imple implem menta. Uma classe clas se abstrata abs trata pode possuir poss uir métodos métodos concretos, concre tos, mas mas deve ter pelo menos um método abstrato. Para uma classe abstrada se tornar concreta ela deve d eve ser herdada por outra que irá sobrescr s obrescrever ever os o s métodos métodos abstratos com métodos métodos 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 jurídica, que é implement implementado ado pelas pel as classe c lassess concretas de empresa empresa cliente (EmpresaCli (EmpresaClient ente) e) e de empresa fornecedora (EmpresaFornecedora). O método criarEmpresa é um método abstrato de deve ser implemen implementado tado pelas classes class es filhas para que estas sejam concretas. concretas.
Figura 59 - Exemplo de classe abstrata abstrat a Um tipo de classe abstrata muito útil na modelagem é a interface. Uma interface é uma classe formada apenas por métodos abstratos. Ela serve para se definir uma forma de comunicação entre as classes de um modelo, porque descreve apenas um conjunto de mensagens que as classes que a implementam devem obedecer. Ela define um padrão de comu comunicação, e se posiciona posici ona entre entre classes, clas ses, por isso é chamada chamada de interface. interface. No exem exemplo plo abaixo abai xo tem temos os a definição de um uma Obra em uma biblioteca, bibli oteca, que que é a definição abstrata de um conceito que serve para se comunicar com o sistema da biblioteca. bibli oteca. A herança herança de uma uma interface interface é chamada chamada de implement implementação ação porque a classe class e concreta devem implementar todos os métodos da classe de interface. Esta herança é representada também por uma linha pontilhada porque não é uma herança verdadeira, uma vez que não há métodos concretos para serem herdados. A “herança” em uma interface é uma implementação. O uso de interfaces é bastante difundido na criação de classes class es reut r eutili ilizáveis záveis e no desenvolviment desenvolvimentoo de componen componentes tes de soft s oftwar waree portáveis. portávei s.
Figura 60 - Exemplo de Interface e Implementação I mplementação
5.2.5.
Adorno Adorno dos relacionamentos relacionamentos
Os relacionam rel acionament entos os podem po dem receber elementos elementos gráficos para descrever, descreve r, com c om maior maior precisão, preci são, a ligação li gação existent existentee entre entre duas classes. classes . A base para o relacionam rel acionament entoo entre entre duas classes classe s é a associação associ ação que represent repr esentaa uma uma un união ião con co nceitual entre entre as duas classes. classes . Na associação associaç ão pode-se inclu i ncluir ir uma uma seta para aument aumentar ar a navegabil navegabilidade idade da associaç as sociação, ão, um losango para indicar uma agregação e uma multiplicidade nas extremidades. Uma seta na associaçã ass ociaçãoo mostra mostra a navegação navegação do relacionam relac ionament ento, o, ou seja, a direção di reção do relacionamento identificando quem é a classe dependente (origem da seta) e quem é a classe cla sse independent i ndependentee (ponta da seta). Um losang los angoo em uma uma das extremidades da seta s eta transforma uma relação em uma composição, istop é, transforma a associação em um relacionam relac ionament entoo de agragação agragação todo-parte, todo-par te, onde onde o losando identifica a classe c lasse que é o todo. Uma associa asso ciação ção pode pod e ter um nome nome indicando indica ndo o tipo tipo de rela r elacio cionam namento ento que exis existe te entre entre as a s classes. cl asses. O nome nome mostra mostra qual é o conceito que une une as classes. class es. Estes adornos podem ser observados obser vados no exem exemplo plo abaixo, abai xo, onde um uma empresa empresa possui pos sui um uma série séri e de produtos produtos que são as suas vendas. vendas.
Figura 61 - Exemplo de adornos adornos em relacionamento O adorno mais importante em um relacionamento é a multiplicidade da relação. Ela descreve descre ve quantos quantos objetos participam partici pam desta relação rel ação e é indicada por um símbolo nas nas extremidades da relação. O exemplo da figura mostra que uma empresa realiza vendas de muitos (*) produtos, nesta relação a navegação indica que é a empresa quem vende os produtos. A tabela tabela abaixo aba ixo mostra mostra os símbolos utili utilizados zados na na represent repre sentação. ação.
Em um sistema esta relação vai indicar que cada um dos objetos que forem instanciados instanciados a partir da classe cla sse Empresa poderão poderã o ter um vínculo vínculo com vários objetos da
classe Produto. O nome deste vínculo é vendas. Na fase de implementação este relacionamento pode, por exemplo, ser traduzido em um vetor de produtos criado na classe class e Empresa. Empresa. A composição composição indica ainda a existên e xistência cia dos d os produtos destas vendas (partes) está condicionada à existência da classe Empresa, o todo na relação. Os vínculos vínculos entre entre as classe class e formam formam os caminh caminhos os pelos pel os quais são enviadas as mensagens que criam a dinâmica de um sistema orientado a objetos. Supondo-se, no exemplo, que os objetos da classe Produto tenham um método público getPreco(), que inform informaa o preço pr eço de cada produt pr oduto, o, é possivel poss ivel aos objetos obj etos da classe cl asse Empresa Empresa pergunt perguntar ar o preço de um produto produto do vetor de vendas com a mensag mensagem em::
vendas[i].getPreco();
que inform informaria aria o preço do d o produto produto de índice i do vetor. A modelagem modelagem da troca de mensagens ensagens entre entre os objetos o bjetos é modelado pelos diagramas diagramas de d e int i nteração, eração, que são estudados estudados a segu se guir. ir.
5.3.
Diagramas de Interação
As mensagens formam a base da dinâmica de um sistema orientado a objetos. A partir da modelagem modelagem conceitual conceitual procurou proc urou-se -se ident i dentificar ificar e representar r epresentar as responsabilidades das classes na forma de mensagens que a classe seria capaz de responder. Os diagram d iagramas as de interação interação objetivam descrever, 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 serão utilizados amplamente nesta seção e nas seguintes. Um sistema é constituído por um conjunto de classes, que dividem entre si uma série de funcionalidades implementadas em métodos e atributos. A integração destas funcion funcionalida alidades des garante o cumprimen cumprimento to da totalidade dos objetivos previstos previs tos para o sistema sistema orient ori entado ado a objetos o bjetos que foram levantados das descriçõe desc riçõess dos casos de uso no modelo de contexto. No modelo de contexto obseva-se também que são os atores a real origem das mensagens, uma vez que as classes respondem a estímulos vindos dos objetivos dos atores. Na modelagem modelagem conceitual conceitual ficou claro que uma uma classe cl asse isoalada isoal ada é incapaz de atender à totalidade de funcionalidades existentes em um sistem, e para isso depende das funcionalidades funcionalidades das outras classes cl asses do sistem si stema. a. Para utilizar uma uma funcionalidade do objeto de uma classe envia-se uma mensagem para ele, que é implem implement entada ada em um uma operação oper ação pública pú blica do objeto obj eto de destin des tino. o. Assim, a operação operaç ão de um sistema orientado a objetos se traduz em uma intensa troca de mensagens entre os objetos, estim es timulados ulados por eventos eventos externos externos vindos vi ndos dos atores do sistem si stema. a. Os objetos que participam da interação formam um contexto, que é a reunião dos objetos e dos vínculos que unem os participantes da interação. A figura, que representa uma interação, esquematiza os conceitos de vínculo, mensagem e contexto e suas relações :
Figura 62 - Componentes Componentes de uma interação A colaboração colabor ação entre objetos, para atingir atingir um determinado determinado objetivo, é realizada reali zada pela requisição de um serviço servi ço que um objeto necessita de outro outro objeto, obj eto, que está capacitado capaci tado a prestar este serviço. serv iço. Um Uma mensag mensagem em geralment geralmentee é iniciada por um ator em um objteo. Este estímulo pode dar origem à outra mensagem, e a esta por sua vez a outra, seqüencialmente, até que o objetivo inicial seja cumprido. A modelagem dinâmica das interações entre as classes é feita na UML por um conjunto de dois diagramas chamados de diagram di agramas as de interação: interação: Diagramas Diagramas de Seqüência Se qüência Diagrama Diagrama de Colaboração Cola boração O diagrama diagrama de seqüência descreve d escreve a organ or ganização ização das mensagens ensagens trocadas entre entre objetos no tempo em um cenário de uso do sistema. É sabido que a colaboração entre os objetos obj etos se dá entre entre objetos obj etos que se relacionam rel acionam,, e principalm pr incipalment ente, e, por meio destes relacionamentos. O diagrama de seqüência não mostra este relacionamento. Para descrever descre ver a troca de mensagens ensagens que ocorre nos relacionam relaci onament entos os entre os objetos usa-se o diagrama diagrama de colabora c olaboração. ção. Na modelagem modelagem das in i nterações o olhar do modelador modelador deve estar suficientem suficientement entee distan dis tante te das classes cl asses para não perceber perc eber os detalhes dos objetos, obje tos, mas próxim pr óximoo o bastan b astante te para perceber as mensagen mensagenss entre eles. eles . O colaboração cola boração e a seqüência de mensagens representam a mesma informação sobre o sistema, sendo possível possív el traçar um diagrama diagrama a partir do outro.
5.3.1.
Mensagens
As mensagens são instâncias do comportamento dinâmico externado pelos objetos. Elas surgem, quase naturalmente, ao se analisar um caso de uso ou, ao se projetar a distribuição de responsabilida re sponsabilidades des de um problem proble ma entre os objetos obj etos de um sistema. sistema. Quando um objeto, o emissor, envia uma mensagem para outro objeto, o destinatário, ele está e stá solicitando soli citando que que o destin de stinatário atário execute execute uma uma operação oper ação da sua coleção. Estabelece-se, a priori , que o objeto que recebe a mensagem é capaz de atender esta solicitação, devendo possuir uma operação pública preparada para isto. São igualmente consideradas como mensagens os estímulos externos recebidos pelo sistema. Um usuário, ao solicitar uma ação 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 operação e é, essencialmente, uma instância desta operação. Como as operações, uma mensagem possui um nome, parâmetros e um valor de retorno. O retorno é a resposta da mensagem e está implícito na maioria das mensagens. Se um objeto faz uma pergunta é porque, provavelmente, espera uma resposta. No entanto, podem existir mensag mensagens ens assínronas, assínronas, que não não aguardam aguardam a resposta, respos ta, e mensag mensagens ens como como a emissão de sinais, que não tem um retorno implícito. A tabela mostra os diversos tipos de mensagens:
5.3.2.
Diagrama Diagrama de Seqüência Seqüência
Os diagramas diagramas de seqüência descre des crevem vem o comportamen comportamento to dos objetos obje tos do sistema, que se relacionam pela troca de mensagens em interações seqüencializadas no tempo. Cada diagram di agramaa mostra mostra um cenário, cenári o, isto is to é, um conjunto conjunto de mensagens, mensagens, ordenadas no tempo, com um determinado objetivo. Assim, para a elaborar um diagrama de seqüência é important importantee que os objetivos do sistem si stemaa já j á tenham tenham sido levantados pela modelagem de contexto, e que se encontrem descritos nos cenários 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 descrição do caso de uso Emitir Fatura, neste sistema poderia ser:
A fatura é emitida emit ida com a soma soma dos preços dos itens do pedido e endereçada endereç ada ao cliente. Na visão de uma uma troca de mensag mensagens ens entre entre os objetos : fatura, pedido, item e cliente, a descrição deste caso de uso fica:
A pedido do Gerente de Contas, a fatura inicia inici a a sua emissão perguntando ao edido quais são os itens e segue enviando uma mensagem aos itens da fatura, erguntando qual o seu preço unitário, uma informação que é própria de cada item. seguir, a fatura pergunta ao cliente qual o seu endereço e, finalmente, retorna ao erente para a aprovação . Este processo é representado pelo diagrama de seqüência abaixo
Figura 64 - Exemplo de Diagrama Diagrama de Seqüência Enquan Enquanto to o diag dia grama rama de casos de uso mostra mostra a visão fun funcional, o de classes cl asses apresen aprese nta um uma visão vis ão estática da estrutu estrutura das operações, operaçõe s, já o diagrama diagrama de seqüência s eqüência oferece uma uma visão vi são dinâm di nâmica, ica, onde a presença pres ença da variável var iável tempo tempo pode ser facilment facilmentee observada. observad a. O tempo tempo corre corr e de cim c imaa para baixo no no diagrama diagrama de seqüência, s eqüência, o que quer dizer que os event e ventos os in i nferiores ocorrem após os eventos eventos superiores superior es no diagrama. diagrama. As linhas linhas verticais represent repres entam am os objetos e as horizont horizontais ais as mensagen mensagenss trocadas trocada s en e ntre eles. O diagrama de seqüência é o diagrama ideal para especificações de sistemas de tempo real, pois o tempo aparece de forma explícita e as mensagens podem ter tempos e intervalo intervaloss bem b em definidos. definidos. Algum Algumas recom r ecomendações endações são úteis para pa ra se elabora e laborarr um diagram diagramaa de seqüência mais claro e preciso. É comum, por exemplo, que ao lado das mensagens se tenha uma descrição textual do processo, com notas explicativas. É também comum que um ator inicie o diagrama, porque como o diagrama se propõe a descrever a seqüência 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. Não é sempre sempre necessário necessári o represent repres entar ar no diagram diagramaa de seqüência a resposta res posta às mensagens, porque elas existem implicitamente. Entretanto, muitas vezes trata-se de mensagens assíncronas e o retorno só virá após outras mensagens terem sido executadas. Dai, é importante identificar quando isso ocorre usando, explicitamente, a mensagem de retorno. re torno. As mensagen mensagenss de retorno retor no são repr r epresentadas esentadas no diagrama com setas tracejadas, traceja das, ao contrári contrárioo das ou o utras mensag mensagens ens que que são linhas linhas contínu contínuas. Uma outra caracaterística do diagrama de seqüência é a capacidade de representar a linha da vida dos objetos que mantem o foco da ação a cada momento. Esta anotação é feita tornando tornando a linh li nhaa vertical ver tical que representa objeto mais mais espessa, espessa , quando quando este está e stá 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 memória do processador, process ador, porque não participa, naquele naquele mom moment entoo do processam process ament ento. o. A figura que se segue mostra um diagrama com o foco de controle dos objetos para exemplificar este recurso. O gerente solicita a emissão de uma fatura que mantém-se em foco enquanto solicita aos pedido a lista de Itens e para cada item da lista o seu preco, e finalmente finalmente o endereço ao cliente cl iente da fatura. fatura. Term Ter minada esta tarefa a fatura fatura retorna retor na ao gerente que a aprova.
Figura 65 - Exemplo do diagrama diagrama de seqüência do sistema da loja
5.3.3.
Diagrama Diagrama de Colaboração Colaboração
Analogament Analogam entee aos diagramas diagramas de seqüência, os diagramas diagramas de colaboração colabor ação representam as interações entre objetos na forma de troca de mensagens. A diferença entre os dois diagramas é que o diagrama de seqüência não mostra a estrutura de vínculos entre os objetos que dão apoio à comunicação, enquanto o diagrama de colaboração colabor ação mostra os vínculos vínculos entre entre as classes, class es, pelos pe los quais fluem as mensagens. ensagens. Outra Outra diferença está no fato que no diagrama de colaboração o eixo dos tempos não é apresentado explicitamente. Estas pequenas diferenças não impedem que se faça uma transform transformação ação direta do diagram di agramaa de seqüência no diagram di agramaa de colaboração. colabor ação. A figura figura abaixo mostra mostra o diagram di agramaa de colabora c olaboração ção referen re ferente te ao processo proces so de emissão emissão de fatura, fatura, descrito no item anterior. Os nomes das mensagens, assim como no diagrama de seqüência devem ser bem escolhidos para refletir as operações opera ções presentes na na classe de destino. Uma seta (à) associada à mensagem facilita a leitura e indica a sua direção. As mensagens, no diagrama de colaboração, podem ser numeradas, o que dá ao diagrama uma orden na seqüência das mensagens no tempo, refletindo a ordenação apresentada no diagrama de seqüência. O diagram di agramaa de colaboração colabor ação pode po de ser utilizado como um uma opção ao diagram di agramaa de seqüência.
Figura 66 - Exemplo de diagrama diagrama de colaboração A existência de um vínculo entre os objetos do diagrama de colaboração indica uma possibili possib ilidade dade de um relacionam relac ionament ento, o, mas, mas, necessariam necessari ament ente, e, não o representa. representa. Os
vínculos servem de meio para que as mensagens fluam e para a navegabilidade no diagrama. Havendo um vínculo as classes podem colaborar, porque há um caminho por onde a mensag mensagem em pode ser s er en e nviada.Os víncu v ínculos los entre entre os objetos podem ser dos tipos:
Concluindo, os diagram Concluindo, di agramas as de int i nteração eração represent repres entam am a visão da din di nâmica âmica presente entre entre as a s classes cl asses de um sistema. sistema. Eles Ele s se caracterizam caracteri zam por descrever de screver uma uma troca intensa intensa de mensagens, seqüencializadas no tempo, relativas a um objetivo do sistema. Enquanto no diagrama diagrama de seqüência o eixo dos tempos tempos está es tá presente, não não está represent repres entada ada a estrutura estrutura das classes. cl asses. Já no diagrama diagrama de colaboração colabor ação encon e ncontra-se tra-se a estrutura, estrutura, mas não se encontra encontra o eixo dos tempos. tempos. Ao final da elaboração elabor ação dos diagramas diagramas de interação, interação, temtemse representada nas mensagens, as operações necessárias às classes para cumprir todos as responsabilidades do sistema. As operações são descobertas porque as mensagens são instâncias das operações. Tendo modelado modelado todos os cenários c enários previstos pr evistos no modelo de con co ntexto texto para um sistema, as classes devem ter recebido todos as operações necessárias para responder às mensagens ensagens trocadas no desenvolvim des envolviment entoo dos cenários. Resta agora verificar veri ficar se se internam internament entee as classes class es possuem pos suem a dinâm di nâmica ica e coerência coer ência necessária, necessári a, papel este desempenhado pelo diagrama de estados.
5.4.
Diagrama Diagrama de Estados
A descrição descri ção da dinâmica dinâmica int i nterna erna de uma uma classe cla sse é feita pelo diagram dia gramaa de estados, e stados, ele reflete o ciclo cic lo de vida dos do s objetos obje tos da classe, cla sse, desde des de o moment momentoo em que que este objeto obj eto é criado criad o até o seu término término quando quando ele el e não é mais utilizado pelo pel o sistem si stema, a, passando pass ando por todas as situ s ituações ações em que o objeto poderia poderi a se encontrar. encontrar. Cada classe cl asse do sistem sis temaa é modelada por uma máquina de estados finita, onde o olhar do modelador deve se posicionar posici onar bem próximo próximo aos mecanism mecanismos os internos internos da classe, cla sse, dentro até até dos lim li mites da própria própri a classe. clas se. A proximidade proximidade deve dev e ser o suficiente suficiente para poder observar, observar , isoladam isolad ament ente, e, cada detalhe interno interno dos estados e stados e das suas transições transições.. O diagrama de estados representa a dinâmica interna de uma classe como sendo formada formada por estados e eventos. eventos. Estados caracterizam cara cterizam condições, situ si tuações, ações, onde o objeto daquela classe pode ser encontrado. Eventos são ações que provocam a mudan udança ça nestas condições. O estado e stado é uma uma atividade ativi dade da classe class e de caráter lento lento (estado (es tado de ação), e às vezes até estático (estado de espera). Por ter este caráter lento, pode ser interrompido por um evento. O evento, por sua vez, retrata uma atividade rápida e que não pode ser interrompida, interrompida, uma uma vez iniciado irá levar, levar , necessáriam necessári ament ente, e, 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 transição de estados est ados
5.4.1.
Evento
Um evento na dinâmica de uma classe está associado às mensagens que a classe recebe, e consequentem consequentement ente, e, às su s uas operações oper ações int i nternas. ernas. São as operações operaçõe s das classes class es que permitem permitem a mudança mudança das su s uas caracterís c aracterísticas ticas int i nternas, ernas, ou seja, são as operações operaçõe s que provocam as alterações no estado. A simbologia adotada pela UML para dar nome a um evento é:
evento[condição]/ação onde :
A condição de disparo di sparo é uma uma expressão booleana que quando quando verdadeira verdadeir a permite o disparo do evento. A expressão é avaliada apenas na ocorrência do evento e permite que um mesmo evento provoque diferentes mudanças de estado, conforme as diferentes condições de disparo a ele associadas. No exemplo que se segue analisa-se o evento retirarMaterial da classe cl asse itemEstoqu itemEstoque, e, que simula simula um possível possíve l sistem s istemaa para par a controle de estoque estoque de materiais. ateriais .
Figura 68 - Diagrama de Classes do Exemplo Supondo que o itemEstoque esteja na sua condição de estoqueNormal, isto é, a quantidade de itens (qtd) está acima do estoque mínimo (estoqueMinimo), a ocorrência do evento retirarMaterial pode po de provocar provoc ar a mudança para a condição estoque baixo, se qtd, variável variáve l que controla a quan quantidade tidade de material, ficar inf i nferior erior ao estoqu es toqueMín eMínim imo. o. Caso contrário o itemEstoque ainda é mantido no estado de estoqueNormal. Pode-se associar ações com o disparo de eventos, estas ações são mensagens enviadas pela classe onde ocorre o evento para outras classes que irão provocar novas mudanças de estados. Esta reação em cadeia que ocorre nas classes é a operação típica de um sistema orientado a objetos. No exemplo, na ocorrência da mudança de estado de estoqueNormal para o estoqueBaixo é diparada uma ação, na forma da mensagem emitir para o objeto obj eto comprador comprador da classe class e Compras, Compras, passando pass ando como como parâmetro parâmetro a variável vari ável qtdReposicao, que indica a quantidade quantidade que deve ser reposta sempre que o estoque estoque fica abaixo do mínimo. ínimo. A figura figura mostra o diagrama diagrama de estado que descreve desc reve estes processos pr ocessos::
Figura 69 - Exemplo de um diagrama de estado
5.4.2.
Estados
Um estado é uma situação em que um objeto pode se encontrar no decorrer da seu ciclo de vida. Esta situação pode ser caracterizada por um conjunto de valores dos atributos, isto é, analisando os valores dos atributos deve ser possível dizer qual é o estado da classe. class e. Existem diferentes diferentes tipos de estado, que possuem diferentes diferentes representações segundo a UML. A tabela abaixo mostra estas representações que são descritas a seguir:
O e stado inicial repr esentam am a situ si tuação ação da classe class e antes antes do início e inicial e estado final represent após o término término do seu ciclo de vida. vida . O evento evento que parte de um estado inicial é um evento de criação (Construtor ) de uma classe, assim como o evento que leva a um estado final é um evento de extinção da classe ( Destruto r). O estado de espera e o estado de ação são estados e stados em que que a classe cl asse podem po dem se encontrar encontrar e diferem pela ação que a classes clas ses pode estar es tar executan executando do nesta. O estado de decisão é um estado que é utilizado para definir uma transição com base em uma uma condição. A diferença diferença entre entre um estado de decisão decisã o e uma uma condição de disparo associada a um evento é, que no estado de decisão, a condição é avaliada antes da ocorrência de um evento, e se executa uma transição em decorrência apenas desta decisão. Na condição de disparo a condição é avaliada apenas quando da ocorrência do evento, e apenas condiciona uma uma transição, não provoca prov oca a transição. transição.
O estado de sincronismo permite a paraleli para lelização zação ou o sincronismo sincronismo de eventos. eventos. É um estado auxiliar na construção de diagramas de estado porque permite que um mesmo evento evento seja sej a paraleli para lelizado zado em outros outros event ev entos, os, que sob novas condições de disparo, dispar o, pode provocar outras outras mudanças mudanças de estado e ações. De outro outro lado o estado de sincronismo sincronismo pode sincronizar sincronizar dois ou mais mais eventos. Os eventos eventos chegam chegam ao estado de sincronismo sincronismo de forma assíncrona, e provocam um outro evento agora síncrono. No exemplo que se segue , o eventoSaída eventoSaíd a só ocorre ocorr e quando quando ocorrerem ocorre rem os eventos eventoA 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, além 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, superes tado, repres rep resenta enta um evento que que parte ou chega chega a cada um dos estados es tados do seu se u interior interior em particular. particular. A integração de superestados, estados de sicronismo e decisão permite a criação de transições complexas e permite representar um sem número de máquinas 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 Eventos e operações, estados e atributos atributos
Enquan Enquanto to os eventos estão associados ass ociados às operações oper ações que um uma classe cl asse pode executar, executar, os estados estão associados aos valores que os atributos assumem. Um estado de uma classe class e pode ser preservado, preser vado, e até armazen armazenado, ado, pela pel a definição, e armazen armazenam ament ento, o, dos valores dos atributos, assim como a mudança de um valor em um atributo pode provocar a mudan mudança ça de um estado da classe. class e. É comum, em muitos casos, definir um atributo chamado estado, com a responsabilidade de indicar o estado atual da classe. Esta prática deve assegurar, entretanto, que a mudança do valor deste atributo acompanha fielmente a mudança de estados da classe. class e. A inobservância deste acompanham acompanhament entoo pode provocar situações incoerente, onde o atributo estado indica um estado e a classe está efetivamente em outro, outro, com c om conseqüências conseqüências imprevis imprevisíveis íveis para a operação ope ração do sistem si stema. a. Uma Uma outra possibili possib ilidade dade de implement implementação ação é criar cri ar uma uma operação getEstado, que que devolve o estado e stado da classe cl asse consu c onsultan ltando do uma uma série sér ie de outras outras operações e atributos. Os eventos, internamente às classes, assim como as mensagens, externamente às classes, são considerados instâncias das operações, isto é, uma operação pode ser utilizada em diversos eventos e mensagens, simplesmente alterando os parêmetros ou a condição de disparo. di sparo. Co já j á foi visto vis to anteriormen anteriormente, te, um uma boa prática de projeto é evitar que as classes clas ses alterem a lterem diretament diretamentee atributos de outras outras classe c lasses. s. Esta providência provi dência evita que a classe perca o controle do seu estado. Fazendo com que toda mudança de atributo seja feita por uma uma operação opera ção é possível possíve l se controlar controlar os estados, as a s mensag mensagens ens que que devem ser enviadas e os próprios atributos.
5.4.5.
Diagrama Diagrama de estado de uma interface nterfac e
Uma aplicação importante dos diagramas de estado pode ser encontrada na [9] descrição da operação das GUI interfaces gráficas dos programas. Uma interface gráfica gráfica é, em geral geral uma uma classe cl asse da camada camada de apresentação do sistem si stemaa que deve receber re ceber os event eve ntos os do usuário externo. externo. Em princípio, o usuário é livre livr e para par a interagir interagir com a interface interface acionan ac ionando do qualquer tipo de event e vento, o, a qualquer qualquer instante. instante. Esta liberdade li berdade pode, se não for devidam devi dament entee controlada, gerar situações perigosas peri gosas para a integridade integridade de uma uma aplicação. Operações delicadas como as de excluir um dado, criar um registro ou transmitir uma informação, devem ser cercadas de condições que as restringam. Criar um diagrama diagrama de estados da interface interface ajuda aj uda a definir os eventos eventos e estados possíveis poss íveis na interface e limita as condições de risco. O exemplo que se segue é uma interface simples, que permite a edição do campos Parâmetro e Valor. A interface tem, em resumo dois estados: o estado onde se edita os campos, e um estado onde estes campos são gravados. O diagrama de estado da interface interface mostra mostra as possíveis possív eis transições transições de estado es tado presentes nesta nesta int i nterface: erface: a lim li mpeza, a gravação e a saída da interface. Os eventos gravar, limpar e sair estão associados aos botões da interface, interface, e aos eventos que que o usuário usuário provoca pr ovoca ao clicá-l cl icá-los. os.
Figura 72 - Modelagem dos estados da interface interf ace (a) exemplo da interface e (b) diagrama de estados correspondente
Analisando este diagrama pode-se incorporar restrições como a de impedir a gravação se os campos não forem preenchidos, alterando o evento gravar com uma condição de disparo expressa pelo pseudocódigo gravar[(param gravar[(par ametro<>n etro<>nulo) ulo) e (valor<>n (valor <>nulo)] ulo)] que limita a gravação quando um dos campos estiver nulo.
5.5.
Diagrama Diagrama de Atividades
A dinâmica de um sistema pode ser representada internamente à uma classe pelo diagrama diagrama de estados, e externam externament ente, e, entre as classe c lassess pelo pel o diagram dia gramaa de seqüência. 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 seqüência de estados e evento, muito semelhante à de um fluxograma, e se aplica na descrição descri ção de um processo process o que transcende transcende a uma uma classe, cl asse, e envolvendo estados de outras outras classes. O diagrama diagrama de atividades a tividades é uma uma altern al ternativa ativa para represent repres entar ar um processo process o descrito descr ito por um caso de uso. Para isso iss o o diagrama diagrama de atividades dispõe dos mesmos esmos elementos elementos dos diagramas de estado: eventos e estados, mas que não se restringem a um único objeto. Como Como exemplo exemplo de uso do diagram d iagramaa de atividades pode-se desenvolver o diag dia grama rama de atividades da operação de vendas do sistema da loja, apresentado no capítulo 2. Neste exem exemplo plo o caixa cai xa deve entrar entrar com o código do produto produto , o CGC CGC do cliente e o número de parcelas para verificar se a venda está aprovada ou não. O diagrama de atividades abaixo mostra mostra a seqüência de comandos comandos que executam executam estas operações: ope rações:
Figura 73 - Exemplo de um diagrama de atividades
5.5.1. 5.5 .1.
Tril Trilhas de Responsa Re sponsabi billidades dade s
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 idéia é 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 relação entre o diagrama de atividades com o diagrama de classes. É interessante interessante observar obser var qu q ue associando as sociando os estados de um objeto em um uma vertica, ver tica, os eventos eventos qu q ue partem pa rtem desta vertical ver tical para outra outra vertica são equivalentes equivalentes às mensagens ensagens em um diagrama de seqüência. Em nosso nosso exemplo, exemplo, pode-se agrupar agrupar os estados e stados mostrados mostrados na execução execução da operação de verificação de vendas no objetos do POS, Loja, cliente e produto. Deve-se observar, comparando a próxima figura com a figura anterior, que os estados são os mesmos, mas a organização organização perm per mite identificar identificar,, claram clar ament ente, e, a responsabili r esponsabilidade dade de cada objeto obj eto no no processo. process o.
Figura 74 - Exemplo das atiividades com as trilhas tri lhas de responsabilidade responsabil idade
5.6.
Diagramas de Implementação Implementação
Os diagramas de implementação ajudam os analistas no projeto da implementação do sistem si stema. a. Nesta fase são definidos definidos os component componentes es de softwar softwaree e a sua distribuição dis tribuição entre entre os processadores process adores e servidores. Para a elaboração dos diagram diagramas as de implem implement entação, ação, o projetista deve de ve se posicionar posici onar a uma uma distân di stância cia tal do sistema, sistema, de modo a deixar de lado os detalhes construtivos da classes e observar apenas o conjunto do componen componente te e os servidores. servi dores.
Figura 75 - O analist analistaa vê as classes classe s e componentes de longe A representação da implementação na UML é realizada com dois diagramas: Diagramas de d e Component Componentes es Diagramas Diagramas de Distribuição Dis tribuição que serão detalhados a seguir. seguir.
5.6.1.
Diagrama Diagrama de Componentes Componente s
Componentes são unidades que armazenam software. A idéia é agrupar em uma unidade un idade uma uma parcela parce la do código do software para par a facilitar facili tar a in i ntegração tegração para formação do sistem si stema. a. Os component componentes es podem pode m ser associados associ ados aos arquivos ar quivos onde os códigos cód igos podem residir. resid ir. Os códigos fonte fonte ou códigos executáveis executáveis podem ser agrupados em componen componentes. tes. O critério cri tério para par a criação cri ação de um componen componente te pode ser s er as necessidades da linguagem de programação, ou o compilador, mas também pode-se criar componentes de software para atender os requisitos de distribuição do projeto e de reutilização. Um dos critérios usado para projetar um componente é otimizar a performance do sistema sistema . O componen componente te de software é a unidade que é utilizada para se distribuir di stribuir o processam process ament entoo do sistema. sistema. O uso uso de diferentes processadores processadore s pode aument aumentar ar a performance performance total, total, um uma vez que que é possível possí vel utili utilizar, zar, mais mais adequ adeq uadament adamente, e, o poder de processam process ament entoo distribuído em uma rede de computadores. computadores. O projeto de distribuição das classes class es em componen componentes tes objetiva transferir transferir para os component componentes es as relações rel ações present pr esentes es nas classe de modo modo a balancear ba lancear a com c omuunicação present pres entee nas classes clas ses e transferida transferida para par a os componentes. Um balanceamento adequado das comunicações entre os componetes promove promove o balanceament balanceamentoo da comun comunicação icação ent e ntre re os processador proc essadores es na rede, e com isso é possível possív el maxim maximizar izar o desempenh desempenhoo total total do sistem si stema. a. Outro critério Outro cri tério para p ara se projetar os com c omponen ponentes tes é a reut r eutili ilização. zação. Os component componentes es são unidades unidades que podem ser armazen armazenadas adas e reaproveitadas reaprov eitadas em vários 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 pública padronizada. O sistema é integrado pela união de componentes nos processadores. process adores. Um componente é representado, na UML, pelo símbolo apresentado na figura. A figura representa o encapulamento pelo retângulo com uma interface pública, identificad identificad pelos símbolos na borda do d o retângulo: retângulo:
Figura 76 - Notação de um componente
Um componente é formado por um conjunto de classes relacionadas. A intensão é isolar isol ar o grupo grupo de classes class es que possam poss am ser reutilizadas. Assim, o componen componente te se comporta como no caso do encapsulamento de um objeto. O componente depende das classes que o forma. Esta dependência pode ser mostrada em um diagrama. A notação indica a composição de um componente em dependência das classes que o compõe, como mostra mostra a figura:
Figura 77 - Um componente e as classes que o compõe Definidos os componentes, pode-se criar um diagrama de componentes descrevendo como como eles ele s dependem depe ndem entre entre si. s i. A dependên de pendência cia também também é a principal pri ncipal relação re lação entre entre os os componentes, como mostrado a seguir:
Figura 78 - Exemplo de um Diagrama de Compon Componentes entes O diagrama de componentes representa a configuração do software, isto é, como as diversas divers as partes pa rtes do sistema sistema se relaciona. rela ciona. Cada parte, par te, identificada identificada por um componen componente, te, é ligada às demais formando o sistema. Com o diagrama de componentes o integrador é capaz de criar cr iar uma uma versão ver são do sistema sistema de software. Para concluir concluir a implement implementação ação é necessário ainda a distribuição dis tribuição dos com c omponen ponentes tes pelos servidores, servi dores, que é o assunto assunto dos
diagramas diagramas de distribuição, apresent apr esentados ados a seguir: seguir:
5.6.2. 5.6 .2.
Diagramas de Distri Distribui buição ção
Os diagramas diagramas de distribuição descreve d escrevem m a configuração configuração do hardware, hardwa re, e a integração integração dele com o sofware. Os equipament equipamentos os são represent repres entados ados por nós que podem estar associados tanto aos processadores como aos servidores reais ou virtuais disponíveis para a aplicação. apl icação. Os nós se relacionam relac ionam entre entre si formando formando uma uma rede de processamen pr ocessamento to de dados. As ligações entre os nós representam as associações físicas e lógicas existentes existentes entre os equipament equipamentos os e servidores. servi dores. A UML representa de um nó é a representação de um cubo, que caracteriza um equipament equipamentoo processador pro cessador,, e seu tipo.
Figura 79 - Exemplo da Notação Notação de um nó nó Os nós recebem os componentes de software, em um diagrama que descreve a configuração do sistema, mostrando a dependência do com aos componetes que a ele são destinados.
Figura 80 - Composição Composição de um servidor com seus componentes O diagramas diagramas de distribuição represent repres entam am a ponte ponte que liga o software e o hardware que irá processá-lo. Assim, Assim, deve-se decidir qu quais ais os processadores serão utili utilizados, zados, e com c omoo distribuir di stribuir os componen componentes tes de software entre eles. el es. Os relaci rel acionam onamentos entos presentes em um diagram dia gramaa de distribuiçã dis tribuiçãoo formam formam as redes red es de
processam process ament entoo de dados.
Figura 81 - Exemplo de um Diagrama de Dist Distribuição ribuição
5.7.
Integração entre os Diagramas
Os diagramas da UML não existem isoladamente, eles fornecem visões complementares de um mesmo sistema e por este motivo devem ser coerentes entre si. Os diagramas diagramas dos modelos orientados a objetos obje tos são baseados bas eados nos mesm mesmos os princípios pr incípios fundamentais, ou seja: classes, heranças, mensagens, estados e eventos. Estes fundamentos garantem que os diagramas se integrem completamente, mostrando uma visão própria própri a do mesmo esmo sistem si stema. a. A base que define define a estrutura estrutura do sistem si stemaa são sã o as classes, class es, que formam formam a base para par a todo o modelo. A implementação do sistema em código executável, parte da criação das classes. A partir delas são criados os objetos que participam dos diagramas de seqüências e colaboração. Os diagramas de estado e atividades partem dos estados das mesmas classes, que formam, também, as bases para criar os componentes nos diagramas de implementação. Na estrutu estrutura ra das classes cl asses são s ão as mensag mensagens, ens, implem implement entadas adas nas operações, operações , que que permitem permitem a integração integração entre entre as diversas diver sas visões vis ões dos diagram di agramas. as. Como Como as mensag mensagens ens são baseadas baseada s nas nas operações operaçõ es das classes, clas ses, elas perm pe rmitem item que se integre integre o diagram diagramaa de classes class es com os diagramas diagramas de interação. interação. Como Como são as operações oper ações que controlam controlam os atributos atributos e permitem permitem às classes class es alterar al terar os seus estados, temos temos a integração integração entre o diagrama diagrama de classe c lassess e o diagrama diagrama de estados es tados também também através das operações. operações . Para exemplificar a integração que as mensagens proporcionam entre os diagramas, apresen aprese nta-se a segu s eguir ir a integração integração que existe existe entre os diagramas diagramas de classes class es e os diagramas diagramas de seqüência, e a integração integração entre entre o diagrama diagrama de estado e stado e as operações de uma classe.
5.7.1.
Integração entre os diagramas diagramas de classes classes e seqüência seqüência
Os diagramas de seqüência mostram uma troca de mensagens entre objetos de uma classe. class e. Cada mensagem mensagem se refere re fere a um serviço servi ço que a classe cla sse do objeto de destin de stinoo pode oferecer. Assim, para poder oferecer este serviço deve existir uma operação na classe do objeto de destino para implementar esta mensagem, como mostra o exemplo da figura:
Figura 82 - Relação entre mensagens e operações nas classes class es Na integração integração entre entre os diagramas diagramas deve-se deve-s e garantir garantir que as mensag mensagens ens presentes presentes nos diagrams diagrams de seqüência, s eqüência, correspondam corr espondam às operações oper ações nas classes de destino. No exemplo exemplo existe uma mensagem sendo trocada entre as classes de origem e destino, o que indica que existe existe uma uma operação oper ação corresp c orresponden ondente te na classe de destin des tino. o. Em um processo process o de desenvolvim des envolviment entoo pode-se pode- se detalhar os processos process os descritos desc ritos nos casos de uso em diagramas diagramas de seqüência. Neste processo pro cesso a modelagem modelagem da interação interação serve para complementar a distribuição de responsabilidade entre as classes, porque toda vez que que se determina um uma mensagem mensagem para uma uma classe cla sse,, se está distribuindo dis tribuindo as operações pelas classes. cl asses. A criação dos diagramas diagramas de seqüência seqüência serve para povoar as classes do sistema de operações.
5.7.2.
Integração entre os diagramas diagramas de classes classes e estados
O diagrama de estados representa a dinâmica interna de uma classe. Ele expõe como a classe cl asse reage aos estímulos estímulos externos externos que recebe. rece be. Estes estímulos, estímulos, eventos no diagramas de estados, devem ser operações internas da classe que são acionadas pelas classes externas. Podem ser operações públicas ou privadas. As operações públicas permitem permitem que eventos eventos extern externos os estimulem estimulem as classes. clas ses. As operações operaçõe s privadas priva das podem ser utili utilizadas zadas para implemen implementar tar eventos internos, internos, estados e stados de ação, condições e outras outras situções onde é necessário ocultar do mundo exterior uma operação. O exemplo do item de estoque, apresentado no item 5.4.1, é um bom exemplo desta integração.
6. Estudo de Casos Este capítulo capít ulo reapresenta reapresent a os exemplos desenvolvidos desenvolvi dos nos capítulos anteriores ante riores aplicando, de modo prático, os conceitos da modelagem orientada a objetos. Objetiva-se a revisão dos diagramas e modelos propostos aplicados em exemplos simples que são levados lev ados à implementação em protóti protótipos pos executáveis. executávei s.
6.1.
Introdução
Este livro propõe um conjunto de modelos que descrevem sistemas orientados a objeto. Em conjunto com a introdução de cada modelo foram apresentados diversos estudos de casos, que serviram de exemplo para a aplicação prática das técnicas e das notações propostas no texto. Este capítulo retoma cada um destes exemplos, apresentando os modelos detalhados que levam estes exemplos à sua implementação na linguagem Java de programação. As implementações destes exemplos foram desenvolvidas com um uma finalidade didática e não o desenvolviment desenvolvimentoo comercial dos sistemas, ou mesmo resolver integralmente os problemas propostos. Para tornar os sistemas sistemas mais sim si mples, não se pretende pretende apresent apr esentar ar a integração integração com bancos bancos de dados, nem interfaces gráficas sofisticadas que seriam exigências naturais em sistemas deste tipo. Os sistemas desenvolvidos são:
Os diagramas da UML apresentados neste livro foram obtidos com a ajuda de uma ferramenta CASE, e os códigos dos programas foram escritos na linguagem Java com uma uma IDE apropriada. apropri ada. Os exem e xemplos plos desenvolvidos para este livro li vro encon e ncontram tram-se -se disponíveis para serem s erem execut executados ados on-line, pela internet como como descreve o apêndice, onde também se encontram os códigos destas aplicações.
6.1.1.
Estrutura Estrutura de camadas dos sistema sistema
Os sistem sis temas as com co mputacionais putacionais podem po dem ser divididos divi didos em 3 camadas: camadas: apresentação, negócio neg ócio e persistência. per sistência. Em geral geral,, a modelagem conceitual conceitual indica a vocação da classe. cl asse. Usando a notação da UML , podemos organizar as camadas em pacotes de classes:
Figura 83 - Estrutura de camadas de um sistema, (a) notação da UML para as camadas de um sistema sist ema A implementação de um modelo orientados a objetos depende de uma estratégia para definir as camadas de apresentação e camada camada de persistência. pers istência. A camada camada de negócios neg ócios está, em geral, descrita descr ita pelo modelo. Mas as camadas camadas de apresentação e de persistên persi stência cia precisam pre cisam ser projetadas. A UML UML pode ser utilzada para definir definir algu al gunns elementos presentes na interface, como os exemplos desenvolvidos aqui puderam mostrar. ostra r. Entretanto, Entretanto, a UML sozinha sozinha não é suf s ufici iciente ente para modelar odel ar um sistem sis temaa completam completament ente, e, outros diagramas diagramas podem p odem ser utilizados para descrever descre ver as interfaces interfaces e o modelo de dados (Ambler, (Ambler, 2001).
6.2.
Estudo Estud o de Caso: Sistema Sistema de Vendas de Loja
Os capítulos 2 e 3 apresentam o exemplo de um sistema de apoio às vendas de uma loja. Este sistema sistema informa informa ao caixa se um produto produto pode ser vendido à crédito cr édito para um client clie nte, e, em fun função ção do preço p reço do produto produto e do crédito crédi to do client cli ente, e, obedecendo as regras de negócio da loja. Este exemplo hipotético é usado para mostrar os fundamentos da orientação a objetos, obj etos, como como a comun comunicação entre entre classes cl asses por meio de troca de mensagens ensagens e o polimorf p olimorfism ismo. o. No capítu capí tulo lo 2 são desenvolvidas des envolvidas as a s regras re gras de negócio e modelado o sistema sem o formalismo da UML, que é introduzido no capítulo 3 untamente com o diagrama de casos de uso e o modelo de contexto. Neste capítulo são apresentados os modelos conceitual e detalhado da implementação deste sistema.
6.2.1.
M odelo Concei Conce itual
O modelo conceitual do sistema de vendas da loja resulta da análise dos casos de uso e dos processos ali descritos. Desta análise identificam-se os principais personagens personagens do sistem sis tema, a, mostrados mostrados na figu figura ra abaix abai xo, que é um uma represent repres entação ação formal formal das classes e dos seus relacionamentos: As classes identificadas no sistema de vendas da loja são:
POS
que representa a interface entre entre o usuário usuário (Caixa) e o sistema, sistema, é tipicamente uma classe de apresentação
Produto
represent repres entam am os produ prod utos comercia comercializados lizados pela pel a loja, loj a, uma uma classe cla sse de negócio
Clien liente
repr repres esen enttam os clien clienttes cada cadast strad rados os pe pela la loja, loja, uma clas classe se de neg egóc ócio io
Loja
represent repres entaa a loja, com um um lista lis ta de produt pr odutos os e client clie ntes, es, uma uma classe cl asse de negocio
BDLoja
auxiliaa loja auxili loj a para par a armazenar armazenar a lista li sta de client cl ientes es e produtos, produtos, exemplo exemplo de uma classe cla sse de persistên persi stência. cia.
No POS o caixa pode se comun comunicar icar com co m a loja que identifica identifica para par a o caixa o Produto Produto que o cliente deseja comprar. comprar. Com base no preço do produto e no crédito do cliente, cl iente, o sistema pode autorizar a venda parcelada. A loja possui as informações de crédito e do preço arm ar mazenadas azenadas em um banco de dados, represent represe ntado ado pela classe c lasse BDLoja, 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.
M odelo Detal Deta lhado
O modelo modelo detalh de talhado ado do sistem s istemaa de vendas ve ndas da loja loj a é conseguido conseguido pela pel a análise detalhada da dinâmica dos processos que estão envolvidos nas vendas. A análise se realiza reali za com os diagram di agramas as de interação, interação, que permitem permitem distribuir, ou o u verificar a distribuição, das d as funcionalidades funcionalidades do sistem si stemaa pelas pel as classes cl asses.. Terminada Terminada a modelagem, odelagem, as classes possuem todas as operações necessárias para atender os objetivos do sistema.
Diagramas Diagramas de Interação A partir do modelo conceitual é possível simular os processos dinâmicos envolvidos no sistema, para distribuir as operações pelas classes. O diagrama de seqüência descreve des creve a série séri e de mensagen mensagenss que são trocadas entre entre os objetos do sistem s istemaa em um determinado cenário. Seguem-se os cenários de inicialização da Loja e de autorização autorização das vendas.:
Figura 85 - Seqüência de autorização de vendas da loja O cenário de inicialização i nicialização da Loja é descrito descri to no no diagrama diagrama de seqüência da figura figura acima. Nele, a classe clas se POS, represent repr esentando ando o caixa da loja, loj a, cria cri a uma uma instância instância da Loja, buscando buscando na na classe clas se BDLoja, BDLoja, que representa o banco banco de dados as inf i nform ormações ações da loja l oja para criar cr iar a lista l ista de client cli entes es e a lista li sta de produtos. produtos. Estas listas são criada c riadass a partir dos dados de client clie ntes es e produtos produtos arm ar mazenados azenados na classe clas se BDLoja, BDLoja, e das respostas r espostas aos
métodos getListaC e getListaP desta mesma classe. Ao final deste cenário, a loja está pronta pronta para iniciar inicia r as operações oper ações de venda solicitadas soli citadas pela rede de POS. O cenário mais importante importante no sistema sistema da loja é o cenário de vendas, que envolve envolve os casos de uso: Identificar Cliente, Identificar Produto e Autorizar o Parcelamento. Estes casos de uso podem ser representados r epresentados por um único diagrama diagrama de seqüência que mostra mostra a autorização autorização do parcelamen par celamento to de um uma venda. Nele, o caixa solicita soli cita à Loja, pelo POS, os dados do cliente, informando o número do seu CGC. A loja busca este nome na lista de client cl ientes es e retorna ao POS. De posse do client clie nte, e, o POS recupera rec upera o nome nome do cliente c liente e exibe na interface. interface. O POS solicita agora os dados do produto produto para a loja, loj a, com base no código 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 descrição do produto. produto. Identificado Identificado o cliente e o produto, produto, o POS POS inform informaa o número número de parcelas par celas desejadas deseja das e pergunt perguntaa para o produto se a venda está aprovada. apr ovada. O Produto faz faz as considerações com base nas regras de negócio da loja, envolvendo o crédito do cliente e o preço do produto, para aprovar, ou não, a venda.
Figura 86 - Diagrama de Seqüência da autorização da venda
Diagrama Diagrama de Classes Classes Detalhado D etalhado O diagrama diagrama de classes, class es, no modelo modelo detalhado, integra integra os diagram di agramas as de interação interação dos processos process os e serve serv e de base para par a a construção construção do software software.. As classes podem pod em ser
traduzidas, diretamente no código correspondente, adotando uma linguagem de programação programação orient ori entada ada a objetos. A mont montagem agem do diagrama diagrama de classes, clas ses, além alé m da distribuição das fun funcionalidades, cionalidades , estabelece estabele ce o relacionam relac ionament entoo existente existente entre entre as classes. O relacionamento segue, aproximadamente, o que foi proposto pelo modelo conceitual, mas com alterações que permitam a implementação. Neste ponto ponto do detalham detalhament entoo são inseridas inserida s operações operaçõe s de acesso acess o para todos os atributos atributos privados pr ivados da classe. cl asse. Usando-se o prefixo get get seguido seguido do nome nome do atributo atributo para as operações de recuperação dos dados , e o prefixo set para as operações de atribuição. A Loja Loja é composta composta de uma uma lista l ista de objetos da classe class e Client Clie ntee chamada chamada listaC l istaC e de uma uma lista l ista de objetos da classe class e produ prod uto chamada chamada listaP. l istaP. Também Também compõe compõe a classe class e Loja a classe BDLoja que é uma classe auxiliar, criada para recuperar os dados destas listas arquivados de um modo persistente, a cada execução do sistema. A Loja, como mostra a figura, figura, usa uma uma composição para represent repres entar ar a associação associ ação com as listas li stas e com a classe class e auxili auxiliar, ar, para par a representar repr esentar um uma forte dependência dependência ent e ntre re estas es tas classes. class es. Analisando Anali sando as regras do negócio estabelecidas estabeleci das pela pel a Loja no caso de uso Ident Identificar ificar Cliente, criou-se uma nova classe chamada ClienteVIP. No diagrama de classes esta relação relaç ão é represent repres entada ada por uma uma herança da classe cl asse ClienteVIP ClienteVIP da classe cla sse mãe Client Cli ente. e. A classe class e filha possui uma uma condição de crédito cr édito diferenciada, implem implement entada ada na operação oper ação getCredito, que retorna o dobro do crédito atribuído para esta classe. A operação getCredito da classe Cliente é sobreposta pela classe ClienteVIP em um exemplo de polimorfismo. polimorfismo.
Figura 87 - Diagrama de classes de negócio do sistema
Projeto Projeto da Interface As classes de negócio são projetadas pela análise do processo de negócio, e os diagramas da UML servem bem para este fim. No entanto, as classes de apresentação necessitam de um projeto proje to diferenciado. Neste tipo de classe cla sse a característica caracterí stica mais mais importante é manter o controle do processo de comunicação entre o usuário e o sistema. A classe de apresentação deve apresentar as informações que o usuário precisa e os meios para ele el e agir sobre sobr e o sistem s istema. a. No exemplo exemplo da loja, o usuário usuário precisa precis a informar informar o código do produto e o CGC do cliente para recuperar da loja o cadastro do produto e do cliente. Para conseguir a aprovação da venda, depois de identificado o produto e o client clie nte, e, o usuário precisa preci sa inf i nform ormar ar o número número de parcelas. parcel as. A interface, interface, descrita descr ita a seguir, seguir, apresenta apr esenta os campos campos de texto texto para a entrada do código, do CGC e do número de parcelas e os botões (PRODUTO, CLIENTE e PARCELAS) para que o usuário possa acionar o sistema e processar os dados de entrada. entrada. Para Par a que o usuário usuário verifique que a operação operaçã o foi um sucesso, ele dispõe de campos de saída com a descrição do produto, nome do cliente e, finalmente, se a venda foi aprovada aprovad a ou não.
Figura 88 - Interface Interf ace POS do do sistema sist ema de vendas da loja Adicionalment Adicionalmente, e, foi inserido um boão Lim Limpar par para limpar os campos campos de dados dad os de entrada e facilitar uma nova entrada.
Figura 89 - Diagrama de Estado da Interface POS Uma forma forma de modelar o controle da comun comunicação icação é representar r epresentar os possíveis possíve is eventos que ocorrem na interface na máquina de estado de um diagrama de eventos. Cada estado do diagrama diagrama representa re presenta um uma situ si tuação ação em e m qua a classe cla sse se s e encontra, encontra, e cada c ada evento representa uma ação, promovida pelo usuário, para mudar o estado. A figura do diagrama de estado da interface POS mostra que ela é criada em um estado de espera dos dados da dos perm per manente. anente. O usuário usuário pode realizar reali zar 3 eventos neste neste estado, es tado, corresponden corres pondente te aos 3 botões disponíveis na interface. interface. Cada botão depende que uma uma inform informação ação seja se ja fornecida, para par a provocar provoc ar a mudan udança ça de estado, que passa para par a um estado de ação onde a classe de negócio é chamada e volta para o estado de espera. Comparando-se Comparando-se o diagrama diagrama de estados acim aci ma, como a interface interface proposta pr oposta é possível p ossível analisar se a interface interface serve ser ve bem à finalida finalidade de desejada desej ada de acionar o sistem si stema, a, ao mesmo mesmo tempo tempo que se analisa as sua precisão prec isão por meio do diagrama. diagrama.
Figura 90 - Diagrama de classes detalhado do sistema siste ma da loja A interface interface POS pode ser in i ncluída no modelo modelo de classes, cl asses, agregando agregando à ela, além da classe class e Loja, um objeto da classe class e Produ Prod uto: oProduto e um objeto da classe class e Client Clie nte: e: oCliente que representam, respectivamente, o produto e o cliente presentes na transação de venda. A integ integração ração da classe c lasse POS com as classes clas ses de negócio negócio perm per mite a criação criaç ão de um diagrama de classe completo do sistema, representado na figura.
Expansão do sistema Para demonstrar a vantagens de manutenção e expansão dos sistemas orientados a objeto, pode-se propor uma expansão no sistema da loja, implantando uma nova regra de negócios negócios ao sistem si stema. a. Pode-se Pode- se partir pa rtir de uma uma necessidade necessida de do departament departamentoo de marketing desta loja, que decidiu colocar um produto em oferta. A regra para esta situação é a seguinte:
Colocar um produto, da lista de produtos da loja, em oferta quer dizer que ele ode ser vendido em até 3 parcela fixas, independentemente do crédito do seu comprador. Analisando o modelo de objeto do sistema, observa-se que esta regra irá implicar
que a verificação verificaçã o da aprovação aprovaçã o do parcelamento parcelamento da venda venda será diferente se o produto produto for um produto normal ou for uma oferta. Assim pode-se criar uma nova classe de produtos, produtos, que herda herda as caracterís ca racterísticas ticas da classe clas se produto e é cham chamada ada de Oferta, como como mostra o diagrama
Figura 91 - Detalhe do diagrama da classe Oferta Ofe rta Na classe Oferta a aprovação da venda é reformu reformulada para par a acomodar acomodar esta nova regra. Na classe Oferta também são criadas uma operação construtor Oferta() e uma operação de saída sa ída toString toString() () reformulada. reformulada. A nova operação de aprovação isAprovado() possui os mesmos parâmetros de entrada entrada da operação op eração anterior anterior,, de modo que ela el a substitui substitui integralm integralment entee a operação operaçã o anterior quando a classe é uma Oferta. Assim, quando se chama a operação de aprovação aprovaçã o em um um objeto da classe class e Oferta a sua forma forma alterada al terada é acionada. A nova nova operação, oper ação, descrita des crita a seguir, seguir, mostra que caso o número número de parcelas parcel as de venda (n) for maior do que 3, em um produto em oferta, a regra que está valendo é a de um produto produto comum comum e para isso i sso se aciona aci ona o método método super.isAprova super.isAprovado do da classe clas se mãe (super). No caso de um produto em oferta, se com um número de parcelas (n) for menor ou igual igual a 3, a operação aprova a venda. Assim a nova operação de aprovação apro vação 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 super.isAprovado(n,c)); )); } }
Para testar esta nova regra do sistema, sistema, vamos colocar o produt pro dutoo 104 em oferta:
104 Piano de Caud Caudaa R$ 5.000,00 5.000,00
Isto é feito alterando a criação deste produto na classe de acesso ao banco de dados: BDLoja, como a Oferta á também um Produto, devido à herança, ela pode ser armazen armazenada ada na lista de Produtos Produtos (listaP), (li staP), pelo comando: comando:
listaP[4] = new Oferta(104,"Piano Oferta(104,"Piano de Cauda",5000); se o produto produto não esivesse esivess e em oferta, oferta, o client cl ientee de código c ódigo 5000, que possui um crédito de R$ 300,00 não poderia adquirí-lo em 3 parcelas, porque o saldo da compra certament certamentee seria ser ia superior s uperior ao seu crédito:
5000 50 00 Miles Miles Dav avis is R$ 30 300, 0,00 00
Mas com a oferta o sistema de vendas autoriza o parcelamento, como mostra a interface com o exemplo desta operação :
Figura 92 - Exemplo da interface do sistema sis tema com venda de ofert ofertaa
6.3.
Estudo Estud o de Caso: Jogo da Forca
Este sistema descreve uma aplicação completa, com uma interface gráfica, apoiada nas classes class es de neg negócio ócio identificadas identificadas na modelagem modelagem conceitual conceitual desenvolvida no item 4.4. Utiliza-se Utiliza-se este exemplo exemplo para demonst demonstrar rar a importância importância da separação se paração das cam ca madas de negócio, negócio, de apresen aprese ntação e da camada camada de persistên persi stência cia em e m um projeto proje to de software e as possibi pos sibilida lidades des da modelagem nestes nestes casos. ca sos. O sistem s istemaa é detalhado em duas implementações, uma implementação básica, onde é gerada uma aplicação local para testes das classes de negócio, e uma implementação “ web” onde a aplicação é expandida expandida para operar no ambiente ambiente da internet . No exem exemplo plo desen dese nvolvido volvid o no no capítulo 4, foram foram identificadas identificadas as a s classes clas ses de negócio: negócio:
6.3.1.
M odelo Detal Deta lhado da Implementa Implementação ção Básica Básica
Para detalh de talhar ar a implemen implementação tação básica básic a do jogo j ogo da forca, a qual será ser á usada para testar as classes cl asses de negócio negócio ant a ntes es de se implement implementar ar o jogo j ogo em rede, é necessário fazer fazer o design da interface desta implementação com o usuário. Na implementação básica do ogo da forca não se utiliza recursos gráficos. O boneco é representado por uma figura simples desenhada com caracteres em uma matriz de 3 x 3 como mostra o esquema abaixo:
Também nesta implementação, as letras da palavra secreta que ainda não foram identificadas são marcadas com traços do tipo : “_”. Por exemplo, se a palavra secreta escolhida foi namorado, e já foram arriscadas as letras “ a”,”m” e “r”, a palavra descoberta descober ta fica sendo apresentada ao jogador como : _ a m _ r a _ _ , , onde as letras ainda não descobertas são substituídas pelo traço.
Diagramas de Seqüência Os diagramas de seqüência são úteis na definição detalhada das classes e na definição definição de como se realiza re aliza a comun comunicação icação entre entre elas. e las. Tomando Tomando os casos caso s de uso: Novo Jogo Jogo e Chut Chutar ar Letra, Letra, pode-se pode-s e analisar a seqüência s eqüência de eventos eventos que é execut executada ada nos cenários principais destes casos de uso, identificando as operações necessárias para se completar cada processo, e que deve estar presentes nas classes.
Figura 93 - Diagrama de Seqüência do caso de uso: Novo Jogo A cada vez que o usuário solicita à Forca que crie um novo jogo, ela constrói uma instância das classes Palavra e Boneco para iniciar o jogo. As operações Jogador(), Palavra() Palavr a() e Boneco() são sã o os chamados chamados métodos métodos contrutores, contrutores, que instanciam instanciam as classes cla sses na criação dos objetos. Solicita então que a classe Palavra escolha uma palavra secreta, que ela vai buscar na lista de palavras. A Forca então cria uma instância do Jogador e prepara a interface do jogo, desenhando o boneco e a palavra secreta com traços, para o jogador tentar descobrir as letras.
Figura 94 - Diagrama de Seqüência do Caso de Uso: Uso: Chutar Letras O usuário usuário do jogo j ogo sugere sugere um uma letra le tra que é capturada capturada pela p ela Forca For ca e passada pa ssada para a classe class e Jogador, J ogador, por meio da mensagem mensagem chu chutaL taLetra() etra() enviada pela pel a Forca. For ca. O jogador então então acrescenta acr escenta a letra na lista de letras já j á chutadas chutadas (addLetrasChut (addLetrasChutadas). adas). O Jogador, pergunt perguntaa para a classe cl asse Palavra Pal avra se a letra l etra está na na palavra palavr a (letraNaPalavra). (letraNaPala vra). A Palavra Palavr a é incumbida de verificar de a letra está na palavra e, se estiver, acrescenta a letra nas posições posiçõe s corretas corre tas da palavra secreta. s ecreta. Caso a letra não esteja na na palavra, palavr a, a classe class e Palavra Palavr a solicita sol icita ao objeto boneco que acrescent acres centee mais uma uma parte par te ao desenh des enhoo (addParte). É importante importante verificar, veri ficar, ao a o se construir construir um diagrama diagrama de seqüência que todas as mensagens trocadas entre as classes tenham uma operação correspondente na o objeto de destino. de stino. A Forca ao final final de cada letra l etra chutada, chutada, deve desenhar desenhar as letras le tras chutadas chutadas
(getL (getLetrasChut etrasChutadas) adas) a palavra pal avra (palavra.desenh (palav ra.desenha) a) e o boneco (boneco.desenha), (boneco.desenha), para pa ra apresentar ao usuário que irá continuar o jogo. Antes porém, a Forca pergunta para o ogador 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 pergunt perguntaa para a palavra pal avra se ela el a está completa completa (isCompleta), finalizan finalizando do o processo, process o, que é repetido a cada letra chutada.
Diagrama Diagrama de Classes Classes Detalhado D etalhado O jogo da forca pode ser considerado c onsiderado um pacote, onde se encontram encontram as classes cl asses de negócio, e que é utilizada pelo usuário externo para jogar com o computador. Este sistema sistema é represent repres entado ado pela pel a figura figura abaixo: a baixo:
Figura 95 - Representação do jogo como um um sistema Os diagramas diagramas de seqüência aju aj udam a completar completar o diagrama diagrama de classes class es com as operações operaçõe s e as a s suas assinat assi naturas, uras, garantin garantindo do que as classes cl asses tenham tenham todas as operações oper ações necessárias para executar os processos do sistema, definidos nos cenários dos casos de uso. O resultado, na implementação básica do Jogo da Forca é mostrado no diagrama de classes detalhado a seguir. O diagrama diagrama de classe c lassess detalhado serve para in i niciar icia r o desenvolvim d esenvolviment entoo do sistem si stema, a, porque cada classe class e será traduzida traduzida em um programa programa Java. Deve-se detalh de talhar ar cada operação e atributo definindo definindo o seu tipo, valor inicial, tipo de retorn r etornoo e parâm par âmetros etros dos atributos. Deve haver uma relação biunívoca entre o código e o diagrama. Isto quer dizer que o diagrama diagrama e o código, no nível nível das definições das da s classes, cl asses, se equivalem equivale m. Cham Chama-se a-se de engenharia de produção a geração de código, em linguagem de programação, a partir do diagrama. diagrama. Chama-se Chama-se de engenh engenharia aria reversa revers a a produção do diagram di agramaa a partir do código códi go em linguagem de programação. Estas conversões são facilitadas pelo uso de uma ferramenta CASE para automação do projeto de software.
Figura 96 - Diagrama de classes da implementação Básica
Código Java da classe Boneco Para exemplificar a equivalência entre o código e o modelo, pode-se analisar o código de uma uma das classes cl asses do diagrama diagrama de classes. clas ses. Este é o código, có digo, na na lin li ngu guagem agem Java, que é equivalente equivalente à classe c lasse Bon Boneco: eco:
public class Bon Boneco eco { private int parte = 0; private char[][] Dforca; Dforca; private void limpaForca () {
} public void addParte () { } public String desenh dese nhaa () { } public boolean isCompleto isCompleto () { } public Bon Boneco eco () { } } A modelagem dinâmica ajuda o projetista a definir como devem ser construídos os métodos, e a detalhar a troca de mensagem entre as classes. Os diagramas de estado exibem as relações re lações entre entre as mensagens ensagens que que a classe c lasse recebe e emite, emite, e os seus processos processo s internos. internos. Mostra-se Mostra-se o ciclo cic lo de vida das da s classes cla sses do sistem si stema, a, que se integram integram para formar 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 ogador é criado no estado ChutandoLetras. O evento que altera os estados é o evento chutaLetra, que recebe uma letra entrada pelo usuário para teste. Quando ocorre o evento chutaLetra, chutaLetra, o jogador continua continua no estado Ch Chut utandoletra andoletras, s, mas manda uma uma mensagem para ele mesmo adicionar esta letra na lista de letrass chutadas (addLetraChu (addLetraChutada). tada). Se a palavra pal avra estiver es tiver completa completa o jogador ganhou ganhou,, se o boneco estiver com c ompleto pleto ele perdeu, estas situações são estados e stados verificados veri ficados com os métodos métodos ganhar() gan har() e perder(), perder( ), respectivamen r espectivamente; te;
Figura 97 - Diagrama de estados da classe Jogador J ogador Ao enviar a a mensagem perguntando se a letra está na palavra, o jogador faz com que a palavra tome uma decisão: se a letraNaPalavra for verdadeira ela insere a letra na palavra secreta. s ecreta. Se a letraNaPalavra for falsa ele manda o boneco acrescentar uma uma parte. É possível possí vel se detalh de talhar ar um estado, em ativida atividades des ain ai nda mais internas. internas. Por exemplo, exemplo, o estado de chutandoLetras é um estado de ação 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 diagrama observa-se observa -se que a entrada entrada do evento chut chutaLet aLetra ra aciona aci ona a ação interna interna
de adicionar adi cionar letras na operação oper ação addLetrasChu addLetrasChutadas e com base na definição definição se s e a letra l etra está na palavra, obtida pela mensagem letraNaPalavra enviada para a classe palavra, toma-se a decisão de adicionar uma parte ao boneco, enviando a mensagem addParte ao boneco, ou não. Term Terminadas inadas estas ações internas, internas, a classe clas se Jogador permanece permanece esperando um novo evento chutaLetra, e pode enviar os sinais de ganhar ou perder. Este diagrama diagrama de estado e stado é equivalente ao código java reproduzido a seguir: seguir:
public char chu chutaLetra taLetra (char letra, Palavra palavra, Boneco boneco){ boneco) { addLetrasChutadas(letra); if (!palavra.letraNaPalavra( (!palavra.l etraNaPalavra(letra)) letra))
boneco.addParte(); }
return(letra); }
Diagrama de Estado da classe Boneco A classe class e Boneco possui 3 estados bem definidos: definidos: um estado inicial, inicial , onde nada do boneco foi foi desenhado desenhado na forca, forca, um estado onde as partes do boneco boneco estão sendo desenhadas uma a uma, e finalmente outro estado, quando o boneco está completo, e o Jogador perdeu perde u o jogo. O atributo atributo que controla controla este estado é o número número de partes do Boneco Bon eco que já foram desenhadas, desenhadas, representado r epresentado pela variável variáv el parte. pa rte. O evento que que coloca o Boneco no no estado inicial é o even eve nto de construir construir o objeto ou o evento evento limpaForca. A troca de estados é feita pelo método método addParte, addPar te, que que adiciona adi ciona uma uma parte par te do boneco cada vez ve z qu quee é acionada. ac ionada. Estando Estando o Boneco com mais de 6 partes par tes ele é considerado completo, o diagrama abaixo mostra estas transições em um diagrama de estado:
Figura 99 - Diagrama de estados da classe Boneco.
Detalhamento da classe Forca A classe forca implementa o método principal (main) acionado quando da execução do prog pro grama. rama. Ao ser inicializada iniciali zada a Forca ela envia uma uma mensagem mensagem para a classe cl asse palavra palavr a escolh escol her uma uma palavra palavr a secreta. A partir dai, entra em um ciclo cicl o que term termina ina quando o jogador ganhar ou perder. A cada volta do ciclo executa o desenho do boneco e da palavra pa lavra secreta, secre ta, mostrando mostrando ao jogador o que já foi descoberto, assim as sim como como as letras que já foram testadas. Cada letra chutada é passada para a classe Jogador que irá processá-la process á-la,, verificando se o jogador ganh ganhou ou ou perdeu, perdeu, retornando retornando ao início do ciclo. ci clo. Este processo pode ser representado pelo diagrama de atividades que se segue:
Figura 100 - Diagramas Diagramas de atividades ativi dades do programa Forca
o extrato de program pr ogramaa Java Ja va abaixo ab aixo apresent apres entaa uma uma possível pos sível tradução tradução deste d este diagram dia grama, a, onde se utiliza a classe class e JOpt J OptionPan ionPanee do pacote javax.swing ja vax.swing para implement implementar ar a interface com o usuário, que é toda na forma de um texto.
public static void main(Strin main(Stringg arg[]){ arg[]){ char letra; String tela=""; palavra.escolheSecreta(); do {
// // constroi constroi o desenho desenho da forca e da palava tela = boneco.desenha()+"n"
+palavra.desenha()+"n"
+jogador.getLetrasChutadas(); // // captura captura uma uma letra entrada entrada pelo usuario letra =JOptionPane.showInputDialog(tel =JOptionPane.showInputDialog(tela).toCharArr a).toCharArray()[ ay()[0]; 0]; // // Envia mensagem ao jogador para entrar com letra no jogo jogador.chutaL jogador.chutaLetra(letra, etra(letra, palavra, palavr a, boneco); }while(!(jogador.ganhar(palavra)||jogador.perder(boneco)));
if (jogador.ganh (jogador.ganhar(palavra)) ar(pal avra)) {tela {tel a = tela + "n Parabens! Par abens! gan ganhou hou!"; !"; }; if (jogador.perder(boneco)) (jogador.perder (boneco)) {tela {tel a = tela + "n Qu Quee pena, perdeu! perd eu!";}; ";}; JOptionPane.showMessageDialog(null,tela, "Jogo da Forca",JOpti Forc a",JOptionPane.IN onPane.INFORMA FORMATION_M TION_MESSAGE); ESSAGE);
System.exit(0); }
Executando-se o comando para executar o sistema:
C:Java Forca Obtém-se uma interface para o jogo, com um pedido para chutar uma letra, de modo semelhante à interface mostrada na figura:
Figura 101 - Interface Interfac e para jogar a forca
6.3.2.
M odelo Detal Deta lhado da Implementa Implementação ção WEB
Os modelos orientados a objeto tem como uma das grandes vantagens a características caracterí sticas de reusabilidade reusabili dade e a facilidade facili dade de expansão expansão e manu anuten tenção. ção. Este exemplo exemplo demonst demonstra ra a reusabilidade reusabili dade do código orientado a objeto, criando cri ando um uma versão vers ão para par a a do jogo da forca reaproveitando grande parte do código da versão básica. A internet do nova versão web do jogo j ogo inclui inclui duas novidades: 1.
Um interface gráfica baseada base ada na tecnologia de Java Applet, Apple t, e
2.
Uma classe class e que permite permite ler as listas de palavra palavr a pela internet .
Estas modificações modificações servem para avaliar aval iar a facilidade facili dade em se dar manut manutenção enção em sistemas sistemas desenvolvidos des envolvidos sob s ob a orient or ientação ação a objetos, e a grande grande reutilização result res ultant antee do encapsulamento encapsulamento das classe cla sses. s. O novo novo sistem sis temaa chama-s chama-see de forcaWEBDB, como mostra o diagrama abaixo, onde se observa a dependência de um sistema e outro.
Figura 102 - Diagrama Diagrama do sistema ForcaWEBDB ForcaWEBDB e suas dependências Para criar uma versão gráfica da forca é necessário 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 modificação modificação na implem implement entação ação básica bá sica para levar l evar o jogo para a internet é alterar a classe Palavra. Optou-se por criar uma nova classe, chamada de PalavraDB para implement implementar ar a camada de persistência da classe clas se Palavra, Palavr a, onde o sufix sufixoo DB lembra DataBase. Como foi visto é comum isolar em camadas as funções de persistência, que são mais sujeitas a alterações.
A idéia é re-escrever o método da classe Palavra que faz acesso à lista de palavras. O método método que que escolhe esco lhe a palavra palav ra secreta se creta lê a lista li sta de palavras pal avras de um arquivo texto texto e seleciona, selec iona, aleatoriamente, aleatoriamente, um uma palavra. pal avra. Esta leitura l eitura é feita pela classe c lasse PalavraDB Palavr aDB que que recebe como como parâmetro parâmetro de entrada entrada o endereço de locali l ocalização zação do arquivo na internet . Este endereço é parâmetro parâmetro de entrada entrada da Applet, o que permite permite que o jogo j ogo possa receber diferentes diferentes listas li stas de palavras pa lavras,, implement implementando ando diferentes diferentes níveis de dificuldade, ou jogos temáticos temáticos como palavras palavra s ligadas l igadas a animais, animais, países, paíse s, plant pla ntas, as, etc... O diagrama diagrama abaixo abai xo mostra mostra a dependên de pendência cia que foi foi então criada entre entre a classe class e Palavra Pala vra e a classe PalavraDB, implementada na operação escolheSecreta().
Figura 103 - Exemplo de implementação implementação da camada de persistência persist ência
Criar uma interface gráfica O que muda na classe que representa o boneco na implementação básica, para o boneco da implemen implementação tação para internet é é apenas a sua aprentação aprentação gráfica, as propriedades propri edades de gerenciar o número número de partes desenh des enhadas, adas, e verificar veri ficar se está completo completo deve ser se r o mesmo. mesmo. Todo código códi go desenvolvido para a implement implementação ação básica bás ica deve d eve ser reutilizado na nova implementação.
Figura 104 - Criação de uma uma classe de Boneco para web Assim, Assim, para reutili reutilizar zar o código existente existente pode-se utilizar da capacitade c apacitade de herança herança das classes cl asses e criar cri ar uma uma nova classe, class e, chamada chamada de Bon BonecoWeb, ecoWeb, que é filha da classe class e Boneco. Bon eco. Esta nova classe cl asse iá subst s ubstitu ituir ir a classe cl asse boneco na implemen implementação tação da forcaWEBDB, sobrescrevendo o método desenha() que desenha o boneco na forca.
Exemplo da interface resultante A nova implem implement entação ação da d a classe cl asse Forca utili utiliza za as mesmas mesmas classes cl asses Jogador e Bon Boneco eco da im i mplementação plementação anterior, acresci a crescida da das da s classes cl asses Bon BonecoWEB ecoWEB e PalavraDB, Pala vraDB, com um uma pequena pequena alteração na classe Palavra. Palavra . O resultado resultado final final é um novo diagrama diagrama de classes, clas ses, esquematizado a seguir, que implementa o novo Jogo da Forca com uma nova interface. Nesta nova nova implement implementação ação as classe cl asse ForcaWEB For caWEBDB DB e BonecoW BonecoWEB EB form formam am a camada camada de apresentação, a cam c amada ada de neg negócios ócios continu continuaa formada formada pelas pe las classes class es Jogador, Palavra e Boneco, e a camada de persistência é implementada pela classe PalavraDB:
Figura 105 – Classes Classes da implementação web e divisão divis ão de camadas camadas Nesta nova nova implement implementação ação é possível possí vel se represe r epresenntar com um diagrama diagrama de componen componentes tes a versão ve rsão final final do jogo, que para ser s er jogado j ogado na na internet requer requer que um servidor receba uma página no formato html (index.html) com o código da Applet (ForcaWEBDB.class) e que é transferida para o processador do cliente pela internet . Os componentes que implementam o jogo são representados no diagrama abaixo:
Figura 106 - Diagrama Diagrama de componentes componentes do jogo da forca No diagrama diagrama de componen componentes tes estão relacion relacio nados os arquivos ar quivos que que fazem fazem parte do ogo e suas dependências. Os arquivos possuem extensões que caracterizam os tipos de componentes. Neste diagrama identificamos a página html, as classes java e o arquivo texto da lista de palavras. Estes component componentes es são s ão recebidos re cebidos por um servidor servi dor web (webserver ) que permite que clientes remotos, munidos de um navegador ( browser ) possam pos sam execut executá-los á-los e jogar a forca. Esta distribuição de componentes é mostrada no diagrama de distribuição abaixo:
Figura 107 - Diagrama Diagrama de distribuição distri buição do jogo da forca O servidor web, em nosso caso, foi implementado no endereço do em um website que se encontra encontra descrito descri to no no apêndice. Neste endereço endereço tem-se tem-se acesso ac esso à págin p áginaa index.htm index.htmll que implementa, implementa, a interface abaixo: abai xo:
Figura 108 - Exemplo de interface para o Jogo da Forca na web
6.4.
Estudo Estud o de Caso: Modelo de um item de estoque
No item 5.4 foi apresentado um um exemplo exemplo de aplicaçã apl icaçãoo do diagrama diagrama de estado na gestão de um item de estoque. Este exemplo é desenvolvido aqui nos seus modelos de contexto, conceitual e detalhado, para também exemplificar uma aplicação da modelagem orientada a objetos.
6.4.1.
Model Mo deloo de Contexto
O sistema em estudo representa um sistema de controle de estoque, comum em almoxerifados de empresas de médio e grande porte. Tais sistemas controlam a quantidade de material em estoque com base nos parâmetros de uso e reposição destes materiais. ateriais . O número número de algoritm al goritmos os e de técnicas para par a se gerenciar gerenciar estoque estoque é grande grande e não faz parte do escopo deste trabalho analisá-los. Como exemplo, toma-se uma regra simples, que é descrita em um modelo de objetos e implementada um um progama de computador, computador, no sistem si stemaa itemDeEstoque. itemDeEstoque.
Figura 109 - Sistema ItemDeEstoque e Diagrama de Casos Casos de Uso
O diagrama descreve as funções do Almoxerife, responsável pelo gerenciamento dos iten i tenss de estoqu e stoquee e de compras compras responsável pela pe la aquisição aq uisição dos itens itens no mercado, mercado, para repor re por o estoque. Resum Resumidament idamente, e, temos temos os casos de uso: Retrir Retriraa Itens Itens do Estoque Estoque e Repoe Itens do Estoque, considerados em nosso exemplo como objetivos do ator Almorexife no sistema de itemDeEstoque.:
Retira Retira Itens Ite ns do Estoque
O Almoxerife Almoxerife atende atende requ req uisições isi ções de retirada de material material do estoque. Se a retirada retir ada deixar o estoque abaixo do estoque mínimo, o almoxerife cancela as próximas retiradas e envia uma mensagem para o setor de compras para repor o material. Após a reposição do material, as retiradas podem ser realizadas novamente.
Repõe Itens do Estoque O Almorexerife recebe o material do setor de compras e aumenta a quantidade de itens itens no estoque. estoque. Toda a reposição reposi ção é feita na na quantidade quantidade de reposiçã r eposição, o, que é definida para cada item i tem..
6.4.2.
M odelo Concei Conce itual
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 operações:
Figura 110 - Diagrama Diagrama de classes do modelo conceitual conceit ual
6.4.3.
M odelo Detal Deta lhado
Para levar este modelo conceitual conceitual a uma uma im i mplement plementação ação deve-se detalhar os processos process os internos internos da classe cla sse ItemEstoqu ItemEstoquee e os eventos de retirar e repor material. Para Par a isso lança-se mão do diagrama de estados desta classe. A classe clas se itemEstoqu itemEstoquee possui pos sui dois estados claramen cl aramente te 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 mínimo. Se a quantidade for menor que o estoque mínimo o estoque está baixo. Estuda-se agora o que os eventos de retirarMaterial retira rMaterial e reporMaterial produzem produzem quan quando do a classe cl asse está e stá em cada um destes estados.
Figura 111 - Diagrams Diagrams de estados da classe class e itemEstoque ite mEstoque A mudança do estoque normal para o estoque baixo ocorre quando há um evento de retirada do estoque e a quantidade final é inferior ao estoque mínimo, neste caso, o comprador comprador deve ser se r acionado para comprar comprar o item. item. Não são autorizadas autorizadas retiradas quando o estoque está baixo, e uma mensagem é enviada ao comprador. A reposição do material coloca o estoque novamente em uma condição normal. É importante observar que a quantidade quantidade de reposição reposi ção deve dev e ser superior ao estoque mínim mínimo, o, para par a garantir garantir que a reposição irá sempre voltar o estoque ao normal. Analisando Anali sando diagrama diagrama acim aci ma é possível possív el escrever e screver um código para os eventos retirarMaterial e reporMaterial. re porMaterial. Cada evento evento será ser á uma uma operação oper ação na classe cl asse Item ItemEstoqu Estoque, e, e será capaz de atender as diferentes mudanças de estado que cada evento produz no diagrama. Os eventos produzem diferentes mudanças de estado em função do estado
original e das condições de disparo, que serão as condicionantes (if) no código da operação. No exem exemplo, plo, existem 3 eventos eventos envolvidos com a retirada de material material que podem ser transcritos no código, como mostra a operação retirarMaterial da classe Item ItemEstoqu Estoque, e, reproduz repr oduzida ida abaixo. a baixo. A operação isBaixo() caracateriza car acateriza o estado da classe class e quando o evento ocorre, e divide o processamento em dois eventos: um quando o estado é baixo (isbaixo==t (is baixo==true) rue) e outro quando quando não está baix bai xo o estoque. estoque. No caso cas o do estoque estoque não ser baixo há ainda duas opções, que são observadas obser vadas no diagrama diagrama como condições de disparo dispar o e reproduz r eproduzidas idas no código: se a quantidade quantidade existente existente é maior maior que a quantidade quan tidade retirada retira da (qtd>n) e se após a retirada retir ada o estoqu e stoquee ficou baixo (qtd
public boolean retirarMaterial(int retirarMaterial( int n) { boolean bool ean ok="fals ok="false;" e;" if (isBaixo()) (isBai xo()) { comprador.setMensagen comprador .setMensagens("Es s("Estoque toque Baixo"); } else { if (qtd>=n) { qtd = qtd - n; ok = true; } if (qtd
comprador.comprar(this);
} }
return(ok); }
de modo modo análogo pode-se traduzir traduzir o evento reporMaterial, que só é processado process ado quando quan do o estado es tado original for de estoque baixo, caso contrário retorna falso na operação reporMaterial:
public boolean reporMaterial (int ( int n) { boolean ok = false; if (isBaixo()) (isBai xo()) { qtd = qtd + getQtdReposicao(); comprador.s comprador.setM etMensag ensagens("m ens("material aterial reposto"); ok = true; }
return(ok); }
Estas operações opera ções resum r esumem em o ciclo de vida vi da da classe class e ItemEstoqu ItemEstoque, e, que necessita ainda das operações de acesso para proteger os atributos. O resultado final está na
classe class e mostrada mostrada abaixo, que que pode ser utilizada em aplicações aplic ações típicas típica s de gerenciamen gerenciamento to de estoqu es toques: es:
Figura 112 - Diagrama Diagrama de classes do sistema si stema itemDeEstoque Para verificar a operação correta desta estrutura foi desenvolvido uma aplicação que executa executa o “gerenciamento” “gerenciamento” de um item de estoque es toque para teste. A classe clas se Almoxeri Almoxerife, fe, que é o cliente da classe ItemEstoque, é implementada com um interface que permite: Retirar uma uma quantidade quantidade de material material (botão: ( botão: Retirar) Repor o estoque estoque do item (botão: Repor) Acompanhar Acompanhar a situação da quantidade quantidade e do estado e stado do item. (Área de texto texto e mensagens) Verificar as mensag mensagens ens de são 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 descrição = Tonner de copiadora qtd = 100
estoqueMínimo estoqueMínimo = 50 qtdReposicao = 70
Figura 113 - Interface Interfac e de teste test e do itemDeEsqtoque Ao se retirar uma quantidade maior (55) que leva ao estoque mínimo temos que o estoque passa a ser baixo e o comprador recebe a mensagem de comprar uma quantidade de 70 para repor o estoque, como mostra a figura.
Figura 114 - Exemplo da comunicação ItemEstoque/Compras Pressionando-se o botão re repor o estoque é acrescido de 70 unidades e se normaliza.
7. Conclusões O livro desenvolve técnicas para representar problemas de software por intermédio de modelos orientados a objeto, seguindo a notação da UML. A abordadem proposta permite permite um um aument aumentoo gradual gradual no nível nível de detalhes da representação. Este aum aumento ento é causa e conseqüência do entendimento do problema que aumenta com a análise e construção construção do software. O objetivo obje tivo final final do modelo de d e software é a apreensão apre ensão da complexidade complexidade do problema p roblema para que seja possível possíve l a construção construção de uma uma solução. sol ução. Este caminho vai depender de uma representação completa, precisa, coerente e com um nível de detalhes suficientemente grande, que possibilite a sua tradução em códigos, a serem integrados integrados nos sistem si stemas as de software software.. Nos capítulos capítulos anteriores foi aprosent apros entada ada a modelagem 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 próprio, e se utiliza de um conjunto de técnicas e de diagram di agramas as da UML para represent repre sentá-lo. á-lo. A tabela abaixo aba ixo resume resume esta es ta combinação:
O desenvolvimento do trabalho mostra que não apenas as classes são importantes em um sistema orientado a objetos, e destaca o importante papel desempenhado pelas mensagens para descrever a dinâmica do sistema. De modo muito parecido com uma conversa entre as classe c lasses, s, o processam process ament entoo de um sistema sistema orient or ientado ado a objetos é um suceder de event ev entos os organizados organizados para pa ra atender os objetivos obj etivos do sistem s istema. a. O leitor não encontrará claramente no livro a organização de um método para
desenvolvimento de software, porque não é esta a sua finalidade. Mas há sim, na forma de apresentação dos assuntos, um caminho natural que pode ser seguido para o entendimento de um problema, e que pode ser percorrido pelo analista como um método. Os melhore melhoress exemplo exemploss deste cam ca minho natural natural são os estudos de caso, cas o, que se utilizam da mesma seqüência de passos para desenvolver um sistema. Cada problema exigirá, no entanto, mais de um modelo do que de outro. A finalid finalidade ade para par a qual se está e stá modelando modelando condiciona a importância importância que se deve dar aos modelos. Um analista de negócio, por exemplo, que está envolvido nas primeiras etapas da concepção de um sistema, irá dedicar mais tempo aos modelos de contexto, e talvez um pouco menos ao modelo conceitual e não produzirá nenhum modelo detalhado. O engenheiro de software que procura garantir uma performance adequada para um sistema, sistema, irá i rá se s e dedidar, dedi dar, exclusivament exclusivamente, e, aos modelos detalhados e aos diagramas diagramas de implem implement entação. ação. O programador programador responsável pelos códigos poderá poder á receber r eceber um modelo modelo de contexto e um modelo conceitual já prontos e deverá, por sua vez, produzir muitos modelos detalhados para poder criar c riar os component componentes es do sistema. sistema. As técnicas de modelagem orientada a objetos não terminam aqui. É uma disciplina viva da engenh engenharia aria de software e passa, pas sa, constantem constantement ente, e, por atualizações, atualizações, correções correç ões e extensões para diversas áreas de aplicação. A OMG é o foro adequado para propor mudanças e discutir as evoluções da UML. Recomenda-se a visita freqüente no seu website para se manter atualizado com a UML Apenas a atualização Apenas atualização teórica teóri ca não é bastante, bastante, a prática da d a modelagem modelagem é necessária necessári a para a apreensão apr eensão dos conceitos. Assim Assim como como ao aprender uma uma língua língua estrang estrangeira eira é preciso preci so falar, ao apren apre nder uma uma linguag linguagem em de modelagem modelagem é preciso preci so modelar modelar.. Soment Somentee a prática pode dar ao modeli modelista sta a habil habilidade idade necessária necessári a para obter a qualidade e precisão preci são na representação. Neste Neste trabalho ao apresentar apresentar cada modelo pode-se observar obse rvar como é possível aplicar os recursos de representação em exemplos práticos, tirados de casos simples, propostos e estudados estudados ao longo longo de todo texto. texto. Cabe agora ao leitor, l eitor, aceitar o desafio de aplicar estas técnicas, e os diagramas da UML, para representar os seus próprios sistemas de software, e comprovar as qualidades da modelagem orientada a objetos.
7.1.
Referê Referências ncias B ibliograficas ibli ograficas
AMBLER, SCOTT; CRC Modeling: Bridging the Communication Gap Between Developers and Users. Users. November 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. OOPSLA´89 Conference Proceedings, 1989. Beck, Kent Kent Extreme Extreme Programming Programming explained: explai ned: embrace change. change. Addison Addis on Wesl Wesley ey Longm Longman, 199 1999. 9. Bellin, D.; Simone, S. The CRC Card Book. Addison-Wesley Pub Co; ISBN: 0201895358; Series Ser ies on Object-Oriented Object-Oriented Software Engin Engineering eering.. 1997. 199 7. BERARD, E. V. Be Careful with “Use Cases”, 1996. /da internet : http://www.toa.com/pub/use_cases.htm / / http://www.toa.com/pub/use_cases.htm BOOCH, G. Object-Oriented Analysis and Design with Application. Benjamin/Cummings, 1994. ECK, DAVID. The Most Complex Machine: A Survey of Computers and Computing. A K Peters Ltd; ISBN: 1568810547; 1995. FOWLER, M.; SCOTT, K. UML Destiled. Object Technology Series. AddisonWesley, ISBN ISBN 0201325632; 1997 HARMON, P.; WATSON, M. Understanding UML The Developer's Guide. San Francisco, Franci sco, Morgan Kaufm Kaufmann ann,, 1997. 19 97. JACOBSON, I.; RUMBAUGH, J.; BOOCH, G; The Unified Modeling Language Users Guide. Addison-Wesley Pub Co; . Object Technology Series; ISBN: 0201571684; 1998. JACOBSON, IVAR et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Pub Co; ISBN: 0201544350; 1992 Larman, Larman, Craig. Crai g. Applying UML UML and and patterns: pa tterns: an int i ntrodution rodution to objec ob ject-ori t-oriented ented analysis analysis and design. design. Prentice Hall PTR, 1997.
OMG, OMG, Ed. OMG Unified Unified Modeli Mode ling ng Langu Language age Specifica Spec ification. tion. Vers Version1.4, ion1.4, September, Object Management Group. 2001./ da internet em em http://www.omg.org/ ORFALI, ORFALI, R.; HARKEY, HARKEY, D. Client/Serve Cli ent/Serverr Programm P rogramming ing with Java Jav a and a nd CORBA. CORBA. 2nd Ed. John Wiley & Sons Ed. 1998. PARNAS, D.L.; D.L.; On the the Criteri Cr iteriaa to be used in i n decomposing System into Modules. Communications of the ACM, Vol.5, No.12, December 1972, pp 1053-1058 Pfleeger, Shari Lawrence. Albert Einstein and Empirical Software Engineering. IEEE Computer. Computer. V.32 n.10 Oct. 1999 19 99 PRESSMAN, R. S. Engenharia de Software. 3a Ed. São Paulo: Makron. 1995. Probasco, Leslee. Dear Dr. Use Case: What About "Shall" Wording in a Use Case?. Rational Rational Software Canada, 2001. /da / da internet : http://www.therationaledge.com http://www.therationaledge.com / / RUMBAUGH, et al. Modelagem e Projetos Baseados em Objetos. Rio de Janeiro: Campus, 1994. SEBESTA, ROBERT W. Concepts of o f Programming Programming Lang Languag uages. es. 3rd ed. New York: Addison-Wesley, Addison-Wesley, 1996. 1996 . Wilkinson, Nancy. Using Using CRC Cards. Cards . SIGS Books Boo ks & Multimedi Multimedia, a, ISBN: 0133746798, 1995. Wirfs-Brock, Wirfs-Brock, Rebecca. Rebecca . Design Desi gning ing Object-Oriented Object-Oriented Software Software Prentice Prentice Hall PTR; ISBN: ISBN: 0136298257; 013629825 7; 1991.
7.2.
Ender End ereços eços da Internet Internet
Seguem-se alguns endereços na internet onde onde se pode encontrar encontrar inform informações ações sobre orientação a objetos: www.omg.org empresas e interessados website da Object Managment Group, entidade que reúne empresas na normatização da tecnologia e das das aplicações orientadas a orientadas a objeto. Lá se encontra a documentação documentação oficia o ficiall da UML em www.omg.org/uml/ www.omg.org/uml/ , , as últimas versões, o estado das discussões das novas versões, referências, e outras normas como CORBA e XML. www.cetus-links.org organiza até a data que escrevia escrevi a este, mais mais de 18000 links para website que organiza sobr e orient ori entação ação a objetos. É uma uma referência obrigat obr igatória ória na bu busca sca de qualquer qualquer websites sobre assunto ligados à tecnologia de objetos, UML, componentes, engenharia de software e seus mais diversos padrões e tópicos relacionados. O website é bem cuidado cuidado e os links são freqüentemente freqüentemente atualizados. atualizados . Em ww www.cetus-link w.cetus-links.org/oo_ooa_ood_tools.htm s.org/oo_ooa_ood_tools.htmll pode ser encontrada encontrada uma lista das lista das ferrament ferramentas as CASE dispon dispo níveis, ívei s, com vários programas programas em demonstração que podem ser copiados para avaliação. www.c2.com empresa de Ward Cunningham onde se pode encontrar alguns artigos website website da empresa importan importantes tes sobre Objetos, inclusive o artigo a rtigo original original de introdução introdução aos cartões CRC. Curiosamente, pode-se encontrar em http://c2.com/doc/crc/draw.html http://c2.com/doc/crc/draw.html a a imagem dos primeiros cartões que Cunn Cunning ingham ham e Beck utilizaram para apresent apr esentar ar a sua técnica. técnica. www.mundooo.com.br bra sileiro iro com um um portal bem atualizado atualizado e organizado organizado sobre orientação a website brasile objetos, possui diversos artigos e notícias de diversas origens, organizadas por assunto. Possui um bom material também sobre Java. Dispõe de um fórum muito útil para discussão de assuntos assuntos relacionados relaci onados a objetos, e que traduz traduz bem a simplicidade simplicidad e e praticidade praticida de da técnica. técnica. www.od.com.br importantes es event eve ntos os sobre s obre orientação o rientação a objetos obj etos que ocorre website de um dos mais important no Brasil. Trata do estado da arte da tecnologia e de importantes aplicações das
técnicas em empresas nacionais. www.objetos6000.com.br
website de outro importante evento patrocinado pela SUCESU-SP (www.sucesusp.com.br ) e que reúne 3 tecnologias ligadas à orientação a objetos: UML, CORBA e Java. www.rational.com
website da empresa Rational, onde originalmente foi criada a UML e hoje é uma empresa empresa que desenvolve soluções para par a apoio apoi o ao desenvolvim des envolviment entoo de soft s oftwar waree usando 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 utili utilizei zei para produz pr oduzir ir os modelos modelos apresentados neste neste livro. li vro. www.uml.com.br ou ou www.umlbrasil.com.br um dos portais nacionais sobre a UML com link para para outros portais, artigos, tutoriais e outras informações sobre UML e orientação a objetos. http://java.sun.com . . http://java.sun.com
website oficial da linguagem Java, no domínio da empresa Sun, onde todas as informações sobre a linguagem, os compliladores e máquina virtual podem ser encontrad encontrados. os. Pode-se Pode- se encontrar encontrar também tutoria tutoriais is e exemplos exemplos de sistem si stemas as 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.
Glossário A
Abstração
(abstraction) As características car acterísticas essenciais de uma uma entidade entidade que a distinguem de outra entidade. Uma abstração define os limites da entidade relativos à perspectiva do espectador.
Ação
(action) Uma mensagem enviada quando da ocorrência do evento, permite permite a integração integração entre entre o diagrama diagrama de estado e os diagramas diagramas de interação.
Adorno
(adornment ) Elementos gráficos que aumentam a precisão da descrição de um diagrama.
Agregação
(aggregation ) Forma especial de associação que especifica uma relação rela ção de todo-parte entre entre o agregado agregado (todo) ( todo) e seus s eus componen componentes tes (parte).
Análise
(analisys) fase do desenvolvim dese nvolviment entoo do sistema sistema onde se identifica identifica os objetivos e se procura entender o problema a ser resolvido.
Analista de sistemas
( system syste m analiyst ) profissional responsável por realizar a análise de um sistema.
Arquitetura
(architecture) organização organização proposta pr oposta para resolver resol ver um problema, inclui a configu configuração ração de d e software e hardware, e como como eles se organizam. ( signature signature ) conjunto composto do nome, o valor de retorno e dos
Assinatura
parâmetros parâmetros da operação oper ação de uma uma classe, class e, não inclui inclui a sua implementação.
Associação
(association) tipo de relacionamento entre classes onde há um certo nível de envolviment envolvimentoo entre elas, cada classe c lasse se mantém mantém independente, mas guardam algum tipo de significado na ligação.
Ator
(actor ) representa os elementos externos ao sistema, que interagem com ele Como Como um usuári usuárioo que desempenh d esempenhaa um papel no sistem sis tema, a, estando estando fora do sistem s istema, a, e não podem ser alterados pelo desenvolvedor do sistema.
Atributo
(atribute) parte da estrutura que permite o armazenamento de informação em uma classe, possui um tipo e um nome.
B
Booleano
(boolean) Tipo de enum enumeração que assume assume os valores va lores de falso ou verdadeiro.
Brainstorm
(brainstorm) estratég es tratégia ia utilizada para levantar os requisitos de um projeto em uma reunião reunião de trabalh trabal ho.
C
Camada
(layer ) conjunto de classes que compartilham o mesmo nível de abstração ou finalidade, um layer pode ser s er representado r epresentado por um pacote.
Cardinalidade
(cardinality) número de elementos de um conjunto. (CRC cards) Técnica proposta por Beck e Cunnigham (1989), que
Cartõe Cartõess CRC
utiliza cartões de papel para representar as classes e organizar um trabalho em equipe que identifica e descreve conceitualmente as classes de um sistema.
CASE
Engenharia de Software Apoiada por Computador, do inglês: Corres ponde a programas programas Computer-Aided Computer-Aided Software Engineering Engineer ing . Corresponde de computador que dão suporte às atividades de engenharia de softwar software, e, principalm pri ncipalment entee as atividades de modelagem modelagem
Caso de de Uso
(Use Case) seqüência de transações ocorridas no sistema, que refletem em algo de importância para o ator que se comunica com ele.
Cenário
( scenary scenary) instância de um caso de uso, pode ser otimista, alternativo alternativo ou de exceção.
(development development cicle) série de atividades que gera um software a partir dos requisitos r equisitos de um problema Possui Possui 4 atividades atividade s Ciclo de principais : análise, design, construção de componentes e desenvolvimento principais: integração.
Ciclo de teste
Ciclo de vida
Classe
(test cicle) série de atividades que verifica se o software fornecido pelo ciclo ci clo de desenvolvim des envolviment entoo está de acordo com os requisitos requisitos de projeto. (life cicle) série de atividades entre a criação e destruição de uma classe, software ou de outro componente de um sistema, ou até mesmo do próprio sistema.
(class) molde para a criação cr iação de objetos, obj etos, identifica identifica um conjun conjunto de objetos que compartilha a mesma estrutura de dados e as mesmas operações. operaçõe s. É a base para par a a con co ntrução trução de um softwar softwaree orient ori entado ado a objetos.
(abstract class) apenas descreve conceitos abstratos e que não serão ser ão transformados transformados em objetos obj etos diretam dire tamente. ente. Uma classe class e Classe Classe abstrata abstrata abstrata possui pelo menos uma uma operação ope ração abstrata, definida apenas pela sua assinatura. assinatura. (concrete class) classe cl asse que permite permite a sua instanciação instanciação em objetos, Classe Classe concreta. concreta. não possui nenhuma operação abstratas.
Classificação
(classification ) processo de identificação das classes de um sistema em uma hierarquia de tipos.
Cliente
(client ) 1.contratan 1.contratante te do desenvolviment desenvolvimentoo do softwar software, e, in i nteressado pelo result re sultado ado que o software software irá ir á dar ao seu negócio. negócio. 2.classe ou componen componente te de soft so ftwar waree que solicita soli cita um serviço servi ço a outra outra classe cl asse ou componente.
Código
(code) programa p rograma de computador computador escrito escr ito em e m um uma lingu l inguagem agem de programação. programação.
Código executável
(executable code) programa de computador em linguagem de máquina, executável em um processador.
Código fonte
( source source code) programa de computador em uma linguagem de programação programação de alto al to nível, nível, passível pa ssível de ser compreendida compreendida por um programador. programador.
Colaboração
(collaboration) con co njunto junto de interação entre classes clas ses para cumprir cumprir um objetivo do sistema. sistema.
Comentário
(comment ) Ver nota
Componentes
(component ) unidades que armazenam software e permitem a manipulação: anipulação: arquivament arquivamento, o, distribuição di stribuição e instalação deste de ste software. softwar e. Devem Devem possuir poss uir uma uma interface bem-defi bem-definida. nida.
(behavior ) Os efeitos observáveis obser váveis de uma uma operação opera ção ou evento, evento, as Comportamento operações operaçõe s públicas públ icas expostas expostas por uma uma classe cl asse ou componen componente. te.
Composição
(composition ) relacionamento entre classes com uma forte propriedade propri edade de posse, poss e, o todo é form formado ado pelas partes que dependem dependem existencialmente do todo.
Condição de disparo
( guard guard condition ) expressão lógica avaliada quando da ocorrência do evento e que condiciona a execução do evento.
Construção
(contruction) fase do desenvolvimento onde os componentes são criados (programados, codificados) a partir dos modelos .
Contexto
(context ) conjunto de elementos relacionados que interagem para cumprir um objetivo do sistema.
CRC
Classe, Reponsabilidade e Colaboração, do inglês: Class Responsability Responsabilit y and Colaboration
D
Delegação
(delegation) A habi habili lidade dade de um objeto obj eto em compartilhar uma uma responsabilidade com outro objeto, por meio da duplicação desta operação entre entre eles. el es. A delegação del egação pode ser usada como como uma uma alternativa alternativa à herança. (dependency) relacionamento existente entre classes que de alguma
Dependência
forma forma não está especificada especi ficada pela pel a relação, rel ação, forma forma frace de relacionamento.
Design
(design) fase do desenvolvim des envolviment entoo onde se elaborar elabor ar uma uma estratég e stratégia ia para resolver re solver o problema Na Na fase de design são tomadas tomadas decisões deci sões ligadas à solução do problema.
Diagrama
(diagram) representação r epresentação gráfica de um umaa coleção col eção de elementos elementos relacionados: diagramas de classes, classes, diagram diagramaa de objetos objetos,, diagrama de casos de uso, uso, diagram diagramaa de seqüência seqüência,, diagrama de colaboração,, diagram colaboração diagramaa de estados estados,, diagram diagramaa de atividades a tividades,, diagram dia gramaa de d e com c omponent ponentee, e diagram diagramaa de distribuição di stribuição..
Diagrama de objetos
(object diagram) reúne objetos e as suas relações em um instante no tempo. Um diagrama de objeto pode ser considerado um caso especial de um diagrama de classes..
Diagrama de Casos de Uso
(use case diagram) descreve um modelo funcional de alto nível do sistema de infomações em projeto. Identifica os usuários e representa o sistema segundo a sua visão.
Diagrama de Atividades
(activity diagram diagram) representação gráfica dos diferentes estados e eventos que estão associados com um cenário. Representa as mensagens ensagens entre entre classes class es e os eventos eventos int i ntracl raclasse. asse.
Diagrama de Classes
(class diagram) mostra uma coleção estática de elementos do modelo seus conteúdos e relações. Forma a base para a tradução em código, criando uma estrutura para orientar a construção.
Diagrama de Colaboração
(colaboration diagram) mostra mostra as interações interações de objetos obje tos organizadas organizadas entre os objetos obj etos e seus s eus vínculos. vínculos. Assemelha-se Assemelha-se em em conteúdo conteúdo ao diagrama diagrama de seqüência.
Diagrama de Componentes
(component diagram) mostra a organização e as dependências entre os componentes componentes de de software.
Diagrama de Distribuição
(deployment diagram) mostra a configuração, em tempo de processam process ament ento, o, dos nós ós de de processamento, e os componentes, processos process os e objetos que existem existem neles.
Diagrama de Estados
( state mostra o ciclo cicl o de vida vi da de uma uma classe cla sse na forma forma de state diagram di agram) mostra uma uma troca de estados es tados provocada provoca da por eventos eventos int i nternos. ernos.
Diagrama de Seqüência
( sequence sequence diagram) mostra uma série de mensagens entre objetos organizadas seqüencialmente no tempo. Diagramas de seqüência e diagramas de colaboração expressam informação semelhante.
Disparo
( fire fire ) Causa uma transição de estado.
Domínio
(domain ) Uma área de conhecimento ou atividade caracterizada por um conjun conjunto de conceitos e terminologias terminologias aceitas por especialis especi alistas tas naquela naqu ela área. á rea.
E Elemento
(element ) um componente de um diagrama ou modelo.
(encapsulation ) conceito c onceito fundam fundament ental al dos objetos, o bjetos, associad as sociadoo ao Encapsulamento fato que um objeto deve possuir todos os dados e as funções necessárias para sua existência existência independent independente. e.
Engenharia de software
( software software engeineering engei neering ) é a ciência da computação aplicada na transformação do computador em uma ferramenta útil, resolvendo
problem proble mas para os seus utilizadores. utilizadores.
Engenheiro de Software
( software software engineer enginee r ) é o profissional que se utiliza de boas práticas de engenharia em um projeto de software.
Enumeração
(enumeration) lista de valores identificados por nomes e usados como uma série para um tipo de atributo em particular.
Especificação
( specificati specif ication on) descrição do sistema de software ou de seu componente, componente, detalhando o que que ele faz (ou deve fazer) fazer)..
Estado
( state state ) caracteriza uma condição onde o objeto daquela classe pode ser encon e ncontrado. trado. O estado é uma uma atividade da classe cla sse de caráter lent l entoo (estado de ação), e às vezes até estático (estado de espera). Os eventos provocam a mudança no estado.
Estereótipo
( stereotype) stere otype) são baseados nos elementos já existentes na UML e podem estender estender a semântica, semântica, mas mas não a estrutu estrutura ra destes elem el ement entos. os. É um dos mecanism ecanis mos de ext e xtendibi endibili lidade dade na UML UML..
Evento de tempo
(time event ) evento e vento que acont aco ntece ece em um um mom momento ento particular. partic ular. Pode ser descrito como uma expressão de tempo.
Eventos
(event ) retrata uma uma atividade rápida e que não pode ser interrompida. Sempre ocorre um evento entre dois estados. Está associado às operações das classes, e à sua dinâmica.
Expressão
F
(expression) Uma seqüência de caracteres que resulta em um valor de um tipo em particular. Por exemplo, a expressão " (7 + 5 * 3) " resulta em um valor do tipo numérico.
( focus diagramaa de seqüência seqüência que que focus of control contr ol ) símbolo em um diagram Foco de controle mostra o período de tempo durante o qual um objeto está executando uma ação diretamente ou por um procedimento subordinado.
Fornecedor
( supplier supplier ) Um tipo, classe ou componente que provê serviços que podem ser invocados por ou o utros.
Framework
( framework framework ) micro-arquitetura que provê um modelo extensível para aplicaçõe apl icaçõess dentro dentro de um domínio domínio específico.
G ( generalization generaliz ation ) relação existente entre um elemento mais geral e um elemento mais específico de uma classificação. O elemento mais específico é totalmente consistente com o elemento mais geral e Generalização contém informação adicional. Uma instância do elemento mais específico especí fico pode ser usada sempre sempre que o elemento elemento mais mais geral for aceito.
Granularidade
( granularity ca racterística associada associ ada ao tamanh tamanhoo dos elementos elementos de granularity ) característica um modelo, uma granularidade alta caracteriza uma grande abstração, uma granuladidade baixa leva a um alto nível de especificação.
GUI
Interface Gráfica do Usuário, do inglês Graphics User Interface.
H
Herança
(inheritance) propriedade das classes de poder serem geradas a partir de outras classes, classes , herdando herdando delas suas propriedades propri edades estáticas (atributos) e dinâmicas dinâmicas (operações) (operaç ões) e relacionam relac ionament entos. os.
Herança de interface
(interface inheritance ) a herança de interface de um elemento mais genérico, como uma classe abstrata. Não inclui herança da implem implement entação ação que será ser á realizada real izada pela classe class e que herda herda a interface. interface.
Herança múltipla
(multiple inheritance ) propriedade das classe em poder herdar de mais de uma classe ao mesmo tempo. Não é um propriedade facilm facil mente im i mplem ple mentável.
I
IDE IDE
Ambiente Integrado de Desenvolvimento, do inglês: Integrated Integrat ed Development Environment
(implementation ) definição de como algo é construído ou é process ado. Por exemplo, exemplo, uma uma classe class e é a implement implementação ação de um tipo, Implementação processado. um código é a implementação (contrução) de uma classe.
Instância
(instance) membro individual de um tipo ou uma classe. Em um uso menos formal é aceitável se referir a um membro de uma classe como um objeto ou uma instância. Sinônimos de ocorrência em alguns casos.
Integração
(integration) ação de colocar col ocar partes pa rtes de um sistema sistema juntas juntas para formar o todo. A união das partes requer conhecimentos específicos de conf c onfigu iguração ração e de técnicas técnicas de int i ntegração. egração.
Interação
(interaction) conjunto conjunto das trocas troca s de d e mensagem mensagem entre entre um conjunt conjuntoo de de objetos dentro de um contexto particular para realizar um propósito específico. Uma interação pode ser descrita por um ou mais cenários. (interface) descreve o comportamento externamente visível de uma
Interface
classe cla sse,, objeto, obj eto, componente componente ou outra outra entidade. uma uma classe cla sse formada formada apenas por métodos abstratos, servindo s ervindo para par a se s e definir uma uma forma forma de comunicação. Descreve o conjunto de mensagens que as classes que implementam a interface devem obedecer.
J, K,L Linha da vida de um objeto
(object lifeline) linha em um diagrama de seqüência que representa a existência de um objeto durante um certo tempo.
M Máquina de estado
( state state machine ) especifica as sucessões de estados que um objeto ou uma interação passam durante sua vida, em resposta aos eventos que recebe.
Membro
(member ) parte par te de um tipo ou classe, pode ser represent repres entado ado por um atributo ou atributo ou uma operação operação..
Mensagem
(message) comunicação entre objetos que leva informação com a expectativa que resultará em uma atividade. O recebimento de uma mensagem é, normalmente, considerado um evento evento..
Mensagem assíncrona
(asynchronous message) tipo de mensagem onde o objeto emissor emissor não tem sua sua execução interrompida interrompida para esperar espera r por resultados.
Mensagem síncrona
( synchronous synchronous message) tipo de mensagem onde o objeto emissor pausa seu processamento para esperar por resultados. (method ) Os métodos sugerem passos a serem seguidos para
Método
cumprir cumprir o vazio existente existente entre a idéia i déia e o produto produto de software software.. A implementação de uma operação. O algoritmo ou procedimento que afetam os resultados de uma operação.
Modelo
(model ) representa, simplificadamente, o que se pretende construir, como uma planta de uma residência. O modelo mostra não só os requisitos do problema mas também como eles serão atendidos pelos elem el ement entos os da solução.
Modelo conceitual
(conceptual model ) modelo que reúne todos os conceitos presentes no problema em estudo. Construído em escala menor do que o modelo de contexto, cria a estrutura do sistema, usando para isso um modelo simplificado de classes.
Modelo contextual
(contextual model ) represent repres entaa os aspectos fu funcionais ncionais de alto nível nível do sistema, possui uma escala grande o bastante para acomodar todo o sistema em um único diagrama.
Modelo detalhado
(detailed model ) in i ncorpora todos os detalhes de uma uma versão vers ão projetada do software. O modelo modelo detalhado pode possuir um nível de detalhe equivalente equivalente ao código c ódigo do software.
Multiplicidade
(multiplicity ) especifica a abrangência da cardinalidade cardi nalidade permissí permissível vel que um conjun conjunto pode assumir. assumir. Podem ser dadas multiplicidade para papéis dentro de associações, partes dentro dentro de composiçõe composições, s, repetições repe tições e em outros outros propósitos. pr opósitos.
N
Nó
Nome
(node) representam os equipamentos em uma rede de processamento de dados. As ligações entre os nós representar as associações físicas e lógicas existentes entre os equipamentos. (name) seqüência de caracteres que identifica um elemento dos
diagramas.
Nota
(note) um comentário preso a um elemento ou a uma coleção de elem ele mentos. Uma Uma nota não acre a cresce scent ntaa um significa significado do ao a o elemen e lemento, to, pode no entan entanto to restringí-l restringí-lo. o.
O
Objeto ativo
(active object ) objeto que possui uma linh linhaa de cont controle role de de execução e pode iniciar o controle de uma atividade. Uma instância de uma classe ativa.
sender [object] ) objeto que passa uma mensagem para um objeto Objeto e missor ( sender receptor.
Objeto persistente
( persistent persis tent object objec t ) objeto que existe depois do processo ou da linha de controle controle que o criou, normalm ormalment ente, e, associado associ ado aos bancos de dados e arquivos.
Objetos
(object ) in i nstância stância de uma classe, cla sse, ele el e implement implementaa a classe cl asse para o sistema. sistema. A estrutura estrutura do objetos é definida definida pela pe la classe, cl asse, mas as operações e estados (valores dos atributos) são definidos na instância.
Operação
(operation ) responsabilidades atribuídas atribuídas às classes, associadas ao que a mensagens que a classe pode receber, e que definem as funcionalidades que aquela classe está apta a realizar. São implementadas pelos métodos.
P ( package package) elemento da UML utilizado para agrupar outros
Pacote
elementos de um sistema, para organizá-los, um pacote pode abrigar outros elementos, outros diagramas, e até outros pacotes. Um sistema sistema pode ser pensado como como um único pacote de alto nível.
Papel
(role) comportamento específicado por um nome de uma entidade que participa de um contexto particular.
Parâmetro
( parameter parameter ) variável que pode ser alterada, transmitida ou retornada, possui possui nome, nome, tipo e direção. Parâmetros Parâmetros são usados para operações, mensagens e eventos.
Polimorfismo
( polimorfism pr opriedade de fundam fundament ental al da d a orient ori entação ação a objetos polimorfis m) proprieda associada ao fato de não se precisa conhecer a instância da classe para utilizar seus serviços. Esta propriedade propri edade leva le va ao fato de que que uma mesma mensagem pode ser interpretada de modos diferentes, quando quan do for recebida rece bida por objetos diferen di ferentes. tes.
Pós-condição
( postcondition restrição que que deve ser verdadeira na postconditi on) Uma restrição conclusão conclusão de d e uma uma operação. ope ração.
Precondição
( precondition restrição que que deve ser s er verdadei v erdadeira ra qu q uando um uma preconditi on) Uma restrição operação é invocada.
Problema
( problem Como todo projeto proj eto de engenharia, engenharia, o projeto p rojeto de software software problem) Como tem como como principal pr incipal objetivo resolver resol ver um problema.
Processo
( process controle que pode ser executada process ) Uma linha de controle que simultaneamente com outras linhas de controle.
(development process) conju c onjunt ntoo de passos ordenados executados executados Proce Processo sso de para um determinado determinado propósito durante durante o desenvolviment desenvolvimentoo de desenvolvimento software, que inclui construir modelos e programar.
Produto
( product ar tefatos atos construídos construídos durante durante o processo proc esso de product ) artef desenvolvimento, como modelos, diagramas, códigos, documentação e planos de trabalho.
(computer programmer ) profission profissio nal especializado especi alizado em criar cria r Programador de programas programas fonte fonte nas nas diferentes diferentes ling li nguuagens agens de programação programação computadores existentes.
Projeto
(design) A parte do processo process o de desenvolvim de senvolviment entoo de soft s oftware ware cujo propósito propósi to principal é decidir deci dir como o sistema sistema será im i mplementado. plementado. Durant Du rantee o projeto pr ojeto são tomadas tomadas decisões de cisões estratégicas estratégicas e táticas para par a se en e ncontrar contrar os requisitos r equisitos funcion funcionais ais e as exigências exigências de qualidade de um sistema.
( pseudo-state vérticess de uma máquina de estado, tem a forma de pseudo-state ) vértice Pseudo-estado um estado, mas não se comportam como um estado como: inicial, final, final, e as conexões histórica históricas. s.
Q
Qualificador
(qualifier ) atributo ligados à uma uma relação rel ação entre classes, class es, seu se us valores limitam o conjunto de objetos que participam da associação.
R
Raia
( swimlane pr esentee no diagrama diagrama de atividade, a tividade, que serve serv e swimlane) pacote present para organizar organizar as responsabilida re sponsabilidades des associadas assoc iadas a um objeto.
Receptor
(receiver [object] [object] ) objeto endereçado por uma mensagem passada por um objeto emissor emissor..
Rede
(network ) ligações entre os nós representando as associações físicas e lógicas existentes entre os equipamentos.
Relação
(relationship) conexão de significados existente entre elementos do diagrama.
Requisito
(requirement ) propried pr opriedade ade ou comportam comportament entoo desejado dese jado de um sistema. Característica de um problema que deve ser resolvida pelo sistema.
(responsabilitiy) o que que uma uma classe deve de ve saber ou saber fazer, Responsabilidade correspondem aos atributos e às operações de uma classe.
Restrição
(contraint ) condição que limita o alcance de um elemento, as restrições fazem parte dos mecanismos de extensibilidade da UML.
Reuso
(reuse) O uso de um artefato artefato pre-existente pre-existente em outro contexto além daquele para o qual ele foi criado originalmente, economizando tempo tempo e recursos no processo pr ocesso de desenvolvim de senvolviment ento. o.
S
Sinal
( signal evento com com um nome, que pode ser invocado signal ) evento explicitament explicitamente, e, pode ser anu anunciado nciado ou pode ser dirig diri gido para um único objeto ou conjunto de objetos.
Sistema
( system união de partes com um um objetivo específico es pecífico de resolver resol ver um syste m) união problem proble ma para o seus usuários usuários.. União União de hardwa hardware re e software.
Software
estratégia estratégia utilizada para resolver resol ver um problema real com apoio de um computador, computador, vai além alé m de um program progra ma de d e com c omputador putador
Subclasse
( subclass subclass ) especialização de outra classe, a superclasse na relação de generalização (h ( herança).
Subsistemas
( subsistem subsist em) um sistema que é parte de um sistema maior. Na UML um subsistema é modelado como um pacote de componentes componentes..
Superclasse
( superclass superclass ) Em uma relação de generalização (herança) é a generalização de outra classe, a sub classe.
Superestados
( superstate agrupamentoo de estados, e os event eve ntos os associados as sociados a superstat e) agrupament eles, que possuem um comportamento comum.
T Texto
( string stri ng ) seqüência de caracteres.
Thread
(trread ) caminho de execução de um programa, um modelo dinâmico, ou alguma outra representação de fluxo de controle.
Tipo
(type) define uma estrutura de dados e operações que afetam esta estrutura, sem a preocupação de implementar estas operações. Um tipo pode definir definir uma uma especificação esp ecificação de operação oper ação (com ( comoo uma uma assinatura) mas não a sua implementação.
Tipo primitivo
( primitive primiti ve type ) tipo básico de um lingaugem, é pré-definido, como um inteiro ou um caracter. car acter.
Transição
(transition) in i ndica que uum m objeto no primeiro primeiro estado poderá ir para pa ra um segundo estado quando um evento especificado acontecer e condições específicas forem satisfeitas.
U
UML UML
Lingu Linguagem agem Unificada Unificada de Modelagem Modela gem do inglês: Unified Modeling Language
V
Valor
(value) Um elem ele mento de um domínio domínio de tipo, ti po, instância de d e um atributo.
Valor rotulado
(tagged value ) definição explícita de uma propriedade pelo par: nome-va nome-valor lor.. Em um valor val or rotulado, o nome nome se refere ao rótu ró tulo. lo. O valor rotulado é um dos mecanismos de extendibilidade em UML.
Vínculo
(link ) conexão de significado entre objetos. A instância de uma associação, servem de meio para que as mensagens fluam e para a navegabil navegabilidade idade no diagrama. diagrama.
Visão
Visibilidade
W, X,Y,Z
(view projection) observação de um modelo a partir de uma determinada perspectiva ou ponto de vista, omite entidades que não são pertinentes a esta perspectiva. (visibility) capacidade das classes de envolver em uma cápsula atributos e operações, ocultando ou não a informação de outras classes que se encontram fora desta cápsula. A visibilidade pode ser: pública, privada ou protegida.
APÊNDICE
Códigos Java dos Exemplos citados no livro Seguem-se extratos dos programas Java que implementam os exemplos desenvolvidos no livro. O objetivo deste d este apêndice é mostrar, com c om um pouco mais mais de detalhes os códigos das aplicações desenvolvidas como exemplo para o livro. Os coment comentários ários sobre o códig códi go, quando quando necessário, necessári o, estão present pre sentes es no próprio própri o código. Os exemplos exemplos desenvolvidos para par a este livros podem ser executados executados pela internet , no no www.eduardodeboni.com/uml dedicado dedicado a este livro.. website www.eduardodeboni.com/uml
Código Código Java J ava do Sistema Sistema de Vendas da Loja 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 estão as funçoes 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.setText("Codig o
");
label1.setAlignment(java.awt.Label.RIGHT);
panel1.add(label1);
panel1.add(textField1);
button3.setLabel("PRODUTO");
panel1.add(button3);
button3.setBackground(java.awt.Color.lightGray);
panel1.add(textField2); label2.setText("CGC
");
label2.setAlignment(java.awt.Label.RIGHT);
panel1.add(label2);
panel1.add(textField3);
button1.setLabel("CLIENTE");
panel1.add(button1);
button1.setBackground(java.awt.Color.lightGray);
panel1.add(textField4); label3.setText("N. parcelas");
label3.setAlignment(java.awt.Label.RIGHT);
panel1.add(label3);
panel1.add(textField5);
button5.setLabel("PARCELAS");
panel1.add(button5);
button5.setBackground(java.awt.Color.lightGray);
panel1.add(textField6);
button2.setLabel("Limpar");
add(BorderLayout.SOUTH,button2);
button2.setBackground(java.awt.Color.lightGray);
//}}
//{{REGISTER_LISTENERS SymAction lSymAction = new SymAction();
button1.addActionListener(lSymAction);
button3.addActionListener(lSymAction);
button5.addActionListener(lSymAction);
button2.addActionListener(lSymAction);
//}} }
//{{DECLARE_CONTROLS java.awt.Panel panel1 = new java.awt.Panel(); java.awt.Label label1 = new java.awt.Label(); java.awt.TextField textField1 = new java.awt.TextField( java.awt.TextField(); ); java.awt.Button button3 = new java.awt.Button(); java.awt.TextField textField2 = new java.awt.TextField( java.awt.TextField(); ); java.awt.Label label2 = new java.awt.Label(); java.awt.TextField textField3 = new java.awt.TextField( java.awt.TextField(); ); java.awt.Button button1 = new java.awt.Button(); java.awt.TextField textField4 = new java.awt.TextField( java.awt.TextField(); ); java.awt.Label label3 = new java.awt.Label(); java.awt.TextField textField5 = new java.awt.TextField( java.awt.TextField(); ); java.awt.Button button5 = new java.awt.Button(); java.awt.TextField textField6 = new java.awt.TextField( 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 actionPerformed(java.awt.event.ActionEvent .awt.event.ActionEvent event) { Object object = event.getSource(); if (object == button1)
button1_ActionPerformed(event); else if (object == button3)
button3_ActionPerformed(event); else if (object == button5)
button5_ActionPerformed(event); else if (object == button2)
button2_ActionPerformed(event); } }
/**
* Ação do botão CLIENTE * que obtem um Cliente da lista com base no seu CGC * * @param event */ void button1_ActionPerform button1_ActionPerformed(java.awt.event.Acti ed(java.awt.event.ActionEvent onEvent event) {
try{ int cgc = Integer.parseInt(text Integer.parseInt(textField3.getText()); Field3.getText()); oCliente = aLoja.getCliente(cgc aLoja.getCliente(cgc); );
textField4.setText(oCliente.getNome()); } catch(Exception e){
textField4.setText("Erro"); }
} /** * Ação do botão PRODUTO * Obtem um produto da lista de produtos com base no codigo * * @param event */
void button3_ActionPerform button3_ActionPerformed(java.awt.event.Acti ed(java.awt.event.ActionEvent onEvent event) {
try{ int codigo = Integer.parseInt(textF Integer.parseInt(textField1.getText()); ield1.getText()); oProduto = aLoja.getProduto(cod aLoja.getProduto(codigo); igo);
textField2.setText(oProduto.getDescricao()); } catch(Exception e){
textField2.setText("Erro"); } } /** * Ação do botão PARCELAS * Verifica se a venda esta aprovada com base no produto e * no cliente ja identificados. * * @param event */ void button5_ActionPerform button5_ActionPerformed(java.awt.event.Acti ed(java.awt.event.ActionEvent onEvent
event) {
try{ Parcelas = Integer.parseInt(tex Integer.parseInt(textField5.getText()); tField5.getText()); boolean ok = oProduto.isAprovado(Pa oProduto.isAprovado(Parcelas, rcelas, oCliente); if (ok) {
textField6.setText(" Aprovada"); } else { textField6.setText(" Não Aprovada"); } }catch(Exception e){
textField6.setText("Erro"); } } /** * Ação do botão Limpar * limpa os campos anteriores para facilitar uma nova
consulta * * @param event */ void button2_ActionPerform button2_ActionPerformed(java.awt.event.Acti ed(java.awt.event.ActionEvent onEvent 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 cializaçao da loja.
* Ela guarda os dados dos clientes em codigo. * Em aplicaçoes 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 Produto(102,"Saxofone",800); ",800); listaP[3] = new Produto(103,"Bateria Eletrônica",750); listaP[4] = new Oferta(104,"Piano de Calda",5000); listaP[5] = new Produto(105,"Guitarra Baixo",1000); listaP[6] = new Produto(106,"Violão", Produto(106,"Violão",200); 200);
listaP[7] = new Produto(107,"Trompete Produto(107,"Trompete",500); ",500); listaP[8] = new Produto(108,"Flauta doce",100); listaP[9] = new Oferta(109,"Baixo Acústico",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,"Char ClienteVIP(4000,"Charlie lie 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 catálogo de produto */ protected Produto listaP[] = new Produto[10];
/** * array de clientes, que implementa um catálogo 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 métodos 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]); }
/** * Método 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]); }
/** * método de acesso ao cliente com base no CGC * o método 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()== (listaC[i].getCGC()==pCGC) pCGC) { c = listaC[i]; } } return (c); }
/** * Método 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( (listaP[i].getCodigo()==pCodigo) )==pCodigo) { p = listaP[i]; } }
return (p); } }
Classe Produto
/** * Classe Produto, representa os produtos vendidos na loja * * @author JEDeboni * @version 1.0 * @since 2003 */ public
class Produto
{ private
int codigo = 0;
private
int preco = 0;
private String descricao="";
/** * Metodo construtor do produto com base apensas no codigo. * Deve-se usar os metodos de acesso para complementar as informaçoes * * @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 atualização 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 descriçao atual do produto */ public String getDescricao(){
return(descricao); }
/** * metodo para atualização da descriçao 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 descriçao do produto. */ public String toString() { String s = "n"; s = s + getCodigo();
s = s + " "+getDescricao(); s = s + " R$ "+getPreco(); return s; } /** * método de verificação da aprovação do Crédito * verificando as regras de venda a crédito 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 dívida da venda for menor que o crédito do cliente */ int divida = preco - (preco/n); // System.out.println("divida System.out.println("d ivida = "+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 { /** * método de verificação da aprovação do Crédito * verificando as regras de venda a crédito 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 System.out.println("d ivida = "+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 descrição do produto * @param pPreco preço do produto */ public Oferta (int pCodigo, String pDescricao, int pPreco) { super (pCodigo, pDescricao, pPreco);
return; }
}
Código Código Java J ava do Jogo Jo go da Velha Velha Segue-se o código completo do jogo da velha na sua implementação básica. Classe Forca import javax.swing.JOptionPane;
/** * Classe principal, que integra as outras na implementaçao do jogo * * @author JEDeboni * @version 1.0 */ public class Forca { /** * objeto boneco usado no jogo */ private static Boneco
boneco = new Boneco();
/** * objeto ppalavra que implementa a Palavra secreta no jogo */ private static Palavra palavra = new Palavra();
/** * objeto j que representa o jogador no jogo */ private static Jogador jogador = new Jogador(); /** * programa principal do jogo da forca * * @param arg não é utilizado */
public static void main(String arg[]){ char letra; String tela="";
palavra.escolheSecreta(); do { // // constroi o desenho da forca, // da palava e das letras usadas tela = boneco.desenha()+"n"
+palavra.desenha()+"n"
+jogador.getLetrasChutadas(); // // captura uma letra entrada pelo usuario
letra="JOptionPane".showInputDialog(tela).toCharArray()[0]; //
// Envia mensagem ao jogador para entrar a letra no jogo jogador.chutaLetra(letra, jogador.chutaLetra(le tra, palavra, boneco); }while(!(jogador.ganhar(palavra)||jogador.perder(boneco))); // // envia uma mensagem final if (jogador.ganhar(pala (jogador.ganhar(palavra)) vra)) { tela = tela + "n Parabens! ganhou!"; }; if (jogador.perder(bone (jogador.perder(boneco)) co)) { tela = tela + "n Que pena, perdeu!"; };
JOptionPane.showMessageDialog(null,tela, "Jogo da Forca",JOptionPane.INF Forca",JOptionPane.INFORMATION_MESSAGE); ORMATION_MESSAGE);
System.exit(0); } }
Código da Classe Palavra import java.io.*;
/**
* Representa a palavra secreta no jogo da forca. * A classe permite escolher uma palavra de uma lista arquivada * e verificar se a letra esta n palavra * * @author JEDeboni * @version 1.0 * @since 2002 */ public class Palavra {
/** * array com as letras da palavra escolhida que e mantida secreta */ private char[] palavraEscolhida =
new char[100];
/** * array com as letras ja descobertas da palavra */ private char[] palavraDescoberta =
new char[100];
/** * numero de letras existente na palavra escolhida */
private int np = 0;
/** * seleciona aleatoriamente uma palavra de uma lista * armazenada em no arquivo ListaPalavras e * inicializa a palavra a ser descoberta com '_' * vao existir tantos tracos quantas letras na palavra */ public void escolheSecreta () { String linha[] = new String[200]; try { // // abre o arquivo FileInputStream ds = new FileInputStream("ListaPalavras.txt"); DataInputStream arquivo = new DataInputStream(ds); // // le as palavras do arquivo int i="-1;" do {
i++;
linha[i]=arquivo.readLine(); } while (linha[i]!=null);
int lp="i-1;"
// numero de palavras no arquivo
// // escolhe uma palavra da lista e mede o seu tamanho int iescolhido = new Double(Math.random() Double(Math.random()*lp).intValue(); *lp).intValue();
np="linha"[iescolhido].length(); // // preenche de espaços "_" a palavra descoberta for (i="0;" i
[i];
palavraEscolhida[i+1]=linha[iescolhido].toCharArray()
palavraDescoberta[i+1]='_'; } } catch (IOException e) {
System.out.println("E rro na leitura do arquivo de System.out.println("Erro palavras");
System.out.println(e); } }
/** * metodo para desenhar a palavra secreta * * @return retorna um texto com a palavra secreta * tracos marcam as letras nao descobertas */
public
String desenha()
{ String linha=" "; for (int i="1;" i<=np; i++) { linha = linha + palavraDescoberta[i] 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==palavraEscolh (letra==palavraEscolhida[i]){ ida[i]){
achou="true;"
palavraDescoberta[i]=letra; } }
return(achou);
}
/** * verifica se a palavra esta completa ou nao * procurando espaços "_" 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] (palavraDescoberta[i]=='_') =='_') { ok = false; } }
return(ok); }
/** * metodo construtor da Palavra */
public Palavra () { // não existe construção 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(ch addLetrasChutadas(char ar 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 não 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.letraNaPal (!palavra.letraNaPalavra(letra)) avra(letra)) {
boneco.addParte(); } }
/** * operaçao 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 não ganhou */ public boolean ganhar(Palavra palavra) {
return(palavra.isCompleta()); }
/** * Operaçao 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 não perdeu */ public boolean perder(Boneco boneco) {
return(boneco.isCompleto()); }
/** * contrutor do Jogador, nao possui parametros */ public Jogador ()
{ // não existe construtor especial para o Jogador }
}
Classe Boneco /** * Representa o boneco do jogo da forca * * @author JEDeboni * @version 1.0 * @since 2002 */ public
class Boneco
{ /** * numero de partes desenhadas do boneco. * Começa 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 cabeça
if (parte==2) Dforca[2][1]='/'; //
desenha bracoE
if (parte==3) Dforca[2][2]='|'; // if (parte==4) Dforca[2][3]='';//
desenha corpo desenha bracoD
if (parte==5) Dforca[3][1]='/'; // if (parte==6) Dforca[3][3]='';//
desenha pernaE desenha pernaD
}
/** * desenha o boneco na forma de texto * * @return texto com o desenho de um boneco e da forca feito com caracteres */ public String desenha() { String
linha = "n /-----";
linha = linha + "n |
"+Dforca[1][1]+Dforca[1][2]+Dforca[1] "+Dforca[1][1]+Dforca [1][2]+Dforca[1]
linha = linha + "n |
"+Dforca[2][1]+Dforca[2][2]+Dforca[2] "+Dforca[2][1]+Dforca [2][2]+Dforca[2]
linha = linha + "n |
"+Dforca[3][1]+Dforca[3][2]+Dforca[3] "+Dforca[3][1]+Dforca [3][2]+Dforca[3]
[3];
[3];
[3]; linha = linha + "n |
";
linha = linha + "n |_________";
return(linha); }
/** * verifica se o boneco esta completo * * @return verdadeiro se o boneco esta completo ou false se nao estiver */ public boolean isCompleto() { if (parte==6) {
return(true); } else {
return(false); } }
/** * método 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(); }
}
Código Java do Item de Estoque Classe Almoxerife import java.awt.*; import java.applet.*;
/** * Classe de interface do sistema itemEstoque, * realiza as açoes de capturar os eventos do usuário, * 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;
/** * operaçao de inicializaçao da Applet Almoxerife */ public void init() {
//{{INIT_CONTROLS setLayout(new BorderLayout(0,0));
setSize(426,266); panel1.setLayout(new FlowLayout(FlowLayout. FlowLayout(FlowLayout.CENTER,5,5)); CENTER,5,5)); add(BorderLayout.NORTH, add(BorderLayout.NORT H, panel1); label1.setText("Almoxerife: label1.setText("Almox erife: quantidade");
panel1.add(label1);
textField1.setText("0");
panel1.add(textField1);
btnRetirar.setLabel("Retirar");
panel1.add(btnRetirar);
btnRetirar.setBackground(java.awt.Color.lightGray);
btnRepor.setLabel("Repor");
panel1.add(btnRepor);
btnRepor.setBackground(java.awt.Color.lightGray); textArea1.setText("Historico textArea1.setText("Hi storico das transações"); add(BorderLayout.CENTER, add(BorderLayout.CENT ER, textArea1); panel2.setLayout(new FlowLayout(FlowLayout. FlowLayout(FlowLayout.CENTER,5,5)); CENTER,5,5)); add(BorderLayout.SOUTH, add(BorderLayout.SOUT H, panel2); label2.setText("Mensagem label2.setText("Mensa gem ao comprador");
panel2.add(label2);
panel2.add(textField2);
//}}
comprador = new Compras(); item = new ItemEstoque("101010 ItemEstoque("101010", ", "Tonner de copiadora", 100, 70, 50, comprador);
textArea1.append(item.toString());
//{{REGISTER_LISTENERS SymAction lSymAction = new SymAction();
btnRetirar.addActionListener(lSymAction);
btnRepor.addActionListener(lSymAction);
//}} }
//{{DECLARE_CONTROLS java.awt.Panel panel1 = new java.awt.Panel(); java.awt.Label label1 = new java.awt.Label();
java.awt.TextField textField1 = new java.awt.TextField( java.awt.TextField(2); 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( java.awt.TextField(25); 25);
//}}
class SymAction implements java.awt.event.ActionListener {
/** * operaçao para capturar os eventos da interface * * @param event evento vindo do usuário e * que devem ser tratados pela classe */ public void actionPerformed(java actionPerformed(java.awt.event.ActionEvent .awt.event.ActionEvent event) { Object object = event.getSource(); if (object == btnRetirar)
btnRetirar_ActionPerformed(event); else if (object == btnRepor)
btnRepor_ActionPerformed(event); } }
/** * operacao que trata o evento de Retirar, * le o valor da quantidade a ser retirada, * envia uma mensagem de retirar para o itemEstoque e * exibe o resultado na interface * * @param event evento vindo da açao do usuário */ void btnRetirar_ActionPerf btnRetirar_ActionPerformed(java.awt.event.A ormed(java.awt.event.ActionEvent ctionEvent event) { int n = Integer.parseInt(text Integer.parseInt(textField1.getText()); Field1.getText()); if (item.retirarMaterial (item.retirarMaterial(n)) (n)) { textArea1.append("nn*** textArea1.append("nn *** Ação :
Retirar "+n);
} else { textArea1.append("nn*** textArea1.append("nn *** Ação de Retirar bloqueada"); } textArea1.append(item.toString());
textField2.setText(comprador.getMensagens());
}
/** * operaçao 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_ActionPerfor btnRepor_ActionPerformed(java.awt.event.Act med(java.awt.event.ActionEvent ionEvent event) { int n = Integer.parseInt(text Integer.parseInt(textField1.getText()); Field1.getText()); if (item.reporMaterial(n) (item.reporMaterial(n)) ) { textArea1.append("nn*** textArea1.append("nn* ** Ação
:
Repor "+n);
} else { textArea1.append("nn*** textArea1.append("nn* ** Ação
de Repor bloqueada");
} textArea1.append(item.toString());
textField2.setText(comprador.getMensagens()); }
}
Classe ItemEstoque
/** * Representa o item de um sistema de estoque gerenciado * A regra de controle de estoque nao permite * que se faça 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 Descriçao 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 *
ou falso se o material nao foi retirado */ public boolean retirarMaterial(int n) { boolean ok="false;" if (isBaixo()) { comprador.setMensagens("Estoque comprador.setMensagens( "Estoque Baixo"); } else { if (qtd>=n) { qtd = qtd - n; ok = true; } if (qtd
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 *
falso se a reposicao não ocorrer porque o estoque estava normal */ public boolean reporMaterial (int n) { boolean ok = false; if (isBaixo()) { qtd = qtd + getQtdReposicao(); comprador.setMensagens("material 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); }
/** * operaçao de acesso a descricao do item * * @return descricao do item */ public String getDescricao() {
return(descricao); }
/** * operação de definiçao 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, *
e falso se o estoque estiver normal */ public boolean isBaixo() { boolean ok = false; if (getQtd()
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+" Mínimo = "+estoqueMinimo+" Reposicao = "+qtdReposicao+ "n
Estoque baixo : "+isBaixo();
return(s); }
}
Classe Comprador
/** * Classe que representa o setor de compras da empresa. * Neste exemplo ira apenas guardar as mensagens recebidas * pelo item de Estoque * * @author JEDeboni * @version 1.0 * @since 2003
*/ public class Compras { /** * mensagem que indica a atividade (estado) do comprador */ private String mensagens;
/** * metodo contrutor do objeto da classe Compras, * inicia informando que nao ha mensagens no comprador */ public Compras() { mensagens = "não 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.getQtdReposica "+item.getQtdReposicao()+" o()+" "+item.getDescricao()); }
}
Notas Notas de Rodapé
[1]
Adaptação do software ao cliente, originaria da palavra: customer , client cli entee em inglês. [2]
CGC – Cadatro Geral de Contribuint Contribuinte, e, su s ubstituído bstituído pelo CPF, Cadastro de Pessoas Físicas, um número único que identifica os contribuintes do Imposto de Renda, e que é usado para identificar unicamente o cliente. [3]
As funções funções são escri es critas tas usando um uma convenção de notaçã notaçãoo em inglês: get para obter, set para definir e is para verificar se é falso ou verdadeiro. [4]
A expre expressã ssãoo super.getCredito( ) sign si gnifica ifica,, na na linguagem linguagem Java, Java , que que se está chamando o método getrCredito da classe mãe (super). No caso o método getCredito da classe ClienteVIP chama o método getCredito da classe Cliente [5]
O bject_Oriented bject_Oriented Systems, Languages e Applications. Conferência annual sobre a tecnologia tecnologia de objetos. [6]
CRC significa Class, Responsability and Colaboration. Em alguns artigos tem sido encontrato tambem Contract no lugar de Colaboration, mas com um significado equivalente. [7]
Object Managment Group, organização de padronização de assuntos ligados à orientação à objetos. [8]
Optou-se Optou-se por não acentu acentuar ar os nomes omes das classes, class es, atributos e operações operaç ões para par a facilitar a transição transição do modelo modelo para códigos, c ódigos, já que a maioria das da s ling li nguuagens agens de implementação não dá suporte à acentuação dos seus componentes. [9]
GUI do inglês, Graphics User´s Interface, interface gráfica do usuário
