Exemplo de Modelagem Orientada a Objetos

Transcrição

1 Curso Curso de Análise, Design e Implementação de Sistemas OO Exemplo de Modelagem Orientada a Objetos Finalidade deste documento: Exemplificar a modelagem, utilizando-se a UML (Unified Modeling Language Linguagem de Modelagem Unificada), de uma ação de negócio coerente e completa (Caso de Uso) prevista para ser implementada em determinado sistema. Instrutor: Hélio Engholm Jr Importância da modelagem utilizando-se UML A finalidade da UML é de documentar, especificar, permitir a visualização e, através de ferramentas apropriadas, gerar estrutura do código para implementação do sistema (C++, Java,...) agilizando o processo de desenvolvimento, diminuindo custos. SISTEMA e-restaurante Objetivo Este exemplo visa demonstrar os detalhes relacionados à modelagem Orientada a Objetos e documentação relacionada, utilizando-se UML, do Caso de Uso referente à Emissão de em Restaurante, para que o mesmo possa ser implementado no sistema OO e-restaurante. Introdução A equipe relacionada ao desenvolvimento do sistema destinado a automação dos processos relativos a restaurantes, identificou uma série de Casos de Uso para o mesmo. Abaixo apresentamos a modelagem UML do Caso de Uso Emissão de conta em restaurante. Escopo: Emissão de em Restaurante A partir dos requisitos do usuário/cliente, identificam-se os casos de uso do sistema. Neste exemplo, iremos analisar o caso de uso referente à emissão de conta em um restaurante. Diagrama de Casos de uso Atores Para este caso de uso, foi identificado um único Ator, o Funcionário do Caixa. Abaixo temos o diagrama do caso de uso em estudo. -Solicita -Emite Sistema Emissão de conta do restaurante funcionariodocaixa

2 Diagrama de Atividades 17/07/2013 Após gerar o Diagrama de Casos de Uso, pode-se utilizar o Diagrama de Atividades para descrever com detalhes cada um dos Casos de Uso identificados. Para tanto, necessitamos de maiores detalhes sobre o processo de emissão de conta. Detalhes relacionados à emissão de conta A fim de emitir a conta referente a uma mesa, precisamos: Informação de qual mesa se deseja encerrar a conta; Quais itens foram consumidos na mesa e qual o valor de cada um; Realizar processamento e emitir a conta; Registrar que o consumo da respectiva mesa está encerrado. A partir destas informações, podemos produzir o Diagrama de Atividades relacionado a este caso de uso, abaixo. Usuário Partition1 Sistema Seleciona opção de emitir conta Apresenta interface de solicitação de conta solicitando número da mesa Informa número da mesa Sim Número da mesa válido? Não Fornece mensagem de inválida Verifica itens registrados como consumidos Realiza totalização e emite a conta Registra consumo da mesa como encerrado

3 Diagrama de Classes 17/07/2013 Outro diagrama extremamente importante na Modelagem Orientada a Objetos é o Diagrama de Classes. Inicialmente, na fase de Análise, são gerados diagramas de classes que identificam os tipos de objetos candidatos do sistema e algumas propriedades/métodos, ficando para a fase do Design o detalhamento completo das classes. A análise dos quesitos do sistema, através ou não dos diagramas de Caso de Uso e de Atividades, leva-nos a identificar os objetos envolvidos e necessários para o desenvolvimento da aplicação que contemplam a ações de negócio. Na modelagem do sistema, devemos então considerar para determinação dos objetos do mesmo: Quais objetos do mundo real (do negócio) devemos representar no sistema; Devemos guardar dados de quais objetos no sistema; Como os objetos identificados se relacionam. Para o caso deste exemplo, analisando os dados e objetos envolvidos na emissão de uma conta, podemos sugerir as seguintes classes candidatas: Classe Item de cardápio Finalidade Armazenar informações sobre a mesa Armazenar o preço dos itens de cardápio disponíveis Armazenar os itens consumidos Emitir a conta Algumas das classes candidatas identificadas na fase de Análise, podem deixar de existir na fase de design, enquanto outras não percebidas anteriormente podem aparecer. Deste modo, inicialmente na fase de análise, podemos ter diagramas de classe que apenas identificam as classes candidatas do sistema, como o diagrama apresentado abaixo, sem mostrar todos os detalhes das mesmas. Na fase de Design devemos ter diagramas de classe detalhados a serem entregues às equipes de desenvolvimento. Deste modo devemos realizar uma análise mais detalhada nesta fase, para que possamos identificar as propriedades e métodos das classes, viabilizando a correta implementação do sistema. Continuando a análise do sistema, percebemos que na modelagem anterior acabou não sendo explicitado o armazenamento da quantidade de itens solicitados de cada Item de Cardápio, pelos clientes da mesa. Outra discussão seria a respeito da obtenção e armazenamento da data/hora de chegada e saída dos clientes nas mesas. Caso esta informação fosse digitada pelo usuário, seria importante termos uma classe DataHora com métodos de validação de data/hora digitadas pelos usuários do sistema. Foi decidido, com anuência do cliente, que estas informações poderiam ser inseridas automaticamente pelo sistema nos momentos de abertura e fechamento da conta relativa

