Prática interdisciplinar em desenvolvimento de software I

Transcrição

1 O diagrama de classes é um dos mais importantes e mais utilizados da UML. Seu principal enfoque está em permitir a visualização das classes que comporão o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem informações entre si. Esse diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em como definir a estrutura lógica das mesmas. O diagrama de classes serve ainda como base para a construção da maioria dos outros diagramas da linguagem UML.

2 Basicamente, o diagrama de classes é composto por suas classes e pelas associações existentes entre elas, ou seja, os relacionamentos entre as classes. Alguns métodos de desenvolvimento de software, como o Processo Unificado, recomendam que se utilize o diagrama de classes ainda durante a fase de análise, produzindo-se um modelo conceitual a respeito das informações necessárias ao software.

3 No modelo conceitual, o engenheiro preocupa-se apenas em representar as informações que o software necessitará, em termos de classes e seus atributos, bem como as associações entre as classes, não modelando características como os métodos que as classes poderão conter nessa etapa (os métodos já fazem parte do "como" o software será desenvolvido). Somente na fase de projeto toma-se o modelo conceitual do diagrama de classes e produz-se o modelo de domínio, que já enfoca a solução do problema. Os métodos necessários às classes são descobertos a partir da modelagem de diagramas de interação, como o diagrama de sequência, que será estudado nos próximos capítulos.

4 4.1 Atributos e Métodos Classes costumam ter atributos, que, como já explicado no capítulo 2, armazenam os dados dos objetos da classe, além de métodos, também chamados operações, que são as funções que uma instância da classe pode executar. Os valores dos atributos podem variar de uma instância para outra. Graças a essa característica, aliás, é possível identificar cada objeto individualmente, ao passo que os métodos são idênticos para todas as instâncias de uma classe específica.

5 Embora os métodos sejam declarados no diagrama de classes, identificando os possíveis parâmetros que são por eles recebidos e os possíveis valores por eles retomados, o diagrama de classes não se preocupa em definir as etapas que tais métodos deverão percorrer quando forem chamados, sendo esta uma função atribuída a outros diagramas, como o diagrama de atividade, que será analisado. nos capítulos seguintes. A figura 4.1 apresenta um exemplo de classe contendo atributos e métodos.

6 Como já foi explicado no capítulo 2, uma classe, na linguagem UML, é representada como um retângulo com até três divisões, descritas a seguir:

7 Primeira contém a descrição ou nome da classe, que nesse exemplo é Conta_Comum. Segunda armazena os atributos e seus tipos de dados (o formato que os dados devem ter para serem armazenados em um atributo). No exemplo da figura 4.1 a classe Conta_Comun contém os atributos nro_conta, do tipo long; dt_abertura e dt_encerranento, do tipo Date (este não é um tipo primitivo e se refere a uma classe); situacao e senha, do tipo int; e saldo, do tipo double. Finalmente, a terceira divisão lista os métodos da classe. Nesse exemplo a classe Conta_Comum contém os métodos abrir_conta, consultar_conta, validar_senha, saldo_conta, extrato_conta, sacar_valor, depositar_valor e encerrar_conta.

