UML: Diagrama de Casos de Uso, Diagrama de Classes

Transcrição

1 UML: Diagrama de Casos de Uso, Diagrama de Classes Diagrama de Casos de Uso O modelo de casos de uso visa responder a pergunta: Que usos (funcionalidades) o sistema terá? ou Para que aplicações o sistema será empregado? Na UML, o modelo de casos de uso é representado por um diagrama de casos de uso, que poderá ser decomposto em subdiagramas para facilitar o entendimento. De forma resumida, o diagrama de casos de uso é uma coleção de atores, casos de uso e os relacionamentos entre estes. Os clientes e os usuários finais do sistema em desenvolvimento têm interesse especial na modelagem que está sendo construída através do diagrama de casos de uso e, portanto, a participação dos clientes na construção deste modelo é fundamental. A figura 1 mostra um caso de uso hipotético chamado Cadastrar Aluno, que faria parte de um software de secretaria de uma escola. Fig. 1: Caso de Uso Cadastrar Aluno. Percebe se, na figura 1, que o caso de uso Cadastrar Aluno é disparado pelo ator Secretária e possui um relacionamento com o ator SGDB (Sistema Gerenciador de Banco de Dados). As demais etapas do processo de desenvolvimento de software estão preocupadas com a realização dos casos de uso, ou seja, pretendem definir quais classes e objetos serão necessários para implementar as funcionalidades descritas no modelo de casos de uso. Diagrama de Classes Uma vez identificados os Atores e Casos de Uso do sistema, pode se iniciar o projeto do software, que consiste em definir os componentes do sistema e as relações entre eles. Em um projeto orientado a objetos, os componentes estruturais do sistema são as classes. O diagrama de classes expressa a arquitetura do sistema, também conhecida como estrutura estática pois aquilo que é descrito é sempre válido em qualquer ponto do ciclo de vida do sistema (em qualquer uma das fases do RUP: concepção, elaboração, construção e transição). No diagrama de classes também é mostrada a interação entre as classes, já que, muitas tarefas somente são possíveis através da colaboração entre as instâncias das classes (os objetos). A notação padrão da UML para representar uma Classe de Objetos é dada pela figura 2. Nota se que a classe é representada por um retângulo,

2 subdividido em três áreas: a primeira contém o nome da classe, a segunda contém os atributos (variáveis) da classe e a terceira contém os seus métodos (funções). Fig. 2: Notação UML para classe de objetos. A UML padroniza a forma de desenhar e escrever os elementos que constituem uma classe. Na figura 3, nota se que elementos (atributos e métodos) precedidos de um sinal de menos ( ) são elementos privados (só podem ser acessados de dentro da classe), elementos precedidos de + são públicos (podem ser acessados de dentro e de fora da classe) e elementos precedidos de # são protegidos (só podem ser acessados de dentro da classe e a partir das classes derivadas). Fig. 3: Sintaxe para escrever os elementos que constituem uma classe. Nota se, também, que os nomes dos elementos se iniciam, preferencialmente, por letra minúscula e, além disso, quando o elemento for um método, sugere se a utilização de um verbo no infinitivo. É interessante que o nome da classe seja precedido da letra maiúscula C (CPessoa ao invés de Pessoa). Além disso, um atributo tem um tipo e pode ter um valor default (valor inicial padrão) como, por exemplo, o atributo sexo (figura 3) que é do tipo char e tem valor default de 'M'. Para objetos, a UML determina que seja utilizado um retângulo com uma identificação, sublinhada, composta do nome do objeto, opcional, seguido de dois pontos e a indicação da classe ao qual o objeto pertence. Quando o nome do objeto não for indicado, entende se que se está fazendo referência a um objeto qualquer de determinada classe. Na figura 4 podem ser vistos três exemplos de objetos: estudante que é da classe CAluno, janentrada da classe CJanela e um objeto qualquer da classe CJanela. Fig. 4: Exemplos de objetos na UML. A definição das classes necessárias para a realização dos casos de uso (implementação das funcionalidades do sistema) envolve um processo de síntese (criação). Não existe uma técnica bem definida para o estabelecimento de classes e, por isso, cabe ao projetista, baseado em experiência e

