RODRIGO OLIVEIRA SPINOLA, MARCO ANTONIO PEREIRA ARAUJO UML na Pratica Construindo Diagramas de Classes (earign@sinaganne con.) Ettor Giole das rwistas SQL Magaine 0 Wet. € bach! em Cicada (Comuzaeo pla Unvesiade Ssnador (QTACS) € Mes om Engenharia de Siomas Compt pla COPPE/UFR) a ina de Enonnata de Softee onde tualmete cua 0 Doutrato, sen embod gupo ESE (Ergethar ve Sotare Bgoinena. inpiontator NPS BR, membr dal COPPE. Sia eas terse so: process de software, engentaia de sofware oferia + obits, inca © enrpentate de stuare, ispctes de swat, ambinies de deemohinenio de ste, engenaria de requis, itegrgéo de feraments,egentara de sare ‘epetinent ubgidece conputacral MARCO ANTONIO P. ARAGIO (narayoacessa.con) & Doutoznd fe Nase om Ergtaia de Sstomas © ‘aman pl COEP/LFR Een en Neto Estates Compueconals & chao mt Nomina Haitalo fn ifométca peo UE, Pesan dos (rvs de Berto em Sona do Iams do Cet de Ersito Supa Ge Jz de fre da Forde Woda Gane, on de Anta de Somas da Preltuade id For xistem diversos pontos criticos causadores de insergio de defeitos durante o desenvol- ‘vimenio de um software. Fodemos citar re- quisilos, projeto e coditicacéo como alguns exemplos, Somados a estes pontos crticos, tem-se um outro momento do desenvolvimento que me- rece uma atencao especial: a/elaboracio da solugao para 0 problema através do diagrama de classes. Elaborar de for- ‘ma criteriosa diagramas de-classes € um fator de sucesso de projetos de software por que, além do fato de ser um momento propenso a insercao de defeitos no software, s30 neles em que si0 transformados 0s problemas do ususé- rio em uma solugio computacional, servindo como uma ponte entre requisitos e codificacdo. Se esta ponte for mal projetade, o software também sera (ver Figura 2) ‘A UML (Unified Modeling Language) apresenta uma, série cle diagramas para a modelagem de sistemas orien- tados a objetos. Os diagramas mais comuns sfo 0 diagra- ma de casos de uso (representa as funcionalidades de um sistema), 0 diagrama de classes (ler Nota 1) (descreve as classes do modelo numa visio estatica), o diagrama de seqiiéncia, ou seu substituto na UML 2.0, 0 diagrama de comunicacéo (descrevem as funcionalidades através de uma visio dinamica) eo diagrama de estados (apresenta o ‘comportamento dinamico de um objeto) O objetivo desta matéria € trazer ao leitor algumas boas praticas para elaboracio de diagramas de classes, através de sua aplicacdo pratica em dois estudos de caso, Modelagem de classes [Exstem diferentes caminhos para se chegar 20 diagra- sma de classes, Bois dos mais tilizados si: + Bspecficar os casos de uso e, entio, partir para o dliagrama de classes: neste cas0, as classes, seus atri- ’butos, elacionamentos e métodos sio identiicados 44 SQL Magazine UML na Pratica - Construindo Diagramas de ClassesFigura 2. inserindo cefetos no projeto diretamente a parti dos requisitos de software de- finidos. Pode-se utilizar, em seguida, o diagrama de sequéncia para verifcar se os relacionamentos e mé- todos definidos fazem sentido, ‘+ Especificar os casos de uso, elaborar 0 diagrama de seqiignciae, entio, partir para a construcio do dia- rama de classes: neste caso, a construgio do dia- grama de segtiéncia ajudaré na identificacéo das classes, relacionamentos e métodos a partir da es- pecificagao de requisites. uma abordagem muito interessante também. Nao existe um caminho mais correto que 0 outro, de- vendo o desenvolvedor utilizar aquele que se sentir mais a vontade em seguir. Neste artigo serétrabalhada a primei- 12 opgio: caso de uso ® diagrama de classes, que é a forma mais natural de ser ulizada. Neste caso, partiremos para a construgio do diagrama de dsses atentando para a identi- ficagio de quatro elementos: entidades (lasses) do software, seus atributos, suas operagées e 0 relacionamento entre as classes. Assim, um processo para criagio de um moxielo de classes pode ser dividido em quatzo etapas (ver Figura 2). Etapa 1: Identificagie de entidades (classes) Classes permitem que sejam representados no mundo computacional elementos do mundo real, ou seja. do pro- blema para o qual o software esta sencio desenvolvido. Elas permitem descrever um conjunto de objetos que compar tilhem os mesmos atributos, operagbes, relacionamentos seméntica, e representam o principal bloco de construgio de um software orientado a objetos. ‘Seguindo nossa abordagem para a construgio do diagra- ‘ma de classes (partindo da especificagio dos casos de uso), para dentificé-las, procura-se na especiicacio por concei- {os que representem objetos do dominio da aplicacio a set desenvolvida. A Figura 3 apresenta a simbologia para uma classe chamada ContaBancaria utilizando a UML. Etapa 2: Mdentificagao de atributos Com as classes definidas, precisam-se especificar quais so seus atributos. Estes so as propriedades que caracteri- UML na Pritica - Construindo Diagramas de Classes Ano 3 34° Edi¢do 45 Figura 2. Elahoranco ums solugdo computacional, zam um objeto, Por exemplo, uma entidade conta bancéria possui como atibutos o ntimero e o saldo. E bastante sim- ples identificar os atributos de cada classe, basta identificar as caractersticas que descrevam sua classe no domtnio do problema em questo. Note que os atributos identificados devem estar alinhados com as necessidades do ususrio para o problema, ‘A Figura 4 apresenta a classe ContaBancaria com alguns ‘deseus aitibuloecd tinporianie observa o'sinal="'8 es- querda do nome dos atributos. Isto indica que os mesmos siio privados, encapsulaclos, proibindo que seu contetido seja manipulado por operagoes que nao sejam da propria classe. Iss0 proporciona maior independéncia da classe, aumentando sua possibilidade de reutilizagio. Ainda te- ‘mos mais dois sinais: “+” e “#". O sinal “+" indica que uum atributo é pailico (ou seja, este pode ser acessado por qualquer outro objeto) e o sinal “#” indica um atributo protegido, podendo ser herdado por subclasses. Etapa 3: Mlentificacao de operacces dentificadas as classes e seus atributos, o préximo pas- s0 6a identificagio das operagies de cada classe, também, Figura 3. Classe ContaBancaia, Figura 4. Classe CortaBancara com seus atibutos.chamadas de métodos ou servigos. Fazendo um paralelo com objetos do mundo real, operagdes sao agoes que 0 objeto € capaz de efetuar. Desa forma, ao procurar por operagies, devem-se ientificar ages que 0 objeto de uma classe € responsvel por desempenhar dentro do escopo do sistema que ser desenvolvido. Figura § apresenta algumas operacdes da classe ContaBancaria. Ao contrério dos atributes, normalmente operagies so piiblicas, per- mitindo sua utilizacio por outras classes e objetos. Etapa 4: Idontificacao de relacionamentos timo passo a ser executado na construgio de um liagrama de classes € a definicio dos relacionamentos en- tre as classes do modelo. Para isso, deve-se entender um ppouco sobre os tipos de relacionamentos que podem apa~ recer entre classes em um diagrama de classes. Os tipos de relacionamento mais utilizados S30: + Generalizagio (Heranca): denota relagSes “é um tipo de”, onde subclasses sio especializagSes de superclasses e herdam seus atributos e operagées. O segredo na identificagio correta deste tipo de relacionamento esté na semantica “é um tipo de”. Isto porque as pessoas, muitas vezes, uilizam 0 re- lacionamento de teranga como wen mecanismo de reutilizagdo esquecendo-se da semintica associada ao relacionamento, Nao é porque Cliente e Agencia possuem algum atributo em comum, como nome, que devam herdar de uma superclasse chamada "Cliente Agencia". Percebese que esta entidade no faz. sentido algum. [Na Figura 6 tem-se um exemplo de generalizagio definindo as classes ContaCorrente e ContaPoupan- ca como subclasses de ContaBancaria, + Associagéo: representa uma relagio estrutural entre duas classes indicando que estas se comunicam atra- vvés de troca de mensagens. E representada por uma linha simples ligando duas classes (ver Figura 7) ¢ pode conter atributos como nome, multiplicidade e navegabilidade. O nome representa a semantica do relacionamento indicando 6 porqué das classes esta- rem relacionadas; a multiplicidade indica a quantos objetos de uma determinada classe um objeto pode se comunicar; ¢ a navegabilidade especifica quem enxerga quem no relacionamento, ou seja, se um pbjeto tem conhecimento cla existéncia de outro. Por exemplo, a Figura 7 informa o seguinte: (© um objeto da classe ContaBancaria esta associado a nenhum ou varios objetos da classe Cliente (no caso de conta conjunta). Essa informagéo € transmitida através do indicador de multiplicidade (0.*) mais pro- ximo a lasse Cliente; © umobjeto da classe Cliente pode estar asso- ciado a nenhum ou varios objetos da classe ContaBancaria. Essa informagio & transmi- tida através do indicador de multiplicidade (0.*) mais préximo a classe ContaBancaria; + Anto-Associagdo: uma classe ainda pode associar-se com ela mesma, caracterizando uma auto-associa- ‘Gio. A Figura B apresenta uma auto-associagao na classe ContaBancaria, representando que uma con- ta pode estar associada a uma conta investimento, ‘que nada mais é do que uma outra conta bancéria + Agregacao: é uma associagio cuja semantica é“par- te de”. Neste tipo de relacionamento, tem-se uma classe representando 0 todo e outras classes, suas partes. Por exemplo, uma ContaBancaria € parte in tegrante de uma Agéncia, inclusive uma conta ban- céria identificada pelo nimero da agéneia e pelo ngimero da conta (ver Figura 9). Esta figura ainda ind ‘ca que um objeto da dasse Agencia esté relacionadoa vrs objetos da classe ContaBancaria, enquanto que tum objeto da classe ContaBancaria esta relacionado a ‘um tinico objeto da classe Agencia. Uma agregacio representada por uma linha simples com um losango sem preenchimento do lado do todo. + Composigio: € uma associagio que expressa a se- ‘miantica “parte de” mais "fortemente”, Neste caso, Figura 6. Generalizarae de classes. os Of Figura 7. Associagio entre classes. a4 Containvestimento oa Figura 8, Autoassociagao em uma classe. 46 SQLMagazine UML na Pratica - Construindo Diagramas de Classes,‘seo objeto que representa o todo for destrutdo, suas partes obrigatoriamente também serdo. For exem- plo, quando se destroi uma ContaBancaria, todas as suas Movimentagées também precisam ser destrut- das (ver Figura 10), Além disso, uma composicao in- ica que, para acessar os métodos de uma classe que represente a“ parte", deve-se primeiro interagir com a caste que representa 6 “todo Ha classe “todo” quem interage com suas classes “parte”. Uma com- ‘posigao 6 representada por uma linha simples com ‘um losango preenchido do lado do todo. Navegacio: representa se um objeto possui uma re- feréncia para um outro numa associacao. A maioria das ferramentas CASE para modelagem OO assu- ‘me que o padrio de associacées é possuir navega- bilidade bidirecional, ou seja, objetos de uma classe possuem referéncias para os objetos da classe asso- ciada, e vice-versa. Entretanto, muitas vezes torna- se interessante restringir a navegabilidade, seja por diminuir 0 estorgo de desenvolvimento, seja por re- almente nio ser necesséria a comunicacio entre ob- jelos num determinado sentido. A Figura 44 exibe ‘uma navegacio da classe Movimentacao (de Contas Bancétias) para a classe TipoMovimentacao. Isso in- dica que a classe Movimentacao “conhece” a classe ‘TipoMovimentacao e pode interagir com ela. O con- trdrio nao € verdade. Neste exemplo, pode nao fa- zer sentido dado um tipo de movimentacao (trans- {eréncia, por exemplo), saber quais movimentagies que aconteceram para este tipo, em todas as contas. O sinal do “X" nao é padrao em todas as ferramen- tas CASE. RestrigSes de navegabilidade podem ser feitas em associagdes, agregagbes € composicdes. Para identificar se uma navegabilidade é necesséria ‘ou nao, uma boa possibitidade é analisar © conjun- to de diagramas de seqiiéncia do sistema, caso estes existam. Desta forma, navegabilidades podem ser definidas: num segundo momento, quando do refi- rnamento do diagrama de classes, apds a construgio dos diagramas de seqiiéncia, Por exemplo, a Figura 12 informa o seguinte: ‘2 um objeto da classe Movimentacao sabe a qual objeto da classe TipoMovimentacao estar se comunicando. Essa informacao 6 transmitida através do indicador de na- vegabilidade (a seta). Em codigo, isso sig- nifica que a partir de um objeto da classe Movimentacao tem-se acesso a um objeto da classe TipoMovimentacao, ou seja, exis- te na classe algum atributo que seja do tipo ‘TipoMovimentacao; © um objeto da classe TipoMovimentacao nao sabe que objeto da classe Movimen- tacao esté utiizando. Essa informacio & ie transmitida através do indicador de nave- gabilidade (0 simbolo “X’, ou a falta dele ‘numa associagio unidirecional). Em cédi- 0, isso significa que a partir de um objeto da classe TipoMovimentacao nao se conse- gue referenciar diretamente um objeto da classe Movimentacao, * Classe associativa: representa situagies onde de- terminados atributos ndo podem ser colocados em rnenhuma das classes participantes de uma associa- fo, por conter informacoes referentes exclusivas 8 ligacao dos objetos das cuas classes. A Figura 12 demonstra que a Validade e Senha de um cartio sé diferentes para cada um dos clientes de uma mes- ‘ma conta, Ou seja, dado um objeto Cliente asso do com um objeto ContaBancaria, tem-se um objeto Cartao com informagées diferentes. Estudo de caso 1 Para o primeiro estudo de caso deste artigo, serd consi- derado um fragmento de um Sistema de Controle Bancé- rio. Para este sistema, o gerente deve cadastrar agéncias, lentes e abrir fechar contas bancérias. Um cliente pos- sui nome, endereco ¢ telefone. Um cliente pode abrir vi- rias contas e uma conta pode ser de varios clientes, para 0 Figura 9. Ageaacao entre classes, OF Figura 30. Composicio entre classes, ir 7 Figura 24. Nevegatildade entre cesses Flew 12. Classe associative, ‘UML na Pratica - Construindo Diagramas de Classes Ano 3 34° Edigao 47caso de contas conjuntas. Contas so de uma determinada agéncia (que possui nome e ntimero), além de poderem estar vinculadas a uma conta de investimento, que nada ‘mais € que uma outra conta bancéria. Contas ainda devem possuir um nimero (formado pelo niimero da agéncia e pelo néimero da propria conta) e saldo disponivel, poden- do ser corrente normal, corrente especial e poupanga. Para contas poupanca, devem-se armazenar os dias de venci- mento e, para contas corrente especiais, informar o limite de crédito, Contas ainda possuem movimentagées de sa- que e depésito, que devem ter data e valor, akim do tipo de movimento, que pode ser débito ou crédito. Clientesainda podem solicitar cartées de contas bancérias, que devem ter ‘timer, validade e senha para cada cliente, além de taloes de cheques para contas correntes, que devem armazenar 0 rntimero inicial e final das folhas do talao. O sistema ainda deve permitir aos clientes consuiltar saldos e extratos. diagrama de casos de uso da Figura 43 apresenta as, principais funcionalidades do sistema No diagrama de casos de uso da Figura 43, observa-se que foram apresentadas as principais funcionalidades do sistema, associadas aos atores que as utilizam. Percebe-se que um ator é quem realmente interage com o sistema. Vale destacar aqui que a0 definirmos um diagrama de casos de uso, 0 mais importante nao € o diagrama em si, ‘mas sua especificacdo. For questio de espago, seré apre- sentada a especificacio de apenas um dos casos de uso apresentados no diagrama da Figura 13. Observa-se na Tabela 1.0 fluxo de agées envolvido no caso de uso Ca dastrar Cliente, Seguindo o processo anteriormente definido, a Etapa 1 (Identificagio de Classes), objetiva encontrar as classes do modelo, Neste estudo de caso, as entidades encontradas foram Agencia, Conta, Conta Corrente, Conta Corrente Nor- mal, Conta Corrente Especial, Conta Poupanca, Movimenta- ‘glo, Tipo de Movimentacio, Talo de Cheques ¢ Cartio de Conta, representandio elementos do dominio da aplicacao. E importante atentar para a entidade Gerente. O fato dela representar um ator do sistema nao significa neces- sariamente que deveré estar contemplada no diagrama de lasses. Entio, como se pode definir se um ator participard ou nao de um diagrama de classes? Basta atentar para 0 fato de haver a necessidade de manter algum atributo e/ou realizar alguma operagdo sobre ele. Neste estudo de caso, © Gerente nao sera uma classe, pois essas necessidades niio estio presentes A proxima etapa refere-se a identificagio dos atributos das classes. A Tabela 2 descreve os atributos identificados a partir dos requisitos inicialmente definidos. Observa-se que nao estdo descritos os atributos de ligacao entre as lasses. Isso 6 papel dos relacionamentos. A etapa seguinie refere-se a identificagao das operacoes das classes. A Tabela 3 resume esta etapa apresentando as principais operagGes das classes do modelo. E impor- tante ressaltar que muitas vezes a identificagéo das opera- Ss BS & Figura 43. Diagrama de casos de uso. bes pode ser feita posteriormente, ao refinar 0 diagrama de classes. Uma boa ferramenta da UML, para detalhar 0 comportamento de casos de uso numa visio orientada a objetos e, consequentemente, auxiliar na descoberta das operacées, € 0 diagrama de seqiiéncia. 0 tiltimo passo refere-se & identificacéo dos relaciona- mentos e, para isso, efetua-se a anise dos casos de uso, de forma a encontrar estas relagées entre as classes j4 identificadas: + Generalizagéo: verifica-se se hé alguma relacdo "& ‘um tipo de” entre as classes identificadas. Neste es- tudo de caso, ContaCorrente e ContaPoupanea “S80 tipos de” ContaBancaria, enquanto ContaCorrente- Especial “é um tipo de” ContaCorrente. + Associacao: verifica-se se hd a necessidade de um. ‘objeto de uma classe utilizar servigos disponibiliza- dos por um objeto de outra classe ou, simplesmen- te, “conhecer” o outro objeto. Neste estudo de caso, tem-se que uma conta bancéia esta relacionada com um ou mais clientes e um cliente pode possuir mais de uma conta bancéria. Insere-se entao uma associacio entre estas classes. Existe uma segunda associacéo entre Movimentacao e TipoMovimenta- c20, onde uma movimentacao € de um tnico tipo de movimentacéoe um tipo de movimentacdo pode estar relacionado a diversas movimentacdes. Verifi- ca-se ainda uma terceira associagdo entre as classes ContaCorrente ¢ TalaoCheques, onde uma conta corrente pode possuir virios tal6es de cheques € um taldo de cheques é de uma tinica conta corrente. Esta associagao nao poderia ter sido feita na classe ContaBancaria uma vez que uma conta poupanca nao possui taloes de cheques. + Auto-Associagéo: verifica-se se existe alguma classe ‘que necessita ser relacionada a ela mesma. Neste estu- do de caso, existe uma auto-associagao na classe Con- taBanearia, representando uma conta de investimen- tos, que nada mais € que uma outra conta banciia + Agregacio: verifica-se se hé alguma relagio “parte de” entre as classes identificadas, Neste estudo de caso, tem-se que uma agéncia (0 todo) € composta de diversas contas bancérias (as partes). Percebe-se ainda que a identificagao da conta bancéria € feita pelo mimero da agéncia, aerescido do némero da propria conta bancéria. Dai, modela-se este relacio- namento através de uma agregacao. ‘8 SQLMazazine UML na Pratica - Construindo Diagramas de Classes.errr coe) ste caso de uso permite 0 cadastre (incluso) ce lentes do banca. ete) ‘caso ce uso # niciaco quenco © Geren Scociona #09585 Cadastar Chet, ‘Sistema apresenta jenela com os campos nome, enderego ee telefon. is ‘Gefenta preenche Gompoe \SAedga & pean tetuar Cacao. Sistema valla as infomagdes preenchidas pelo geente (EXO), “ister cadastrs elt (EXO) o volta pa a toa Inca. Neste momento, este caso de use 6 eneorede, i (0s campes devem estar todos preenchides e de acordo com © dominio (tise) do atibute. Se hower ‘robiemes no preenchimento do foemuléio 0 sistema exibe & mensagem de err: “Exctom dadoe Invalides no formulanio ou algum campo nae fl preencnido™. (Caso 0 clente j8 se ercantie cadastiado, a mensagam “Este clente J8 possul eadasto" € presenta, Tahela 4. Desericdo do cose de uso Cadestrar Cilents ae coo ceusons aa sales ContaComenta€spacial | LimiteCredito aaperae Exineeo Palen : Bonn coe Cle int Ii ae eC Snore Sotto eae ae os aa HE os Nunero, Movimentacao | EfetwarMovimentaceo conte oe a Tet tre ta poen enc oan Lae S29 + Classe Associativa: verifica-se se existem informa- TipoMovimentacan ma ce gdes que precisam estar vinculadas a associagao de Pea ee dois objetas (mas ndo a um deles em particular) ‘Tabata 2, Ineniticagto dos stitutes ne classes, Neste estudo de caso, 0 niimero, validade e senha Seeeiies dé Sais cds a ees fa 1 Geek her tec cpeeacisatie. sent om in trie peace atin aermsckceldelicia Wereriale —cudMaidees oa dmc scllanior ene chee pips hysPegarey aiecieneny ne mee Sa entre as classes ContaBancaria e Movimentacso, Juma ver que as movimentacées s80 como atributos Feito isto, chega-se a versio final do diagrama de classes interns de contas bancitias. Além disso, a exelusio _ proposto pelo estudo de caso, que pode ser visto na Flgu- de uma conta bancéria necessariamente implica nara 14, Um refinamento deste diagrama ainda precisa ser exclusio de suas movimentagies. Neste caso, mode- feito, definindo tipos de atributos e assinaturas das opera- la-se esta situagio através de uma composigio. .gées, com seus eventuais parametros de entrada e tipos de + Navegacio: verifica-se se existem ‘navegagdes" des- _retorno para 0 caso de fungbes. necessérias entre classes. Neste estudo de caso, na Percebe-se na versdo final do diagrama da Figura 14 que associagao entre as classes Movimentacao e Tipo- classe ContaBancaria tornou-se abstrata. Em UML isso 6 Movimentacao, utilizou a navegabilidade no senti-_representada pelo nome da classe em itélica, Uma classe do Movimentacao @ TipoMovimentacao, uma vez _abstrata nao instancia objetos e ¢ criada com a finalida- que esta diltima nao precisa utilizar nenhuma das de de agrupar atributos, métodos e/ou relacionamentos ‘operagies definicas na classe Movimentacao. ‘comuns a outras classes. Nao se deve achar que toda su- UML na Pratica - Construindo Diagramas de Classes Ano 3 34° Edicéo 49Figura 14. Diagrams de classes. lis ai perclasse é abstrata. Por exemplo, a classe ContaCorrente € concreta, podendo instanciar objetas. Caso seja aberta uma conta corrente comum, esta € instanciada a partir desta classe. Estudo de caso 2 © segundo estudo de caso considera um fragmento de tum sistema para uma Transportadora. Para este sistema, os fancionatios da transportadora devem cadastrar Clientes, Filiais, Vefculos, Funcionarios, Tipos de Veiculos, Cidades, Distncias, Categorias de Frete e Fretes de Clientes. Clientes sto pessoas fisicas e possuem nome, endereco e telefone. Filiais tem nome, endereco, telefone, funcionario responsivel e vérios veiculos, Veculos devem possuir nti- mero de placa e um tipo de veiculo, além de ser necessa- ‘Hamente de uma filial. Funcionérios sfo identificados pelo seu ntimero de matricula, e devem conter ainda nome, endereco, telefone e depen- denies (com nome e data de nascimento), além de estar associado, obrigatoriamen- te, a uma filial. Tipo de Vefculo apresenta uma descricao (como caminhao e moto) 0 peso maximo que pode transportar, além de estar associado a veiculos. Cida- des contém o nome da cidade e 0 estado, aque pertence, representando as cidades abrangidas pela empresa de transporte. Distancias envolvem as cidades origem & destino e, para cada par de cidades aten- didas, deve haver a disténcia em quilé- metros entre elas, Categoria do frete deve conter descrigéo e um percentual, que deve incidir sobre o valor do frete onde, por exemplo, entregas répidas tém au- mento de 10%, entregas super-répidas tém aumento de 30%, e entrega normal nao tem acréscimo no valor. Cada Frete tem um e6digo, um cliente, 0 veiculo que deve efetuar o frete, cidade origem e ci- dade destino, funciondrio responsivel € itens a serem transportados, ndo podendo hhaver um frete sem os dados citados. Cada frete deve ter ainda o seu valor, que deve ser caleulado através da distancia entre as cidades envolvidas e da categoria do fre- te, Para isso, deve existir um valor padrio para o km rodado. Um Item de Transporte & cada objeto a ser transportado num frete e deve possuir apenas uma descricao e seu peso. Por fim, temas que o sistema ainda deve emitir Nota Fiscal com todas as infor- ‘mages de um determinado frete, logo apts seu cadastramento. A Figura 48 apresenta o diagrama de casos de uso com as principais funcionali- dades deste sistema. No diagrama de casos de uso da Figura 18, observa-se que, como é 0 funciondrio quem utiliza todas as fungses do sistema, todos os casos de uso estio ligados a ele. Outra caracteristica é relativa ao caso de uso EmitirNotaFiscal. Como este caso de uso é disparado sempre que um fre- te for cadastrado, representa-se esta situagao utilizando uma seta com 0 esteredtipo “< >”, indicando que 0 caso de uso CadasirarFrete dispara © caso de uso EmitirNotaFiscal. Este tipo de situacéo é utilizado quando se deseja destacar uma funcionalidade do sistema, como neste caso, o quando uma determinada funcionalidade € uiilizada por mais de um caso de uso, evitando que seja deserita mais de uma vez Mais uma vez, destaca-se a importancia em especificar cada um dos casos de uso presentes no diagrama de casos 50 SQLMiagazine UML na Pratica - Construindo Diagramas de Classeseer eer Corsi Veibo Esto caso de usp pormite 0 cadastio (nlueo) de ellos da Traneportadora. ceed ‘caso de uso ilado quando o Futons sclocion a apode Cadastar Veto. Coens ‘Sis apfSeea jaa eon Gains Hui Wal lake Ua) de vlcuo al Funciondiopreenehe campos © selecione @ el ‘pega Efetuar Cadast, [Sea ees aetna Aas ple Puno (EXO). ‘Sistema cocastra veculo (EXO2) € vis re 8 tel nicl. Neste momenta, este caso de uso ¢ encorade. 1s capos deven estar todos Tabela 4. Deserclo do caso de uso Cadastre Vou, de uso, A Tabola 4 apresenta o fluxo de acbes envolvido ro caso de uso Cadastrar Vefculo. Novamente seguindo 0 processo definido no inicio do artigo, retorna-se A Fiapa I (identiticagio de Classes) Nes- te estudo de caso, as entidades encontradas foram Cliente, Filial, Veculo,Funciondrio, Dependente,Tipos de Veiculo, (Cidade, Distineia, Categoria de Fete, Fretes, Hens de Fre- te, e Parametro (contendo o valor do km rodado) repre- sentando clementos do dominio da aplicacs. ‘A préxima etapa reiere-se a identifcagio dos atributos das clases. A Tabola 8 descreve os aributos identificados, 4 partir dos requisitos inicilmente definidos. Observa-se rovamente que nao estao descitos os atributos de ligagao entre as classes. Isso 6 papel dos relacionamentos. ‘A etapa seguinte refere-se & identificacio das operacbies dias classes. A Tabela 6 resume esta etapa apresentando as principais aperacées das classes do modelo. E importante novamente ressaltar que muitas vezes a identifcagso das ‘operagbes pode ser feta posteriormente, ao se refinar 0 iagrama de classes. CO titimo passa referese &identiticago dos relacionamen- tos e, paraiso, efetua-se a anise dos casos de uso de forma encontrar estas lage entre as classes ideticadas + Generalizagio: veritca-se se hi alguma relacio "é um tipo de” entre as classes identifcalas. Neste es- tudo de easo, como as classes Funcionario e Cliente {ambos sio pessoas fsicas, pelo enunciado do estu- do de caso) possuem atzibutos em comum (nome, enddereco,¢ telefone), optou-se por ciar uma clas- se Pessoabisica que agrupe estas coracteristicas. Uma TipoVeiculo, uma vez esta dikima nao precisa utilizar nenhuma das operacdes definidas na classe Veiculo. O mesmo foi feito na associagie entre as classes Fre te e CategoriaFrete, mantendo a navegabilidade no sentido Frete > CategoriaFrete. + Classe Associativa: verifica-se se existem informa- g6es que precisam estar vinculadas a associagéo de dois objetas. Neste estudo de caso,a classe Distancia est associada ao relacionamento entre dois objetos da classe Cidade, representando a distancia entre clas. Modelam-se situagdes como esta ulilizando uma classe associativa, Feito isto, chega-se 8 versio final do diagrama de classes proposto pelo segundo estudo de caso, que pode ser visto na Figura 26. Novamente, um refinamenio deste diagra- ma ainda precisa ser feito, definindo tipos de atributos e assinaturas das operagoes, com seus eveniuais parametios de entrada e tipos de retorno, para 0 caso de fungbes. Percebe-se na versio final do diagrama da Figura 16 que a classe PessoaFisica tornou-se abstrata (nome da classe em itdlico), A classe Cliente, apesar de nao possuir atribu- tos e nem servigos especificos, justifica-se pelo papel que representa através da associacdo com a classe Frete. Uma nova simbologia que surgiu neste diagrama € a Dependencia, encontrada entre as classes Prete e Parame= ‘ro, indicando que um Frele, para cumprir algama de suas funcionalidades (no caso, o céleulo do frete), depende de servigos da'classe Parametro (neste exemplo, a-obtengao do valor do quilémetro rodado}. Este tipo de ligacao in- dica que a classe Frete utiliza os servicos da classe Para- ‘metro, mas no contém uma referéncia para esta, ou seja, ‘no possui tim atributo do tipo da classe Parametro. Esta é ‘uma situacio ponco indicada, pois ests representando um, acoplamento entre as classes, situagao nao desejével em qualquer projeto de software. Entretanto, quando isto for necessério, a UML disponibiliza esta representagdo gréfi- ‘a, Assim, deve-se perceber que 0 valor do quilémetro ro- dado nio foi colocado na classe Frete, pois a cada instancia desta classe, este valor seria repetido. Neste caso, a classe Parametro forneceré 0 valor do quilémetro rodado, que serd utilizado no cileulo do frete Conclusdo ‘Qualidade em sistemas de software passa pela qualida- de das especificagées © modelagem destes sistemas. Neste sentido, a UML apresenia uma série de diagramas para a construgao de sistemas baseadlos no paradigma da orien- lacao_a objetos. Dentre estes diagramas, o mais importante €0 diagrama de classes, que representa os elementos do dominio do problema, composto pelas classes envolvidas, seus atributos, operagSes e relacionamentos Este artigo teve o objetivo cle apresentar os elementos fundamentais para a constragao destes diagramas de clas- ses, discutindo situagoes ce modelagem que levam & cons- trucao de sistemas bem projetados e, consequentemente, de maior qualidade, m 52 SQLMtagazine UML na Pratica - Construindo Diagramas de ClassesNA TEMPO REAL AGORA VOCE rae vena seus livros usados! Programa de Usados da Tempo Real. Soames pesioshents ibang ese eh rd a csi otmnaronds vocb comara sete ‘Posstolldade de vender seus IMos Usados em Nos Venda seus © compre muite maist $e Soot poets exeae corresrs mau rence Usados com garantia de avaliacdo e ent aprender seu Contetide e depois vandé-io, ss tae eee incense ce ara aes » a www.temporeal.com.br/usados TEMPO REAL’ (Pi crore kn Sl on mes preemies ‘UML na Pratica - Consruindo Diagramas de Classes Ano 334° Edicéo 53