Baixe o app para aproveitar ainda mais
Prévia do material em texto
x RODRIGO OLIVEIRA SPíNOLA, MARCO ANTÔNIO PEREIRA ARAÚJO ·UML na Prática Construindo Diagramas de Classes ROORIGO OLIVEIRA SPíNOLA (rodrigoêsqlmagazine.cem.bn é Editor Chefe das revistas SQL Magazine e WebMobile. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) e Mestre em Engenharia de' Sistemas e Computação pela COPPEjUFRJ na linha de Engenharia de Software onde atualmente cursa o Doutorado, sendo membro do grupo ESE (Engenharia de Software Experimental). É implementador MPS BR, membro da \I COPPE.Suas áreas de interesse são: processos de software, engenharia. de software orientada a objetos, métricas e complexidade de software, inspeções de software, ambientes de désenvolvimento de software, engenharia de requisitos, integração de ferramentas, engenharia de software experimental e ubiqüidade computacional. 44 SQLMagazine UML na Prátiea- Construindo Diagramas de Classes E xistem diversos pontos críticos causadores de inserção de defeitos durante odesenvol- vimento 'de um software. Podemos citar re- I quisitos, projeto e codificação como alguns - exemplos. Somados a estes pontos críticos, tem-se um qu#o- momento do. desenvolvimento que me- rece uma aténção especial: a/elaboração da soluçã<;>para o 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 à inserção de defeitos no software, são neles em que são transformados os problemas do usuá- rio em uma solução computacional, servindo como uma ponte entre requisitos e codificação. Se esta ponte for mal projetada, o software também será (ver Figura 1). A UML (Unified Modeling Language) apresenta uma série de diagramas parq a modelagem de sistemas orien- tados a objetos. Os diagramas mais comuns são o diagra- ma de casos de uso (representa as funcionalidades de um sistema), o diagrama de classes (ler Nota 1) (descreve as classes do modelo numa visão estática), o diagrama de seqüência, ou seu substituto na UML 2.0, o diagrama de comunicação (descrevem as funcionalidades através de uma visão dinâmica) e o diagrama de estados (apresenta o comportamento dinâmico de um objeto). O objetivo desta matéria é trazer ao leitor algumas boas práticas para elaboração de diagramas de classes, através de sua aplicação prática em dois estudos de caso. Modelagem de classes Existem diferentes caminhos para se chegar ao diagra- ma de classes. Dois dos mais utilizados são: Especificar os casos de uso e, então, partir para o diagrama de classes: neste caso, as classes, seus atri- butos, relacionamentos e métodos são identificados Inserindo defeitos ao longo do desenvolvimento r. Figura 1. Inserindo defeitos no projeto. diretamente a partir dos requisitos de software de- finidos. Pode-se utilizar, em seguida, o diagrama de seqüência para verificar se os relacionamentos e mé- todos definidos fazem sentido. • Especificar os casos de uso, elaborar o diagrama de seqüência e, então, partir para a construção do dia- grama de classes: neste caso, a construção do dia- grama de seqüência ajudará na identificação das classes, relacionamentos e métodos a partir da es- pecificação de requisitos. É uma abordagem muito interessante também. Não existe um caminho mais correto que o outro, de- vendo o desenvolvedor utilizar aquele que se sentir mais a vontade em seguir. Neste artigo será trabalhada a primei- ra opção: caso de uso ® diagrama de classes, que é a forma mais natural de ser utilizada. Neste caso, partiremos para a construção do diagrama de classes atentando para a identi- _ ficação de quatro elementos: entidades (classes) do software, seus atributos, suas operações e o relacionamento entre as classes. Assim, um processo para criação de um modelo de classes pode ser dividido em quatro etapas (ver Figura 2). Etapa 1: Identificação 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 está sendo desenvolvido. Elas permitem descrever um conjunto de objetos que compar- tilhem os mesmos atributos, operações, relacionamentos e semântica, e representam o principal bloco de construção de um software orientado a objetos. Seguindo nossa abordagem para a construção do diagra- ma de classes (partindo da especificação dos casos de uso), para identificá-Ias, procura-se na especificação por concei- tos que representem objetos do domínio da aplicação a ser desenvolvida. A Figura 3 apresenta a simbologia para uma classe chamada ContaBancaria utilizando a UML. Etapa 2: Identificação de atributos Com as classes definidas, precisam-se especificar quais são seus atributos. Estes são as propriedades que caracteri- """"""'.-...........,. ~ ~ -- UML na Prática" Construindo Diagramas de Classes Ano 3 34a Edição 45 Figura 2. Elaborando uma solução computacional. Nota 1. Diagrama de classes De forma simplificada. um diagrama de classes descreve os "tipos" de objetos do software e os vários tipos de relacionamentos estáticos que existem entre eles. De todos os diagramas da UML. este é o diagrama mais comumente utilizado pelas empresas. zam um objeto. Por exemplo, uma entidade conta bancária possui como atributos o número e o saldo. É bastante sim- ples identifi~~r os atributos de' cada classe, basta identificar as características que descrevam sua classe no domínio do problema em questão. Note que os atributos identificados devem! estar alinhados com as necessidades do usuário para o problema. A Figura 4 apresenta a classe ContaBancaria com alguns de seus atributos. É importante observar o sinal" _" à es- querda do nome dos atributos. Isto indica que os mesmos são privados, encapsulados, proibindo que seu conteúdo seja manipulado por operações que não sejam da própria classe. Isso proporciona maior independência da classe, aumentando sua possibilidade de reutilização. Ainda te- mos mais dois sinais: "+" e "#". O sinal "+" indica que um atributo é público (ou seja, este pode ser acessado por qualquer outro objeto) e o sinal "#" indica um atributo protegido, podendo ser herdado por subclasses. Etapa 3: Identificação de operações Identificadas as classes e seus atributos, o próximo pas- so é a identificação das operações de cada classe, também ICodaBancaria l Figura 3. Classe ContaBancaria. ContaBancaria -Numero -Saldo Figura 4. Classe ContaBancaria com seus atributos. chamadas de métodos ou serviços. Fazendo um paralelo com objetos do mundo real, operaçoes são ações que o objeto é capaz de efetuar. Dessa forma, ao procurar por operações, devem-se identificar ações que o objeto de uma classe é responsável por desempenhar dentro do escopo do sistema que será desenvolvido. A Figura 5 apresenta algumas operações da classe ContaBanc"aria. Ao contrário " dos atributos, normalmente operações são públicas, per- mitindo sua utilização por outras classes e objetos. . Etapa 4: Identificação de relacionamentos O último passo a ser executado na construção de um diagrama de classes é a definição dos relacionamentos en- tre as classes do modelo. Para isso, deve-se entender um pouco sobre os tipos de relacionamentos que podem apa- recer entre classes em um diagrama de classes. Os tipos de relacionamento mais utilizados são: • Generalização (Herança): denota relações "é um tipo de", onde subclasses são especializações de superclasses e herdam seus atributos e operações. O segredo na identificação correta deste tipo de relacionamento está na semântica "é um tipo de". Isto porque as pessoas, muitas vezes, utilizam o re- lacionamento de herança como um mecanismo de reutilização esquecendo-se da semântica associada ao relacionamento. Não é porque Cliente e Agência possuem algum atributo em comum, como nome, que devam herdar de uma superclasse chamada "Cliente_Agência". Percebe-se que esta entidade não faz sentido algum. Na Figura 6 tem-se um exemplo de generalização definindo as classes Conta Corrente e ContaPoupan- ca comosubclasses de ContaBancaria. . Associação: representa uma relação estrutural entre duas classes indicando que estas se comunicam atra- vés de troca de mensagens. É representada por uma linha simples ligando duas classes (ver Figura 7) e pode conter atributos como nome, multiplicidade e navegabilidade. O nome representa a semântica do relacionamento indicando o porquê das classes esta- rem relacionadas; a multiplicidade indica a quantos objetos de uma determinada classe um objeto pode se comunicar; e a navegabilidade especifica quem enxerga quem no relacionamento, ou seja; se um objeto tem conhecimento da existência de outro. Por exemplo, a Figura 7 informa o seguinte: o um objeto da classe ContaBancaria está associado a nenhum ou vários objetos da classe Cliente (no caso de conta conjunta). Essa informação é transmitida através do indicador de multiplicidade (O .. *) mais pró- ximo à classe Cliente; o um objeto da classe Cliente pode estar asso- ciado a nenhum ou vários objetos da classe 46 SQLMagazine UML na Prática - Constl1lindo Diagramas de Classes ContaBancaria. Essa informação é transmi- tida através do indicador de multiplicidade (O .. *) mais próximo à classe ContaBancaria; • Auto-Associação: uma classe ainda pode associar-se com ela mesma, caracterizando uma auto-associa- ção. A Figura 8 apresenta uma auto-associação 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. Agregação: é uma associação cuja semântica é "par- te de". Neste tipo de relacionamento, tem-se uma classe representando o 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 número da agência e pelo número da conta (ver Figura 9). Esta figura ainda indi- ca que um objeto da classe Agencia está relacionado a vários objetos da classe ContaBancaria, enquanto que um objeto da classe ContaBancaria está relacionado a um único objeto da classe Agencia. Uma agregação é representada por uma linha simples com um losango sem preenchimento do la,do do todo. Composição: é uma associação que expressa a se- mântica "parte de" mais "fortemente". Neste caso, /,,:' CortaB ancari a -Numero -Saldo +E fetuarSaqueO +E fetuarD epositoO +EmitirSaldoO +E mitirEldratoO .I Figura 5. Classe Conta Bancaria com seus atributos e operações. ComBancalia t>- I ComCorreme ComPoupanca I I I -FIgura 6. Generalização de classes. I C_.ncaria I O..' Cliente O.! Figura 7. Associação entre classes. CortaB ancari a 0 ..1 - Contal n vestim ento . 0 ..1 I'---------' Figura 8. Auto-associação em uma classe. ---- -- ----------------------------------------- I. I I se o objeto que representa o todo for destruído, suas partes obrigatoriamente também serão. Por exem- plo, quando se destrói uma ContaBancaria, todas as suas Movimentações também precisam ser destruí- das (ver Figura 10). Além disso, uma composição in- dica que, para acessar os métodos de uma classe que represente a "parte", deve-se primeiro interagir com a classe que representa o "todo". É a classe "todo" quem interage com suas classes" parte". Uma com- posição é representada por uma linha simples co~ um losango preenchido do lado do todo. Navegação: representa se um objeto possui uma re- ferência para um outro numa associação. A maioria das ferramentas CASE para modelagem 00 assu- me que o padrão de associaçõ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 o esforço de desenvolvimento, seja por re- almente não ser necessária a comunicação entre ob- jetos num determinado sentido. A Figura 11 exibe uma navegação da classe Movimentacao (de Contas Bancárias) para a classe Tipolvlovimentacao. Isso in- dica que a classe Movimentacao "conhece" a classe TipoMovimentacao e pode interagircom ela. O con- trário não é verdade. Neste exemplo, pode não fa- zer sentido dado um tipo de movimentação (trans- ferência, por exemplo), saber quais movimentações que aconteceram para este tipo, em todas as contas. O sinal do "X" não é padrão em todas as ferramen- tas CASE. Restrições de navegabilidade podem ser feitas em associações, agregações e composições .. Para identificar se uma navegabilidade é necessária ou não, uma boa possibilidade é analisar o conjun- to de diagramas de seqüência do sistema, caso estes existam. Desta forma, navegabilidades podem ser definidas num segundo momento, quando do refi- namento do diagrama de classes, após a construção dos diagramas de seqüência. • I I I l I I. I ~ ~ I ! t Por exemplo, a Figura 11 informa o seguinte: o um objeto da classe Movimentacao sabe a qual objeto da classe TipoMovimentacao estará se comunicando. Essa informação é transmitida através do indicador de na- vegabilidade (a seta). Em código, 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; o um objeto da classe TipoMovimentacao não' sabe que objeto da classe Movimen- tacao está utilizando. Essa informação é transmitida através do indicador de nave- gabilidade (o símbolo "X", ou a falta dele numa associação unidirecional). Em códi- go, isso significa que a partir de um objeto da classe TipoMovilnentacao não se conse- gue referenciar diretamente um objeto da classe Movimentacao. • Classe associativa: representa situações onde de- terminados atributos não podem ser colocados em nenhuma das classes participantes de uma associa- ção, por conter informações referentes exclusivas à ligação dos objetos das duas classes. A Figura 12 demonstra que a Validade e Senha de um cartão são diferentes para cada um dos clientes de uma mes- ma conta. Ou seja, dado um objeto Cliente associa- do com um objetoContaBancaria, tem-se um objeto Cartao com informações diferentes. lio--~---- -- ----- UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 47 Estudo de caso 1 Para o primeiro estudo de caso deste artigo, será consi- derado um fragmento de um Sistema de Controle Bancá- rio. Para este sistema, o gerente deve cadastrar agências, clientes e abrir e fechar contas bancárias. Um cliente pos- sui nome, endereço e telefone. Um cliente pode abrir vá- . I rias contas e ú;n.a)::onta pode ser de vários clientes, para o "/ " A.oná. fd O..' :1 C•••••••• ori. 1 Figura 9.: Agregação entre classes. Movirnentac ao 1 CortaBancaria 1...•.. 1 I-Valor . O.." -Data Figura 10. Composição entre classes. Movi rnenta c ao O .. " TipoMovimentacao -Valor .i ..•.. -Descricao -Dsta I'" '1 ...--O ebito _Credito Figura 11. Navegabilidade entre classes ===c:'::..:i_ent::e:~~il-.:::O:.:.," __ O_.._._I C•••••••••••• Cartao -Validade -Senha Figura 12. Classe associativa. caso de contas conjuntas. Contas são de uma determinada agência (que possui nome e númerp), 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 número (formado pelo número da agência e pelo número da própria conta) e saldo disponível, poden- do ser corrente normal, corrente especial e poupança. Para " contas poupança, devem-se armazenar os dias de venci- mento e, para contas corrente especiais, informar o limite de crédito. Contas ainda possuem movimentações de sa- qu~ e depósito, que devem ter data e valor, além do tipo de movimento, que pode ser débito ou crédito. Clientes ainda podem solicitar cartões de contas bancárias, que devem ter número, validade e senha para cada cliente, além de talões de cheques para contas correntes, que devem armazenar o número inicial e final das folhas. do talão. O sistema ainda deve permitir aos clientes consultar saldos e extratos. O diagrama de casos de uso da Figura 13 apresenta as principaisfuncionalidades do sistema. No diagrama de casos de uso da Figura 13, 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 ao definirmos um diagrama de casos de uso, o mais importante não é o diagrama em si, mas sua especificação. Por questão de espaço, será apre- sentada a especificação de apenas um dos casos de uso apresentados no diagrama da Figura 13. Observa-se na Tabela 1 o fluxo de ações envolvido no caso de uso Ca- dastrar Cliente. Seguindo o processo anteriormente definido, a Etapa 1 (Identificação de Classes), objetiva encontrar as classesdo modelo. Neste estudo de caso, as entidades encontradas foram Agência, Conta, Conta Corrente, Conta Corrente Nor- mal, Conta Corrente Especial, Conta Poupança, Movimenta- ção, Tipo de Movimentação, Talão de Cheques e Cartão de Conta, representando elementos do domínio da aplicação. É importante atentar para a entidade Gerente. O fato dela representar um ator do sistema não significa neces- sariamente que deverá estar contemplada no diagrama de classes. Então, como se pode definir se um ator participará ou não de um diagrama de classes? Basta atentar para o fato de haver a necessidade de manter algum atributo e/ou realizar alguma operação sobre ele. Neste estudo de caso, o Gerente não será uma classe, pois essas necessidades não estão presentes. A próxima etapa refere-se à identificação dos atributos das classes. A Tabela 2 descreve os atributos identificados a partir dos requisitos inicialmente definidos. Observa-se que rtão estão descritos os atributos de ligação entre as classes. Isso é papel dos relacionamentos. A etapa seguinte refere-se à identificação das operações das classes. A Tabela 3 resume esta etapa apresentando as principais operações das classes do modelo. É impor- tante ressaltar que muitas vezes a identificação das opera- 48 SQLMagazine UML na Prática - Construindo Diagramas de Classes 'RI ? Eenacy-* E~ ec,me'(c~~ ~ e>-*-+~I~ Gerentee Figura 13. Diagrama de casos de uso. ções pode ser feita posteriormente, ao refinar o diagrama de classes. Uma boa ferramenta da UML para detalhar o comportamento de casos de uso numa visão orientada a objetos e, consequentemente, auxiliar na descoberta das operações, é o diagrama de seqüência. O último passo refere-se à identificação dos relaciona- mentos e, para isso, efetua-se a análise dos casos de uso de forma a encontrar estas relações entre as classes já identificadas: • Generalização: verifica-se se há alguma relação "é um tipo de" entre as classes identificadas. Neste es- tudo de caso, ContaCorrente e ContaPoupanca "são tipos de" ContaBancaria, enquanto Conta Corrente- Especial" é um tipo de" ContaCorrente. • Associação: verifica-se se há a necessidade de um objeto de uma classe utilizar serviços disponibiliza- dos por }:ll!l objeto de outra classe ou, simplesmen- te, "córl'hécer" o outropbjeto. Neste estudo de caso, tem-se que uma conta bancária está relacionada com um ou mais clientes e um cliente pode possuir mais de uma conta bancária. Insere-se então uma 'associação entre estas classes. Existe uma segunda associação entre Movimentacao e TipoMovimenta- cao, onde uma movimentação é de um único tipo de movimentação e um tipo de movimentação pode estar relacionado a diversas movimentações. Verifi- ca-se ainda uma terceira associação entre as classes ContaCorrente e TalaoCheques, onde uma conta corrente pode possuir vários talões de cheques e um talão de cheques é de uma única conta corrente. Esta associação não poderia ter sido feita na classe ContaBancaria uma vez que uma conta poupança não possui talões de cheques. • Auto-Associação: verifica-se se existe alguma classe que necessita ser relacionada a ela mesma. Neste estu- do de caso; existe uma auto-associação na classe Con- taBancaria, representando uma conta de investimen- tos, que nada mais é que uma outra conta bancária. • Agregação: verifica-se se há alguma relação "parte de". entre as classes identificadas. Neste estudo de caso, tem-se que uma agência (o todo) é composta de diversas contas bancárias (as partes). Percebe-se ainda que a identificação da conta bancária é feita pelo número da agência, acrescido do número da própria conta bancária. Daí, modela-se este relacio- namento através de uma agregação. Este caso de uJio permite o cadastro (inclusão) de clientes do banco. Cadastrar Cliente Gerente o caso de uso é iniciado quando o Gerente seleciona a opção Cadastrar Cliente. Sistema apresenta janela com os campos nome, endereço e telefone. Gerente preenche campos e selecioça a opção Efetuar Cadastro. Sistema valida as informações preenchidas pelo gerente (EX01). Os campos devem estar todos preenchidos e de acordo com o domínio (tipo) do atributo. Se houver problemas no preenchimento do formulário o sistema exibe a mensagem de erro: "Existem dados inválidos no formulário ou algum campo não foi preenchido". Caso o cliente já se encontre cadastrado, a mensagem "Este cliente já possui cadastro" é apresentada. Sistema cadastra cliente (EX02) e volta para a tela inicial. Neste momento, este caso de uso é encerrado. Tabela 1. Descrição do caso de uso Cadastrar Cliente. Classe Atributos Agencia Nome Numero Conta Bancaria Numero Saldo , ContaCorrenteEspecial LimiteCredito ContaPoupanca DiasVencimento Nome Cliente Endereço Telefone Numero Cartão Validade Senha Movimentacao Data Valor TipoMovimentacao Descricao Debito_Credito Tabela 2. Identificação dos atributos das classes. Composição: verifica-se se há alguma relação "parte de" forte entre as classes identificadas. Neste estudo de caso identifica-se um relacionamento deste tipo entre as classes ContaBancaria e Movimentacao, uma vez que as movimentações são como atributos .internos de contas bancárias. Além disso, a exclusão de 'uma conta bancária necessariamente implica na exclusão de suas movimentações. Neste caso, mode- la-se esta situação através de uma composição. • Navegação: verifica-se se existem "navegações" des- necessárias entre classes. Neste estudo de caso, na associação entre as classes Movimentacao e Tipo- Movimentacao, utilizou a navegabilidade no senti- do Movimentacao ® TipoMovimentacao, uma vez que esta última não precisa utilizar nenhuma das operações definidas na classe Movimentacao. Classe Operações EfetuarSaque Efetuarüepostto Conta Bancaria EmitirSaldo /' EmitirExtrato ?'" -'" " /. policitarCartao Conta Corrente SolicitarTalao Cartão ,,'(IalidarSenha Verif Movimentacao EfetuarMovimentacao Tabela 3. Identificação das operações. Classe Associativa: verifica-se se existem informa- ções que precisam estar vinculadas à associação de dois objetos (mas não a um deles em particular). Neste estudo de caso, o número, validade e senha de cartões de contas bancárias são diferentes para cada um dos clientes de uma mesma conta bancária. Modela-se esta situação utilizando-se uma classe associativa. Feito isto, chega-se à versão final do diagrama de classes proposto pelo estudo de caso, que ,pode ser visto na Figu- ra 14. Um refinamento deste diagrama ainda precisa ser feito, definindo tipos de atributos e assinaturas das opera- ções, com seus eventuais parâmetros de entrada e tipos de retorno para o caso de funções. Percebe-se na versão final do diagrama da Figura 14 que a classe ContaBancaria tornou-se abstrata. Em,UML isso é representado pelo nome da classe em itálico. Uma classe abstrata não instancia objetos e é criada com a finalida- de de agrupar atributos, métodos e/ou relacionamentos comuns a outras classes. Não se deve achar que toda su- UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 49 Cliente -Nome -Endere6'Õ" -Telefõne CarUo -Numero o ..' -Vãlidade -Senha------- .•Vali darSenhaD Agencia 1 O ..' +VeriftcarVelidade O -Nome C CotrtilBlMcali. -Numero O .. ' -Numero -Saldo .-:' MovimeIdIIc:ao +E fetuarDeposRo() - O ..' -Valor +E fetuarSaqueO-Data..•. +EmftirSaldoO +E fetuarM ovim entacaoO 0 ..1 +E mftir!llclrato()r- +SoliátarCartaoO O ..' Contal n vestim ento 0 ..11 \1 1 •~ TipoMouimentJlcao ra'aoCheCJJes COIÚCorrerte I I COIÚPaupan:a I -Descricao -Numerolnicial O . .' -NumeroFinal 1 +SoliátarTalao() I-DiasVencimento I -Debfto_Credito ? L COIÚCorrerteE 8pecia' I I-LimiteCredRo I Figura 14. Diagrama de classes. seu número de matrícula, e devem conter ainda nome, endereço, telefone e depen- dentes (com nome e data de nascimento), além de estar associado, obrigatoriamen- te, a uma filial. Tipo de Veículo apresenta uma descrição (como caminhão e moto) e o peso máximo que pode transportar, além de estar associado a veículos. Cida- des contêm o nome da cidade e o estado a que pertence, representando as cidades abrangidas pela empresa de transporte . Distâncias envolvem as cidades origem .e destino e, para cada par de cidades aten- didas, deve haver a distância em quilô- metros entre elas. Categoria do frete deve conter descriçã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 não tem acréscimo no valor. Cada Frete tem um código, um cliente, o veículo que deve efetuar o frete, cidade origem e ci- dade destino, funcionário responsável e _ itens a serem ,transportados, não podendo - .: haver um frete sem os dados citados. Cada,.-'. , ~ . frete deve te! ainda o seu valor, que deve ser calculado através da distância entre as cidades envolvidas e da categoria do fre- te. Para isso, deve existir um valor padrão para o km rodado. Um Item de Transporte é cada objeto a ser transportado num frete e deve possuir apenas uma descrição e seu peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com todas as infor- mações de um determinado frete, logo após seu cadastramento. A Figura 15 apresenta o diagrama de casos de uso com as principais funcionali- dades deste sistema. No diagrama de casos de uso da Figura 15, observa-se que, como é o funcionário quem utiliza todas as funções do sistema, todos os casos de uso estão ligados a ele. Outra característica é relativa ao caso de uso EmitirNotaFiscal. Como este caso de uso é disparado sempre que um fre- te for cadastrado, representa-se esta situação utilizando uma seta com o estereótipo" < < Include >»", indicando que o caso de uso CadastrarFrete dispara o caso de uso EmitirNotaFiscal. Este tipo de situação é utilizado quando se deseja destacar uma funcionalidade do sistema, como neste caso, ou quando uma determinada funcionalidade é utilizada por mais de um caso de uso, evitando que seja descrita mais de uma vez. Mais uma vez, destaca-se a importância em especificar cada um dos casos de uso presentes no diagrama de casos ~*E ~ FundonarioCadastrarCategOri~ I Figura 15. Diagrama de casos de uso. perclasse é abstrata. Por exemplo, a classe Conta Corrente é concreta, podendo instanciar objetos. Caso seja aberta uma conta corrente comum, esta é instanciada a partir desta classe. Estudo de caso 2 o segundo estudo de caso considera um fragmento de um sistema para uma Transportadora. Para este sistema, os funcionários da transportadora devem cadastrar Clientes, Filiais, Veículos, Funcionários, Tipos de Veículos, Cidades, Distâncias, Categorias de Frete e Fretes de Clientes. Clientes são pessoas físicas e possuem nome, endereço e telefone. Filiais têm nome, endereço, telefone, funcionário responsável e vários veículos. Veículos devem possuir nú- mero de placa e um tipo de veículo, além de ser necessa- riamente de uma filial. Funcionários são identificados pelo 50 SQLMagazine UML na Prática- Construindo Diagramas de Classes x Cadastrar Veículo Este caso de uso.permite o cadastro (inclusão) de veículos da Transportadora. o caso de uso é iniciado quando o Funcionário seleciona a opção Cadastrar Veículo. Sistemá apresenta janela com os campos número da placa, tipo de veículo e filial. Funcionário preenche campos e seleciona a opção Efetuar Cadastro. Sistema valida as informações preenchidas pelo Funcionário (EX01). Sistema cadastra veículo (EX02) e volta para a tela inicial. Neste momento, este caso de uso é encerrado. Os campos devem estar todos preenchidos e de acordo com o domínio-ttlpo) do atributo" Se houver problemas no preenchimento do formulário o sistema exibe a mensagem de erro: "Existem dados inválidos no formulário ou algum campo não foi preenchido". . . Caso o veículo já se encontre cadastrado, a mensagem "Este veículo já possui cadastro" é apresentada. Tabela 4. Descrição do caso de uso Cadastrar Veículo. de uso. A Tabela 4 apresenta o fluxo de ações envolvido no caso de uso Cadastrar Veículo. Novamente seguindo o processo definido no início do artigo, retoma-se à Etapa 1 (Identificação de Classes). Nes- te estudo de caso, as entidades encontradas foram Cliente, Filial, Veículo, Funcionário, Dependente, Tipos de Veículo, Cidade, Distância, Categoria de Frete, Fretes, Itens de Fre- te, e Parâmetro (contendo o valor do km rodado) repre- sentando elementos do domínio da aplicação. A próxima etapa refere-se à identificação dos atributos das classes. A Tabela 5 descreve os atributos identificados a partir dos requisitos inicialmente definidos. Observa-se novamente que não estão descritos os atributos de ligação- entre as classes. Isso é papel dos relacionamentos. A etapa seguinte refere-se à identificação das operações das classes. A Tabela 6 resume esta etapa apresentando as principais operações das classes do modelo. É importante novamente ressaltar que muitas vezes a identificação das operações pode ser feita posteriormente, ao se refinar o diagrama de classes. O último passo refere-se à identificação dos relacionamen- tos e, para isso/efetua-se a análise dos casos de uso de forma a encontrar estas relações entre as classes já identificadas: • Generalização: verifica-se se há alguma relação "é um tipo de" entre as classes identificadas. Neste es- tudo de caso, como as classes Funcionario e Cliente (ambos são pessoas físicas, pelo enunciado do estu- do de caso) possuem atributos em comum (nome, endereco, e telefone), optou-se por criar uma clas- se PessoaFisica que agrupe estas características. Uma dúvida poderia surgir em relação à classe Filial, que possui os mesmos atributos. Neste caso, não será con- siderada herança entre estas classes, mesmo conten- do os mesmos atributos. Isso por que uma Filial não é uma pessoa física e, portanto, não deve haver herança . Classe Atributos Nome Cliente Endereco Telefone Nbme Filial Endereco ITelefone Veiculo /(/ , NumPlaca 'I / ~ " "Matricula Funclonario Nome "'" Endereco , Telefone Dependente Nome DataNascimento I- Descricao '"'TipoVeiculo " "••! 'Pesovlaximo" " , Cidade Nome Estado Distancia Quilometros Categoria Frete Descricao Percentual Código Frete Valor NumNotaFiscal ItemFrete Descricao Peso Parametro ValorKmRodado Tabela 5. Identificação dos atributos das classes. Classe Operações Frete Cálcu)arFrete EmitirNotaFiscal Item Frete ObterPeso Categoria Frete ObterPercentual TipoVeiculo ObterPesoMaximo Distancia ObterDistancia Tabela 6. Identificação das operações. UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 51 --------------------------------------------------------~/ • (a semântica" é um tipo de" não se aplica). Associação: verifica-se se há a- necessidade de um objeto de uma classe utilizar serviços disponibiliza- dos por um objeto de outra classe ou, simplesmen- te, "conhecer" o outro objeto. Neste estudo de caso, observam-se várias associações no modelo, como entre Frete e Cliente (um frete é' de um cliente e um cliente pode fazer vários fretes), entre Frete e Veiculo (um frete possui um veículo e um veículo pode fazer vários fretes), entre Frete e Funcionaria (um frete possui um funcionário responsável e um funcionário pode ser responsável por vários fretes), entre Frete e CategoriaFrete (um frete possui uma categoria e uma categoriapode estar associada a vá- rios fretes), entre Frete e Cidade (neste caso, existem duas associações entre estas classes, uma vez que um frete tem uma cidade representando sua origem e outra seu destino e, além disso, cidades podem ser origem e/ou destino de diferentes fretes), entre Filial e Funcionaria (uma filial possui diversos funcioná- rios e um funcionário está latada numa filial), entre Filial e Veiculo (uma filial possui diversos veículos e um veículo é de uma única filial) e, finalmente, en- tre Veiculo e Tipoveiculo (um veículo tem um tipo e um tipo pode estar associado a diferentes veículos). Auto-Associação: verifica-se se existe alguma clas- se que necessita ser relacionada a ela mesma. Neste estudo de caso.existe uma auto-associação na classe Cidade, representando que uma cidade pode estar associada a diversas outras, representando as dis- tâncias atendidas pela empresa de transportes. Agregação: verifica-se se há alguma relação "parte de" entre as classes identificadas. Neste estudo de caso, não foi necessária a utilização de agregações. Composição: verifica-se se há alguma relação "parte de" forte entre as classes identificadas. Neste estudo de caso identificam-se dois relacionamentos deste tipo, um entre as classes Funcionaria e Dependente, uma vez que os dependentes são como atributos in- .ternos de funcionários; e outro entre as classes Fre- te e ItemFrete, pelo mesmo motivo de estar repre- sentando atributos internos que foram deslocados para outra classe em função de suas características próprias e também pela multiplicidade. Além disso, a exclusão de um funcionário necessariamente im- plica na exclusão de seus dependentes, bem como a exclusão de um frete implica na exclusão de seus itens. Nestes casos, modelam-se estas situações atra- vés de composições. Navegação: verifica-se se existem navegações des- necessárias entre classes. Neste estudo de caso, na associação entre as classes Veiculo e TipoVeiculo, utilizou-se a navegabilidadeno sentido Veiculo ~ TipoVeiculo, uma vez esta última não precisa utilizar nenhuma das operações definidas na classe Veiculo. . O mesmo foi feito na associação entre as classes Fre- te e CategoriaFrete, mantendo a navegabilidade no sentido Frete ~ CategoriaFrete . . Classe Associativa: verifica-se se existem informa- ções que precisam estar vinculadas à associação de dois objetos. Neste estudo de caso, a classe Distancia está associada ao relacionamento entre dois objetos da classe Cidade, representando a distância entre elas. Modelam-se situações como esta utilizando uma classe associativa. Feito isto, chega-se à versão final do diagrama de classes proposto pelo segundo estudo de caso, que pode ser visto na Figura 16. Novamente, um refinamento deste diagra- ma ainda precisa ser feito, definindo tipos de atributos e assinaturas das operações, com seus eventuais parâmetros de entrada e tipos de retorno, para o caso de funções .. Percebe-se na versão final do diagrama da Figura 16 que a classe PessoaFisica tornou-se abstrata (nome da classe em itálico). A classe Cliente, apesar de não possuir atribu- tos e nem serviços específicos, justifica-se pelo papel que representa através da associação com a classe Frete. Uma nova simbologia que surgiu neste diagrama é a Dependência, encontrada entre as classes Frete e Parame- tro, indicando que um Frete, para cumprir alguma de suas funcionalidáj,ys(no caso, o cálculo do frete), depende de serviços daclasse Parametro' (neste exemplo, aobtenção do valor do quilômetro rodado). Este tipo de ligação in- dica que a classe Frete utiliza os serviços da classe Para- metro, mas não contém uma referência para esta, ou seja, não possui um atributo do tipo da classe Parametro. Esta é uma situação pouco indica da, pois está representando um acoplamento entre as classes, situação não desejável em qualquer. projeto de software. Entretanto, quando isto for necessário, a UML disponibiliza esta representação gráfi- ca. Assim, deve-se perceber que o valor do quilômetro ro- dado não foi colocado na classe Frete, pois a cada instância desta classe, este valor seria repetido. Neste caso, a classe Parametro fornecerá o valor do quilômetro rodado, que será utilizado no cálculo do frete. Conclusão Qualidade em sistemas de software passa pela qualida- de das especificações e modelagem destes sistemas. Neste sentido, a UML apresenta uma série de diagramas para a construção de sistemas baseados no paradigma da orien- tação a objetos. Dentre estes diagramas, o mais importante é o diagrama de classes, que representa os elementos do domínio do problema, composto pelas classes envolvidas, seus atributos, operações e relacionamentos. Este artigo teve o objetivo de apresentar os elementos fundamentais para a construção destes diagramas de clas- ses, discutindo situações de modelagem que levam à cons- trução de sistemas bem projetados e, consequentemente, de maior qualidade. • 52 SQLMagazine UML na Prática - Construindo Diagramas de Classes • • • • Parametro Distancia Vai orKmRodado Qui 10m etros~ - - PessoaFiBica +0 bterVal orKm Rodad 00 +0 bterD istanciaO -Nome -Endereco '1\ 1 1 Dependente -Telefone 1 1 1 1 -Nome ~ 1 -DataNascim ento 1 O ..• 1 Cliente 1 O." I • Ol,igem Cidade 1 1 1 , -Nome O."~ 1 1 I -Estado 1 ~. I O."O.' I Frete 1Fmcionario -Codigo -Matricula 1 Destino-Valor O."O.' Itenf'rete-N umNotaF iscal O." Veicuo 1 ..-1 -Descrtcao+CalcularFr~eO -Peso-NumPlaca O." +E m itirNotaFi scalO -- O."O." +0 bterP esoí) O." . 1O." ~1 1 TipoVeiculo CategoriaFrete Filial 1 -Deserieao -Deserícao -Nome -P ésoM axim o -P ercentual -Endereco -Telefone +0 bterPesoM.imoO _+ObterPercentualO /",1" " t I f-I I I I ! I I I ! ! Figura 16. Diagrama de Classes / Programa de Usados da Tempo Real. o melhor lugar para você vender seus livros é o lugar onde você compra sempre. Venda seus livros e compre muito mais! Usados com garantia de avaliação e entrega. A TEMPO REALinova oferecendo aos seus clientes a possibilidade de vender seus livros usados em nosso site. Você pode agora comprar seu livro, estudar e aprender seu conteúdo e depois vendê-Io, recuperando parte do seu investimento! l ~'. Acesse agora : Awww.temporeal.com.br/usados j ,1 é conheça esta exclusividade da Livraria do Profissional de Informática I.MlARIA DO PROFISSIONAl DE INFORMÁTlCA UML na Prática" Construindo Diagramas de Classes Ano 3 34a Edição 53
Compartilhar