4 às mesas. Deste modo, foi decidido que estas informações serão armazenadas diretamente na classe. Considerando-se este aspecto, teremos a nova proposta de modelagem abaixo. Classe Item da conta Item de cardápio Finalidade Armazenar informações sobre a mesa Armazenar data/hora de chegada e saída de clientes nas mesas Armazenar a quantidade do respectivo Item de cardápio Armazenar o preço dos itens de cardápio disponíveis Armazenar os itens consumidos Emitir a conta Deste modo, passamos a ter o seguinte diagrama simplificado de classes: ItemDa Fase de Design do Sistema Analisando o Caso de Uso em questão, mais os dados que necessitamos para emitir uma conta, podemos gerar uma tabela como a apresentada abaixo que nos auxilia na determinação de todas as propriedades e métodos das classes do sistema sendo modelado. Ações/Classes responsáveis Ação no estado pagando conta Obter consumo da conta Obter itens consumidos e quantidades Fornecer preço dos itens Emitir conta Recuperar e armazenar data/hora Classe responsável + Item da conte Item do cardápio

5 Abaixo temos o Diagrama de Classes mais detalhado, considerando as classes identificadas nas fases de Análise e Design. Observe que neste diagrama de classes, são especificadas todas as propriedades e métodos das classes, se são do tipo privado (-) ou público (+) e o tipo de cada propriedade (int, double,...). -numero : int -horachegada : Date -horasaida : Date -conta : +abre() +fecha() +sethorachegada() +gethorachegada() +sethorasaida() +gethorasaida() +set() +get() 1 1 -flagaberta : bool -mesa : -collectionitens : ItemDa +abre() +fecha() +adiciona() +retira() +emitefatura() +gettotal() +setflagaberta() +getflagaberta() 1 ItemDa - : -quantidade : double +setquantidade() +getquantidade() 1 1 -descricao : String -preco : double -flagdisponivel : bool +getdadosdobd() +setflagdisponivel() +getflagdisponivel() Conforme podemos observar no diagrama acima, uma mesa pode estar associada a apenas uma conta em determinado intervalo de tempo, que por sua vez pode estar associada a n itens de conta/cardápio com suas respectivas quantidades. Devido ao fato da modelagem ser um processo evolutivo, análise posterior do Caso de Uso mostrou que, as horas de chegada e saída não fazem parte do objeto e que o objeto pode ser substituído pelo objeto Consumo, este sim possuindo horários de chegada e saída (equivalentes a horários de início e fim de consumo). Caso o sistema seja modelado desta maneira, pode-se obter dados da conta do cliente e imprimir a mesma, através de métodos do objeto Consumo, não sendo efetivamente necessário definir e implementar o objeto. Durante conversa entre integrantes do projeto, foi estabelecido que seria mais apropriado então, utilizar o termo Consumo no lugar de. Estes fatos nos levam à tabela abaixo: Classe Finalidade Armazenar informações sobre a mesa, relacionando-a a determinado consumo Item do consumo Armazenar quantidades consumidas de Itens de cardápio Item de cardápio Armazenar o preço dos itens de cardápio disponíveis Consumo Armazenar os itens consumidos Emitir a conta Armazenar data/hora de chegada e saída de clientes nas mesas Baseado nestas novas decisões de modelagem, temos o seguinte Diagrama de Classes simplificado: Consumo ItemDeConsumo

6 Como diagrama detalhado de Classes, temos: Consumo -numero : int -consumo : Consumo +iniciaconsumo() +encerraconsumo() +setconsumo() +getconsumo() 1 1 -flagaberta : bool -mesa : -collectionitens : ItemDeConsumo -dthorainicioconsumo : Date -dthorafimconsumo : Date +iniciaconsumo() +encerraconsumo() +adiciona() +retira() +emitefatura() +gettotal() -setflagaberta() +getflagaberta() +getdthorainicioconsumo() +getdthorafimconsumo() -Possui -Compõe ItemDeConsumo : -quantidade : double +setquantidade() +getquantidade() 1 1 -descricao : String -preco : double -flagdisponivel : bool +getdadosdobd() +setflagdisponivel() +getflagdisponivel() Diagrama de Seqüência Diagramas de Seqüência mostram as interações seqüenciais entre objetos e pode ser utilizado para o entendimento do fluxo de controle da aplicação. Abaixo, temos o Diagrama de Seqüência do caso de uso sendo modelado neste exemplo. Consumo ItemDeConsumo Sistema encerraconsumo() encerraconsumo() getvaloritemda() getpreco() funcionariodocaixa getdadosdobd() getdatahora() sethorasaida() gettotal() setflagaberta() emitefatura()

7 Comentários finais Foram apresentados neste documento, quatro diagramas UML necessários para uma boa documentação/especificação de uma funcionalidade (Caso de Uso) a ser implementada pelo sistema exemplo (e-restaurante), sendo eles: Casos de Uso, Atividades, Classes e Seqüência. Existem outros diagramas UML (Objetos, Estados, Colaboração, Implantação e de Componentes) que podem ser utilizados no Ciclo de Desenvolvimento de Sistemas, cada um com sua finalidade específica. Devido ao trabalho envolvido na documentação de sistemas, alguns diagramas não são efetivamente confeccionados.