8 Os símbolos de sustenido (#) e mais (+) na frente dos atributos e métodos representam a visibilidade dos mesmos, o que determina quais objetos de quais classes podem utilizar o atributo ou o método em questão. Os tipos de visibilidade já foram explicados no capítulo 2.

9 Não é realmente obrigatório que uma classe apresente as três divisões, pois pode haver classes que não tenham atributos ou que não contenham métodos, ou pode acontecer ainda que seus atributos e métodos não precisem ser apresentados no diagrama,já que é recomendado apresentar apenas atributos relevantes ao diagrama para evitar, por exemplo, tornar o diagrama muito poluído. Assim, é possível encontrar classes com somente duas divisões ou mesmo com apenas uma, no caso, aquela que contém a descrição da classe, porque esta é obrigatória.

10 Métodos podem receber valores como parâmetros e retomar valores (da mesma forma que as funções implementadas na linguagem de programação C), que podem tanto ser o resultado produzido pela execução do método quanto simplesmente um valor representado se o método foi realizado com sucesso ou não. Nessa classe, por exemplo, podemos perceber que o retorno do método abrir_conta é um long, que conterá o número da nova conta gerada.

11 Por sua vez, o retorno dos métodos consultar_conta, validar_senha, sacar_valor, depositar_valor e encerrar_conta é um inteiro (int), e esse valor é utilizado para determinar se o método foi concluído com sucesso ou não. Por padrão o retorno 1 significa verdadeiro (ou sucesso) e O falso (ou fracasso).

12 Já os métodos saldo_conta e extrato_conta retomam um double e uma String, que contêm o resultado da execução desses métodos. Para o método abrir_conta, se o valor retomado for igual a 1 significará que o método foi concluído com sucesso e que uma nova conta foi aberta. Já se o retorno for igual a zero, saberemos que o método não foi concluído da forma esperada e que algum problema ocorreu.

13 Na figura 4.1 os métodos foram apresentados sem o detalhamento de quais argumentos (parâmetros) eles deveriam receber (a lista de argumentos de um método, junto com seu valor de retorno, é chamada de assinatura da operação). Esse detalhamento é opcional, e isso foi feito propositadamente para explicar os diagramas que serão apresentados no decorrer do capítulo. Alguns métodos podem ter muitos parâmetros, e o detalhamento destes em um diagrama que contenha muitas classes tornará esse diagrama muito extenso e será difícil visualizá-lo claramente como um todo, porque as classes ficarão largas.

14 Assim, é melhor, quando se trata de apresentar um diagrama de classes composto por muitas classes, apresentar somente o nome dos métodos da classe, sem especificar os argumentos que ele receberá. O detalhamento dos métodos de cada classe poderá ser feito individualmente em um diagrama separado, conforme apresentado na figura 4.2.

15

16 Ao examinarmos a figura 4.2 podemos perceber que os métodos abrir_conta e validar_senha recebem um inteiro como parâmetro; o método consultar_conta, um long; sacar_valor, um double; e depositar_valor, um long e um double. Já os outros métodos não recebem argumento algum. A partir do modelo da classe conta_comum apresentada na figura 4.2 é possível gerar o código correspondente a ele. A seguir, será apresentado o código correspondente a essa classe implementado em Java.

17 public class Conta_Comum { protected long nro_conta; protected Date dt_abertura; protected Date dt_encerramento; protected int situacao; protected int senha; protected double saldo; public Conta_Comum() { } public void finalize() throwsthrowable { } public long abrir_conta(int senha){ return 0; public int consultar_conta(long nro_conta){ return 0; }

18 } public int validar_senha(int senha){ return 0; } public double saldo_conta(){ return 0; } public String extrato_conta(){ return ; } public int sacar_valor(doublevalor){ return 0; } public int depositar_valor(long nro_conta, double valor){ return 0; } public int encerrar_conta(){ return 0; }

19 Obviamente esse código é apenas um esqueleto da classe. Como pode-se perceber, não há nenhum detalhamento de como os métodos irão desempenhar sua função. Além disso, será preciso criar uma classe chamada Date para que o compilador reconheça os atributos desse tipo. Observe que o valor de retorno em Java é declarado antes do nome do método, enquanto na UML ele é definido depois do nome do método e dos parâmetros que ele receberá.

20 Os atributos de uma classe podem ainda ter características extras, entre as quais podemos citar valores iniciais, multiplicidade e se o atributo é derivado, ou seja, se seus valores são produzidos por meio de algum tipo de cálculo, conforme apresentado na figura 4.3.

21 Ao estudarmos esse exemplo podemos verificar que o valor inicial dos atributos situacao e saldo será respectivamente 1 e 0 quando da instanciação de um objeto dessa classe durante a abertura de uma nova conta. Dessa forma, sempre que uma nova conta for aberta sua situação inicial terá o valor 1 (está ativa), e o seu saldo permanecerá com valor 0 até que um depósito seja realizado.

22 Pode-se perceber também que o atributo dt_encerramento, após a definição de seu tipo (Date), contém os valores [0..1]. Isso é chamado multiplicidade e, nesse contexto, significa que existirá no mínimo nenhuma (O) e no máximo uma (1) data de encerramento para a conta, uma vez que a conta pode estar aberta ainda e, portanto, não poderá ter uma data de encerramento e, se ela tiver sido encerrada, não poderá ter mais do que uma.

23

24 Finalmente, os atributos dt_abertura, dt_encerramento e saldo têm uma barra (I) antes de seus nomes, significando que os valores desses atributos sofrem algum tipo de cálculo. No caso das datas, quando for realizada a operação de abertura de conta, o valor da data de abertura será tomado da data do sistema, o mesmo ocorrendo com o valor da data de encerramento quando do encerramento da conta.

25 A rigor, não necessariamente isso poderia ser considerado um cálculo e sim uma simples atribuição, sendo que alguns poderiam considerar isso como sendo o valor inicial dos atributos. No entanto, principalmente no caso da data de encerramento, que será deixada indefinida até que a conta seja encerrada, isso não seria verdadeiro, e o valor desse atributo seria definido em uma operação posterior à criação do objeto. Já no caso do saldo, ele precisa ser recalculado sempre que urna operação de saque ou depósito for realizada.

26 4.2 Relacionamentos ou Associações As classes costumam ter relacionamentos entre si, chamados associações, que permitem que elas compartilhem informações entre si e colaborarem para a execução dos processos executados pelo sistema. Uma associação descreve um vínculo que ocorre normalmente entre os objetos de uma ou mais classes.

27 As associações são representadas por linhas ligando as classes envolvidas. Essas linhas podem ter nomes ou títulos para auxiliar a compreensão do tipo de vínculo estabelecido entre os objetos das classes envolvidas nas associações. Há outras informações que uma associação poderá conter, conforme será visto ao longo do capítulo, na medida em que serão apresentadas as diversas formas de relacionamento possíveis em um diagrama de classes.

28 4.2.1 Associação Unária ou Reflexiva Este tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe. Um exemplo de associarão unária pode ser observado na figura 4.4.

29 Ao examinarmos a figura 4.4, é possível perceber que a única classe do exemplo tem o nome Funcionario, e como atributo o nome do funcionário. Observe que uma linha inritulada "chefia" parte da classe Funcionario e atinge a própria classe. Isso ocorre porque, nesse exemplo, um funcionário pode ser chefe de outros funcionários.

30 O chefe de um funcionário também é, por sua vez, um funcionário da empresa e, portanto, também se constitui em uma instância da classe Funcionario. Logo, a associação denominada "chefia" indica uma possível relação entre uma ou mais instâncias da classe Funcionario com outras instâncias da própria classe Funcionario, ou seja, essa associação determina se um funcionário pode ou não chefiar outros funcionários.

31 Observem que existe outra informação na associação, além de seu próprio nome, representada pelo valor 0..* ; Essa informação é conhecida como multiplicidade. A multiplicidade procura determinar o número mínimo e máximo de objetos envolvidos em cada extremidade da associação, além de permitir especificar o nível de dependência de um objeto para com os outros envolvidos na associação.

32 No caso apresentado na figura 4.3, a multiplicidade 0.." indica que um determinado funcionário pode chefiar nenhum (O) ou muitos (*) funcionários, ou seja, um funcionário pode não chefiar ninguém ou pode chefiar um ou mais funcionários. Pode-se perceber que só existe multiplicidade em uma das extremidades, por default, quando não existe multiplicidade explícita e entende-se que a multiplicidade é "1..1'; significando que um e somente um objeto dessa extremidade da associação relaciona-se com os objetos da outra extremidade.

33 Nesse exemplo, significa que um funcionário pode ou não chefiar outros funcionários, mas um funcionário tem um e apenas um funcionário como chefe imediato. A tabela 4.1 demonstra alguns dos diversos valores de multiplicidade que podem ser utilizados em uma associação.

34

35 Outra informação que pode, por vezes, ser considerada útil é a definição de papéis. que são informações extras na associação que podem ajudar a explicar a função de um objeto (o papel que este representa) dentro da associação. Um exemplo do uso de papéis pode ser visto na figura 4.5.

36 Nesse exemplo percebemos claramente qual a função de cada objeto envolvido na associação, sendo que o objeto na extremidade cuja multiplicidade é 1 executa o papel de chefe, enquanto os objetos na extremidade de multiplicidade muitos, interpretam o papel de subordinados, Como pode-se perceber, os papéis desse exemplo têm visibilidade pública, mas podem ter visibilidades protegidas ou privadas. O uso de papéis pode facilitar a compreensão da associação existente, mas nem sempre é necessário, e seu uso excessivo pode deixar os diagramas visualmente muito poluídos.

37 Na verdade, a classe Funcionaria é uma classe persistente (embora não a tenhamos identificado explicitamente como tal), ou seja, suas instâncias deverão ser preservadas de alguma maneira em um banco de dados. No entanto, não é necessário definir atributos do tipo chave primária ou chave estrangeira, como no modelo entidaderelacionamento. Como regra geral, cada classe, ao ser declarada, já tem um código interno implícito, não sendo necessário declarar um atributo exclusivamente para isso. Ao final do capítulo trataremos da questão de persistência e mapeamento de classes em tabelas em bancos de dados relacionais.

38 4.2.2 Associação Binária Associações binárias ocorrem quando são identificados relacionamentos entre objetos de duas classes distintas. Esse tipo de associação é, em geral, a mais comumente encontrada. A figura 4.6 demonstra um exemplo de associação binária.

39 Como podemos verificar na figura 4.6, um objeto da classe Socio pode relacionar-se ou não com instâncias da classe Dependente, conforme demonstra a multiplicidade 0..*, enquanto se existir um objeto da classe Dependente ele terá de se relacionar obrigatoriamente com um objeto da classe Socio, pois, como não foi definida a multiplicidade na extremidade da classe Socio, isto significa que esta é Poderíamos acrescentar informações a essa associação, como definir a navegabilidade da mesma, conforme demonstrado na figura 4.7.

40 A navegabilidade é representada por uma seta em uma das extremidades da associação, identificando o sentido em que as informações são transmitidas entre os objetos das classes envolvidas, ou seja, o sentido em que os métodos poderão ser disparados. Nesse exemplo, um objeto da classe Socio poderá disparar métodos em objetos da classe Dependente, mas a recíproca não é verdadeira: um objeto da classe Dependente não poderá disparar métodos em um objeto da classe Socio.

41 A navegabilidade não é obrigatória, mesmo porque, se não houver setas, significa que as informações podem trafegar entre os objetos de todas as classes da associação.

42 A navegabilidade é uma informação que só deve ser acrescentada na fase de projeto, porém é possível durante a fase de análise definir a direção de leitura da associação, representada, em algumas ferramentas CASE, como um triângulo em forma de seta ao lado do nome da associação, em outras ferramentas, porém, não há diferenciação entre a seta de direção de leitura e a de navegabilidade.

43 A direção de leitura e a navegabilidade não são exatamente a mesma coisa, o sentido de leitura tem como objetivo somente facilitar a compreensão da associação, enquanto a navegabilidade define em que sentido os métodos poderão ser disparados. No exemplo da figura 4.6, o uso da direção de leitura nos transmitiria a informação de que a leitura da associação deveria ser feita da seguinte forma: "Uma instância da classe Socio possui, no mínimo, nenhuma instância e no máximo, muitas instâncias da classe Dependente e uma instância da classe Dependente é possuída por uma e somente uma instância da classe Socio"

44 4.2.3 Associação Ternária ou N-ária Associações tcrnár ias ou n-árias são associações que conectam objetos de mais de duas classes. São representadas por um losango para onde convergem todas as ligações da associação. A figura 4.8 apresenta um exemplo de associação ternária.

45 Nessa ilustração identificamos uma associação que demonstra um fato corriqueiro na maioria das universidades, em que um professor pode lecionar para muitas turmas, uma turma pode ter muitos professores e utilizar muitas salas de aula e um professor, ao lecionar para uma turma específica, pode utilizar mais de uma sala de aula (ele pode ministrar aulas teóricas em salas comuns ou práticas em laboratório).

46 Assim, podemos ler a associação apresentada na figura 4.8 da seguinte forma: Um professor leciona para no mínimo uma turma e no máximo para muitas, uma turma tem no mínimo um professor e no máximo muitos, e um professor, ao lecionar para uma determinada turma, utiliza no mínimo uma sala de aula e no máximo muitas. As associações ternárias são úteis para demonstrar associações complexas. No entanto, deve-se evitar utilizá- Ias, pois sua leitura é, por vezes, difícil de ser interpretada.

47