3 criatividade, determinar as classes que vão compor o sistema. Sugere se que o levantamento das classes seja feito por caso de uso, sendo que as classes obtidas não são exclusivas de um determinado caso de uso, podendo ser compartilhadas por vários deles. Em sistemas de grande porte pode ser difícil fazer um levantamento completo das classes em uma primeira tentativa. Nestes casos, pode se definir grandes classes (classes de análise) que, futuramente, podem ser decompostas em classes menores e mais detalhadas (classes de projeto). Geralmente as classes podem ser criadas baseando se em três estereótipos (tipos): 1. Entidade: são classes que servem para armazenar dados e que representam entidades do mundo real, tais como, aluno, professor, disciplina, carro, pessoa; 2. Controle: são classes que controlam a execução dos processos (é o fluxo de execução do caso de uso) e, nesta tarefa, comandam outras classes; 3. Fronteira: são classes que realizam o interfaceamento com os atores e, para isso, elas contêm os protocolos necessários para estabelecer a comunicação do sistema com o ator. Existem algumas regras que auxiliam na definição das classes: definir uma classe do tipo fronteira para cada ator que participe do caso de uso; definir, pelo menos, uma classe do tipo controle para cada caso de uso; definir uma classe de entidade para cada grupo de dados. Para exemplificar o processo de definição de classes, pode se considerar, novamente, o caso de uso Cadastrar Aluno, da figura 1. Neste caso de uso, existiam dois atores e, portanto, são necessárias duas classes de fronteira, uma para o ator Secretária e outra para o ator SGDB. Estas classes poderse íam chamar CIntSecretária (classe de interface com a Secretária ) e CIntSGDB (classe de interface com o Sistema de Gerenciamento de Banco de Dados ), respectivamente (figura 5). Fig. 5: Classes de fronteira CIntSecretária e CIntSGDB Deve se observar o estereótipo <<fronteira>>, colocado acima do nome da classe, utilizado para identificar a classe como sendo de fronteira, ou seja, de interface com um respectivo ator. Para o caso de uso Cadastrar Aluno, será criada uma classe de controle chamada CCtrlCadastrarAluno, conforme mostra a figura 6. Nota se o estereótipo <<controle>> acima do nome da classe.

4 Fig. 6: Classe de controle do caso de uso "Cadastrar Aluno". Finalmente, percebe se a existência de apenas um grupo de dados referentes às informações do aluno que se quer cadastrar. Desta forma, será criada apenas uma classe de entidade, cujo nome é CAluno, para armazenar os dados referentes ao aluno (figura 7). Nota se o estereótipo <<entidade>> acima do nome da classe. Fig. 7: Classe de entidade que armazena os dados dos alunos. Duas classes podem se relacionar de quatro formas diferentes: herança, dependência, associação e agregação. Na herança, uma classe herda a estrutura e o comportamento de outra. A classe derivada (aquele que herda), também chamada de subclasse, é uma especialização da classe base, também conhecida como superclasse, classe mãe ou metaclasse. A herança é mais comum entre classes do tipo entidade: na figura 8, por exemplo, a classe de entidade CAluno herda da classe de entidade CPessoa. A herança estabelece um relacionamento do tipo é um, ou seja, o aluno é uma pessoa e serve para representar hierarquias entre classes, mostrando uma estrutura do mais geral para o mais específico. Nota se, na figura 8, que há um triângulo (não é uma seta!) apontando para a superclasse. Fig. 8: Exemplo de herança: "o aluno é uma pessoa". No relacionamento do tipo dependência, uma classe depende da existência de outra e, se houver uma mudança na última, provavelmente a primeira vai sofrer alterações. A figura 9 mostra um exemplo de relação de dependência onde uma classe CVeículoAlugado depende da classe CModeloVeículo.

