DIAGRAMAS UML:
CASO DE USO
E DE CLASSES
Este texto-base aborda os seguintes temas. Clique para navegar.
DIAGRAMAS UML:
CASO DE USO
E DE CLASSES
Este texto-base aborda os seguintes temas. Clique para navegar.
Modelagem Orientada a Objetos e Diagramas UMLVocê já sabe que, dentre os tipos de modelagens, a Orientação a Objetos é um modelo eficaz e conveniente para as necessidades em que devemos modelar o mundo real para uma necessidade, como por exemplo, um sistema acadêmico. Para facilitar a comunicação entre os diversos integrantes de uma equipe de desenvolvimento de sistemas – e dessa equipe com clientes e demais envolvidos no processo – na orientação a objetos utilizam-se esquemas gráficos específicos, com o objetivo de permitir a visualização, especificação, construção e documentação do software que será construído.
Assim como arquitetos utilizam plantas e maquetes para representar as casas que ainda existirão, desenvolvedores de sistemas utilizam representações gráficas específicas quando trabalham com projetos orientados a objetos: o Diagrama de Caso de Uso e o Diagrama de Classes. Essas representações são parte da UML (Unified Modeling Language - Linguagem Unificada de Modelagem), um padrão usado para o desenvolvimento de modelos de software orientados a objeto. Ela permite que toda a equipe de desenvolvimento tenha um vocabulário comum, e assim trabalhe em melhor sintonia.
A modelagem orientada a objetos foi criada para simular o mundo real dentro do computador e, para isso, são utilizados objetos que se relacionam, se comunicam e guardam dentro deles os dados e as operações. Mas, antes de se iniciar a codificação de um programa, é importante planejar o que se pretende fazer. Isso garante maior confiabilidade do produto a ser desenvolvido, e pode ser feito de uma forma simples e dinâmica utilizando-se, por exemplo, o esboço de um desenho, que ajudará a documentar e modelar o sistema a ser desenvolvido. Agora, conheça o diagrama de caso de uso e o diagrama de classes.
O Diagrama de Caso de Uso é bem simples e prático de ser aplicado pela equipe no desenvolvimento. Consiste em representar a forma como as funcionalidades se relacionam a partir dos atores envolvidos e tem como foco elencar as necessidades do usuário e as funcionalidades do sistema. A notação usada pelo Diagrama de Caso de Uso consiste em três elementos: ator, caso de uso e a comunicação entre eles.
Observe a situação a seguir, um diagrama de caso de uso feito para um sistema de agendamento de consulta médica. Nele, o paciente é o ator que se comunica com a funcionalidade marcar consulta. No diagrama, podemos notar que o boneco representa o ator (Paciente) e a elipse representa o caso de uso, ou seja, a funcionalidade do sistema ou requisito funcional, cujo nome é Marcar Consulta. Para finalizar a construção do diagrama, temos a comunicação entre o ator e o caso de uso, sendo assim podemos interpretar que o Paciente se comunica com Marcar Consulta.
Os Requisitos Funcionais (RF) descrevem explicitamente as funcionalidades e os serviços do sistema, obtidos sob o ponto de vista do usuário. No exemplo, requisitos funcionais poderiam ser: Cadastro de Médicos, Cadastro de Pacientes, Cadastro de Consultas Médicas, Cancelamento de Consultas etc.
O Diagrama de Classes é o mais usado por desenvolvedores e representa a base de qualquer projeto Orientado a Objeto porque descreve detalhadamente o que deve ser construído no sistema a ser modelado. Este diagrama é composto pelas classes e relacionamentos entre elas. Na unidade anterior, você viu que objetos são representados por classes e conheceu outros conceitos como associação, generalização e agregação, que serão fundamentais para a criação deste diagrama.
Observe o diagrama a seguir, também do sistema de consultas médicas. Veja que a classe Paciente está relacionada (associada) com a classe Consulta, pois sabemos que o paciente faz consultas médicas. Para informar essa associação usamos uma linha e um verbo ou um substantivo para representá-la.
Análise Orientada a Objetos
Na etapa inicial do projeto, em que você fará o levantamento e análise de requisitos, será preciso identificar quais classes deverão ser implementadas e quais serão seus principais atributos e métodos para que os requisitos sejam satisfeitos. Para representar isso, geralmente são utilizados os Diagramas de Casos de Uso e o Diagrama de Classe da UML, possibilitando a visualização, especificação, construção e documentação de artefatos de um sistema complexo de software orientado a objetos.
A UML foi criada pelos norte-americanos Grady Booch e James Rumbaugh e pelo suíço Ivar Jacobson que, em 1995, lançaram a UML 0.8, unificando o Método de Booch, o método OOSE (Object-Oriented Software Engineering), de Jacobson e o método de OMT (Object Modeling Technique), de Rumbaughtos.
Criadores da UML: GradyBooch, Ivar Jacobson, James Rumbaugh. Fonteimagens:
http://www.fabiobmed.com.br/booch-rumbaugh-jacobson-e-a-uml-unified-modeling-language/
Por oferecer ferramentas que podem ser utilizadas em todas as fases do desenvolvimento de software, a UML acabou se tornando a linguagem padrão para representação no desenvolvimento de software orientado a objetos. Existem 13 diagramas na UML 2.0, divididos em quatro grupos de acordo com o tipo de análise que os modelos gerados por sua utilização possibilitam: diagramas estruturais, diagramas comportamentais, diagramas de interação e diagramas de implementação. Veja a seguir:
Você pode conhecer os diagramas da UML com maiores detalhes acessando esta apresentação de slides do Prof. Eduardo Figueiredo, da UFMG.
Agora, assista ao vídeo “UML é importante para você?” do Canal DevMedia:
Diagrama de Caso de UsoOs diagramas de caso de uso são uma excelente técnica para auxiliar no levantamento dos requisitos de um sistema e são compostos por um conjunto de casos de uso, atores e seus relacionamentos. Cada caso de uso é um dos requisitos funcionais do sistema a ser desenvovido.
Você pode criar diagramas de caso de uso para avaliar alguma situação que não ficou muito clara durante as entrevistas, para definir como será a relação dos diversos agentes de software no sistema, ou ainda para verificar quais funcionalidades este deverá implementar. Com este diagrama, o que você fará é mapear os requisitos funcionais do sistema e sua análise, além de identificar as relações que tais requisitos terão com os demais componentes, internos ou externos ao sistema.
Os principais componentes do diagrama de caso de uso são o cenário, os atores, os casos de uso e os relacionamentos.
Um Ator representa uma entidade externa ao sistema que interage de alguma forma com um caso de uso. Normalmente, um ator é uma pessoa, um dispositivo de hardware ou um outro sistema. Ele é representado por um ícone em formato de pessoa ou por um boneco palito.
Você se lembra do conceito de herança, que conheceu a unidade anterior? Assim como há o conceito de herança, existe a Generalização de Atores:
Conhecendo um exemplo
Para melhor entender a notação de um Diagrama de Caso de Uso, veja o exemplo a seguir:
O Cliente chega ao caixa eletrônico de um banco, efetua um saque em sua conta corrente, emite o extrato da conta e faz um pagamento de um boleto. O sistema bancário controla as operações de saque, de emissão de extrato e do pagamento do boleto. O administrador do sistema alimenta o caixa com as cédulas monetárias (dinheiro).
Com esse cenário simples pode-se começar a criar o diagrama.
Agora, deve-se construir o diagrama de caso de uso:
Como se pode observar, o Diagrama de Caso de Uso é composto por desenhos simples que descrevem as funcionalidades do sistema e as interações dos atores com elas. Existem ainda os conceitos de <>Include e <>Extend, que podem melhorar ainda mais as especificações das ações no diagrama.Vamos conhecê-los?
<>Include
Em algumas situações, toda vez que um caso de uso A ocorrer, um outro caso de uso B deverá ocorrer simultaneamente. Por exemplo, toda vez que um cliente for efetuar um saque num caixa eletrônico, o sistema bancário precisa autenticar esse cliente (verificar se ele de fato é a pessoa responsável pela conta). Essa condição é representada no diagrama de caso de uso por meio do <<include>> e é chamada relação de inclusão.
Uma relação de Inclusão de um caso de uso A com um caso de uso B indica que uma instância do caso de uso A deve incluir o comportamento especificado para o caso de uso B. Observe:
Ou seja, quando o caso de uso A (Efetuar saque) “inclui” o caso de uso B (Autenticar cliente), significa que sempre que o caso de uso A for executado, o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído. Agora, observe o diagrama do exemplo citado:
Neste caso, sempre que o cliente selecionar a opção de efetuar um saque, o sistema deverá solicitar a autenticação do cliente, como procedimento de segurança.
<>Extend
Em outras situações, quando um caso de uso A ocorrer, outros casos podem ou não ser desencadeados. Por exemplo, imagine que um cliente vá ao banco encerrar sua conta bancária. Caso o saldo seja positivo, ele precisará retirar o valor existente na conta para poder encerrá-la. Caso o saldo seja negativo, ele deverá depositar o valor referente à divida para poder fechar a conta. Esse tipo de relação é chamada de relação de extensão.
Uma relação de extensão de um caso de uso A com um caso de uso B indica que uma instância do caso de uso B pode incluir o comportamento especificado para o caso de uso A. Observe:
Ou seja, quando o caso de uso B (Sacar e Depositar) estende o caso de uso A (Encerrar conta), significa que quando o caso de uso A for executado o caso de uso B poderá (poderá = talvez não ocorra) ser executado também. A direção do relacionamento é do caso de uso extensor (aqui, o caso de uso B) para o caso de uso estendido (aqui, o caso de uso A).
Neste exemplo, quando o cliente for ao banco encerrar a sua conta, caso ela esteja com saldo positivo, é preciso que o cliente faça um saque em sua conta para depois encerrar. Da mesma forma, caso a conta estiver com saldo negativo, é preciso ele fazer um depósito deixando o saldo zerado para depois encerrar a sua conta. Sendo assim, pode ser que um desses casos aconteçam antes do cliente encerrar a conta. Entendeu?
Na Comunicação com os clientes, o diagrama de caso de uso é muito importante para auxiliar na definição dos requisitos por não exigir conhecimentos técnicos e para delimitar o contexto do sistema.
Praticando o diagrama de caso de uso
Agora que você já compreendeu como se constrói um diagrama de caso de uso, pratique pensando em um sistema de biblioteca escolar com o seguinte contexto:
Faça o rascunho do seu diagrama de caso de uso e confira se você acertou.
Diagrama de ClassesO Diagrama de Classes é o mais utilizado da UML. Ele fornece uma visão estática do modelo a ser criado. Como as classes são um dos componentes mais importantes da orientação a objetos, esse diagrama deve constar em todo projeto orientado a objetos. Preste muita atenção ao criá-lo, pois será a base da sua solução.
Nesse tipo de diagrama os principais componentes são as classes, interfaces e relacionamentos.
Identificar uma classe não é tarefa das mais simples, mas o caminho é procurar itens que têm as mesmas informações e comportamentos. Saiba que nem sempre uma classe tem atributos e métodos, ela pode ter apenas métodos ou apenas atributos.
Como criar um diagrama de classes?
O caminho é analisar o cenário do projeto com base no diagrama de caso de uso e fazer uma lista do que você identificou como classes. Acrescente os atores que, geralmente, são também classes de seu sistema. Analise as possíveis classes, tente identificar atributos para elas e, se possível, alguma funcionalidade.
Coloque as classes em um diagrama e comece a analisar as relações entre elas, de acordo com os tipos de relacionamentos que esse diagrama propõe. Veja:
É um relacionamento estrutural que especifica objetos de uma classe conectados a objetos de outra classe. A partir de uma associação, conectando duas classes, você é capaz de navegar do objeto de uma classe até o objeto de outra classe e vice-versa (BOOCH, RUMBAUGH e JACOBSON,2005).
A Associação é representada por uma linha interligando as duas classes, podendo definir papéis das classes relacionadas, assim como a multiplicidade de sua associação, além de ter um nome. É usada em conjunto com a multiplicidade para expressar o relacionamento entre as classes, pode ser um intervalo de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e assim por diante. No caso de ter a representação de somente um (1), este não é obrigatório ser descrito no diagrama de classes.
Veja a seguir, a notação de representação da multiplicidade no relacionamento entre as classes:
Multiplicidade
1 somente um
* muitos (zero ou mais)
0..* muitos (zero ou mais)
0..1 opcional (zero ou um)
1..* maior ou igual a um
M..N sequência específica
Veja este exemplo de associação e multiplicidade:
É um tipo especial de associação que tenta demonstrar que as informações de um objeto-todo precisam ser complementadas pelas informações contidas em um (ou mais) objetos-parte.
Exemplos de agregação:
É uma variação da agregação e também representa uma relação todo-parte. No entanto, na composição o objeto-pai (todo) é responsável por criar e destruir suas partes. Em uma composição, um mesmo objeto-parte não pode se associar a mais de um objeto-pai.
Exemplos de Composição:
Têm como objetivo identificar classes-mãe, denominadas de gerais, e classes-filha chamadas de especializadas. São chamados de relacionamentos “é um tipo de”.
Podemos verificar na imagem a seguir, que a classe Pessoa possui os atributos nome e CPF e pode executar os métodos andar e falar. Já a classe Funcionário, por herdar os atributos e métodos da classe Pessoa, possui nome, CPF, salário e nroCarteiraProfissional, podendo executar os métodos andar, falar e trabalhar. Dizemos que a classe Pessoa é a superclasse da classe Funcionario, que é sua subclasse, ou que Pessoa é a classe pai de Funcionario e que Funcionario é classe filha de Pessoa.
Como o nome sugere, indica um grau de dependência entre uma classe e outra. Uma dependência difere de uma associação porque a conexão entre as classes é temporária. É representada por uma seta tracejada entre duas classes.
Exemplos de Dependência:
O quadro a seguir sintetiza a representação dos tipos de relacionamentos da UML:
Agora, observe esse diagrama de classes e seus relacionamentos1. Perceba os conceitos que você estudou:
O diagrama de classe acima modela um pedido de um cliente para um catálogo de itens. A classe central é o Pedido. Associada a ela estão: o Cliente fazendo o Pagamento. Um Pagamento pode ser de três tipos: Dinheiro, Cheque ou Crédito. O pedido contém DetalhesPedido, cada um associado a um Item.
Praticando o diagrama de classe
Agora, vamos retornar ao exemplo do sistema de biblioteca escolar, situação para a qual você já desenvolveu um diagrama de caso de uso anteriormente. A partir dele, exercite a criação do diagrama de classes.
Faça o rascunho do seu diagrama de classes e confira se você acertou.
Recapitulando...Para sintetizar e retomar os conceitos estudados neste material, assista à videoaula do professor.
1 Exemplo de Diagrama de Classe (adaptado). Fonte: Tecnolog Local, 2009. Disponível em http://tecnologialocal.blogspot.com/2009/
Acessado em 05.abr.2019.