5 Na dependência, a classe independente ( CModeloVeículo ) pode existir sozinha, não sendo afetada pela classe dependente ( CveículoAlugado ), mas a classe dependente é afetada diretamente pela classe independente. Fig. 9: Dependência de uma classe em relação à outra. No relacionamento de associação existe um canal de comunicação entre objetos de duas classes, ou seja, as associações são estabelecidas em função das necessidades de comunicação das duas classes. Na figura 10, existem duas associações chamadas comanda e registra : a classe de controle CCtrlEmitirDiário controla a classe de fronteira CIntSGDB através da associação comanda e a classe CIntSGBD grava dados na classe de entidade CDiárioClasse através da associação registra. Fig. 10: Exemplo de associações entre classes. Já na agregação, o relacionamento entre as classes é de pertinência (relacionamento tem um, partede ou todo parte ), significando que objetos de uma classe estão no interior de objetos de outra classe. Conforme mostra a figura 11, CPedido é um agregado de CItensPedido (o pedido é composto de itens de pedido). Fig. 11: Exemplo de agregação por valor (agregação por composição). O relacionamento de agregação possui duas formas de representação, com significados diferentes: a

6 agregação por valor, também chamada de agregação por composição, e a agregação por referência, também chamada de agregação por associação. Na agregação por valor, representada pelo losango preenchido (figura 11), o tempo de vida das partes é dependente do tempo de vida do todo, ou seja, as partes estão realmente dentro do todo: um item de pedido só existe, se o pedido existir, e vice versa. Por outro lado, na agregação por referência, representada pelo losango sem preenchimento (figura 12), o tempo de vida das partes não é mutuamente dependente do tempo de vida do todo. No exemplo da figura 12, o departamento pode existir mesmo sem a existência dos professores e vice versa. Fig. 12: Exemplo de agregação por referência (agregação por associação). Nas associações e agregações, muitas vezes é representada a multiplicidade, que especifica o número de instâncias de uma classe (objetos) participantes do relacionamento. A tabela 1 mostra os tipos de multiplicidade existentes, onde <literal> é qualquer inteiro maior ou igual a 1. Tabela 1: Exemplo de multiplicidade. Notação 0..1 zero ou uma instância. 1 somente uma instância. 0..* zero ou mais instâncias. Significado * default (o número mínimo e máximo de instâncias é ilimitado). 1..* uma ou mais instâncias. <literal>..* número exato ou mais instâncias. Exemplificando: na figura 11, para cada pedido, existem um ou mais itens de pedido e na figura 12, o raciocínio é o mesmo, ou seja, para cada departamento, existem 1 ou mais professores. Interface A interface é um tipo especial de classe que não pode ser instanciada, ou seja, não se pode criar um objeto a partir dela (é conhecida como classe virtual ou abstrata). Uma interface funciona como uma classe modelo, que poderá ser utilizada por outras classes que devem implementar as funcionalidades descritas pela primeira. A figura 13 mostra um exemplo do uso de uma interface: a interface é CContratoModelo que declara, mas não implementa, o método void emitirtexto (texto: String). A implementação da interface é feita pela classe de entidade CContratoVenda.

7 Fig. 13: Exemplo do uso de uma interface. A tabela 2 mostra a implementação em Java da interface apresentada na figura 13. Tabela 2: Exemplo de implementação de uma interface em Java. public interface CContratoModelo { public void emitirtexto (String texto); } public class CContratoVenda implements CContradoModelo { } public void emitirtexto (String texto) { } // implementação Bibliografia TONSIG, Sérgio Luiz. Engenharia de Software, Análise e Projeto de Sistemas. Editora Futura, São Paulo, Brasil: STADZISZ, Paulo Cézar. Projeto de Software Utilizando a UML. UTFPR, Departamento de Informárica: 2002.