Princípios de modelagem de Domínio e Projeto(design) de Software Parte 1

Princípios de modelagem de Domínio e Projeto(design) de Software Parte 1 Prof. Gustavo Willam Pereira ENG10082 Programação II Créditos: Prof. Clayton Vieira Fraga Filho

Apesar de todas as vantagens que a OO pode trazer ao desenvolvimento de software, um problema fundamental ainda persiste: identificar corretamente e completamente objetos (classes), atributos e operações.

Projeto Um projeto de software é uma descrição da estrutura de software a ser implementada, dos dados que são partes do sistema, das interfaces entre os componentes do sistema e, algumas vezes, dos algoritmos utilizados.

Modelos de Domínio: na análise! É o modelo mais importante em análise OO Ilustra importantes conceitos em um domínio; Pode agir como fonte de inspiração para projetar alguns objetos; O modelo de domínio é a representação visual de classes conceituais, ou objetos do mundo real em um domínio. Também são chamados de modelos conceituais.

Modelos de Domínio class modelodominio Modelo de Domínio - data Venda 1 1..* LinhadeVenda - quantidade Requisitos e Casos de Uso Conceitos, associações Realizar venda Importar produtos Emitir Nota Fiscal Inspiram Nomes de Classes de projeto class proj eto Projeto Venda - data: Date 1 +itens 1..* LinhadeVenda - quantidade: double + calculatotal() : void

Modelos de Domínio Regra: Evite um esforço grande de modelagem pensando na abordagem para fazer um modelo completo ou correto ele nunca será. Esforços excessivos de modelagem levam à paralisia de análise com pequeno ou nenhum retorno.

Modelos de Domínio Descreve: Objetos do domínio ou classes conceituais; Associações entre classes conceituais; Atributos de classes conceituais;.

Técnicas de Identificação de Classes Uma das tarefas mais importantes e difíceis no desenvolvimento de software OO é a identificação das classes necessárias e suficientes para compor o sistema. Independentemente da técnica utilizada, esta tarefa se subdivide em duas: Classes candidatas (entidades que podem vir a se tornar classes) são identificadas; São aplicados alguns princípios para eliminar classes candidatas que são desnecessárias.

Técnicas de Identificação de Classes Várias técnicas (de uso não exclusivo) são usadas para identificar classes: 1. Categorias de Conceitos 2. Análise Textual de Abbott (Abbott Textual Analysis) 3. Análise de Casos de Uso Categorização BCE 4. Padrões de Análise (Analisys Patterns) 5. Identificação Dirigida a Responsabilidades 9

Categorias de Conceitos Estratégia: usar uma lista de conceitos comuns. Conceitos concretos. Por ex., edifícios, carros, salas de aula, etc. Papéis desempenhados por seres humanos. Por exemplo, professores, alunos, empregados, clientes, etc. Eventos, ou seja, ocorrências em uma data e em uma hora particulares. Por exemplo, reuniões, pedidos, aulas, etc. Lugares: áreas reservadas para pessoas ou coisas. Por exemplo: escritórios, filiais, locais de pouso, salas de aula, etc. Organizações: coleções de pessoas ou de recursos. Por exemplo: departamentos, projetos, campanhas, turmas, etc. Conceitos abstratos: princípios ou idéias não tangíveis. Por exemplo: reservas, vendas, inscrições, etc. 10

Análise Textual de Abbott Estratégia: identificar termos da narrativa de casos de uso e documento de requisitos que podem sugerir classes, atributos, operações. São utilizadas diversas fontes de informação sobre o sistema: documento de requisitos, modelos do negócio, glossários, conhecimento sobre o domínio, etc. Para cada documento, os nomes (substantivos e adjetivos) que aparecem no mesmo são destacados (são também consideradas locuções equivalentes a substantivos.) Após isso, os sinônimos são removidos (permanecem os nomes mais significativos para o domínio do negócio em questão). 11

Análise Textual de Abbott Cada termo remanescente se encaixa em uma das situações a seguir: O termo se torna uma classe (ou seja, são classes candidatas); O termo se torna um atributo; O termo não tem relevância alguma com a SSOO (solução de software orientada a objetos). Técnica análoga foi sugerida pelo mesmo autor para a identificação de operações de uma classe e de associações entre classes. Para isso, sugere que se destaquem os verbos no texto o Verbos com sentido de ação (e.g., calcular, confirmar, cancelar, comprar, fechar, estimar, depositar, sacar, etc.) operações em potencial. A classe à que a operação pertencerá é aquela que ocupa o valor de sujeito na frase do verbo em questão. Outras informações relevantes podem ser encontradas no complemento da frase. o Verbos com sentido de ter agregações ou composições em potencial. o Verbos com sentido de ser generalizações em potencial. 12 o Demais verbos associações em potencial

Análise Textual de Abbott

Análise Textual de Abbott Vantagem: simplicidade da sua aplicação. Desvantagem: seu resultado (as classes candidatas identificadas) depende de os documentos utilizados como fonte serem completos. Dependendo do estilo que foi utilizado para escrever os documentos, essa técnica pode levar à identificação de diversas classes candidatas que não gerarão classes reais, ou o que é mais grave, pode omitir uma classe crucial para o sistema. A análise do texto de um documento pode não deixar explícita uma classe importante para o sistema. Em linguagem natural, as variações lingüísticas e as formas de expressar uma mesma idéia são bastante numerosas. 14

Análise Textual de Abbott: Exemplo Desenvolva a modelagem de uma sistema para controle de processos jurídicos, através do diagrama de classes, de acordo com as seguintes informações: O escritório possui um cadastro de diversas pessoas que participam de processos como clientes ou com partes contrárias. Uma pessoa pode ser tanto física como jurídica e pode ter sido cliente do escritório em uma determinada época e parte contrária em outra. Existe uma grande quantidade de processos cadastrados, alguns concluídos outros em andamento. Cada processo deve armazenar informações como o número do processo, o tribunal e a vara em que ele tramita, o cliente ao qual o processo se refere, a parte contrária envolvida, a data de abertura do processo e sua possível data de conclusão.

Análise Textual de Abbott: Exemplo Escritório de Advocacia (cont.) Um processo deve tramitar em um determinado tribunal e em uma determinada vara, no entanto um tribunal pode julgar muitos processos e uma vara pode possuir diversos processos tramitando nela. Um tribunal pode possuir diversas varas, porem um processo julgado por um determinado tribunal só pode tramitar em uma das varas pertencentes ao mesmo. O advogado pode achar necessário emitir relatórios de todos os processos em andamento em um determinado tribunal e tramitando em uma determinada vara.

Análise Textual de Abbott: Exemplo Escritório de Advocacia (cont.) Cada processo possui no mínimo uma audiência e pode possuir diversas. Cada audiência é relativa a um determinado processo. Para fins de histórico do processo, cada audiência deve ser registrada, devendo-se cadastrar a data e a recomendação do tribunal relativa a cada uma das audiências do processo. Um processo pode gerar custas (despesas com xerox, viagens, etc.). Cada custa deve ser armazenada de forma a ser cobrada da parte contrária caso o processo seja ganho. O registro de uma custa deve conter a data em que ela foi gerada, sua descrição e o valor gasto.

Análise Textual de Abbott: Exemplo 2 Desenvolva a modelagem de uma sistema para controle de vendas de passagens aéreas por uma empresa aérea, através do diagrama de classes, de acordo com as seguintes informações: Uma empresa aérea realiza venda de passagens a diversos clientes. No entanto uma passagem se refere a um cliente específico. A empresa mantém um cadastro de todos os clientes que já foram passageiros de algum vôo. Para cada cliente deve-se armazenar informações como: nome, telefone, endereço, CPF, cidade e estado. Um vôo pode ter muitos passageiros, no entanto cada passagem se refere exclusivamente a um vôo específico. Ao adquirir uma passagem o cliente pode realizar seu pagamento através de dinheiro ou cartão de crédito, podendo ser parcelada.

Análise Textual de Abbott: Exemplo 2 Venda de Passagens Aereas (cont.) Um vôo pode fazer escalas em diversos aeroportos, ou seja, pode ter diversos destinos e um aeroporto pode ser destino de muitos vôos. Os vôos são identificados através de um Número, contendo também a data. A empresa mantém um cadastro de todos os aeroportos para onde oferece vôos. Para cada escala de um vôo deve-se armazenar o horário de saída e o horário de chegada. Um aeroporto está localizado em uma cidade específica, mas uma cidade pode possuir muitos aeroportos. Um aeroporto pode ser a origem ou o destino de muitas escalas, no entanto, um determinado aeroporto só pode ser a origem ou o destino de uma determinada escala, nunca os dois ao mesmo tempo. Ao adquirir uma passagem em um vôo, ela pode compreender apenas à um trecho do vôo (escala), ou à vários trechos. O preço total da passagem será calculada de acordo com o valor de cada trecho compreendido.

Análise de Casos de Uso Também chamada de identificação dirigida por casos de uso Técnica preconizada pelo Processo Unificado. Modelos de casos de uso utilizado como ponto de partida. Premissa: um caso de uso corresponde a um comportamento específico do SSOO esse comportamento só pode ser produzido por objetos que compõem o sistema. Ou seja: a realização de um caso de uso é responsabilidade de um conjunto de objetos que devem colaborar para produzir o resultado daquele caso de uso. Com base nisso, aplica-se a técnica de análise dos casos de uso para identificar as classes necessárias à produção do comportamento que está documentado na descrição do caso de uso. 20

Casos de Uso Níveis de detalhamento de um Caso de Uso Descrição Alto Nível; Descrição Casual; Descrição Expandida.

Casos de Uso Descrição Alto Nível Consiste em um parágrafo que explica sucintamente o objetivo e o funcionamento do caso de uso. Não é objetivo da descrição alto nível o detalhamento de todas as possíveis exceções do processo. Caso de Uso: Emprestar Fitas Um cliente solicita a locação de algumas fitas. Após se identificar e escolher as fitas, ele pode levá-las para casa, ciente do prazo de devolução e do valor a ser pago.

Casos de Uso Descrição Casual Indica algumas exceções importantes, mas não necessariamente todas. Apenas a versão expandida da fase de elaboração é que vai tentar esgotar todas as possibilidades. Caso de Uso: Emprestar Fitas Um cliente solicita a locação de algumas fitas. Após se identificar e se não houver problemas no seu cadastro e se as fitas não estiverem reservadas para outro cliente, ele pode levá-las para casa, ciente do prazo de devolução e do valor a ser pago.

Casos de Uso Expansão dos Casos de Uso A expansão consiste basicamente de: Identificar a seqüência de passos principal (fluxo principal) Identificar as seqüências alternativas e exceções, ou seja, os fluxos específicos para tratamento de exceções.

Casos de Uso Exemplo: Caso de Uso Emprestar Fitas Fluxo Principal 1.O cliente chega ao balcão com as fitas que deseja locar. 2.O cliente informa o seu nome e entrega as fitas ao funcionário. 3.O funcionário registra o nome do cliente e inicia a locação. 4.O funcionário registra cada uma das fitas. 5.O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação. 6.O cliente deixa a locadora com as fitas. Exceções O cliente não possui cadastro 1.O cliente deve informar seus dados para cadastro. 2.O funcionário registra o cadastro 3.Retorna ao Fluxo Principal no passo 3. O cliente possui pendências (débito) 1.O cliente paga seu débito. 2.O funcionário registra a quitação do débito, eliminando assim a pendência 3.Retorna ao fluxo principal no passo 3.

Casos de Uso Fluxo Principal 1. Duas pessoas podem descrever casos de uso com uma sequência de passos diferente. 2. Todo caso de uso possui passos obrigatórios e esses passos envolvem informações que passam dos atores para o sistema e vice-versa. 3. Passos como Perguntar o nome do cliente são opcionais.

Casos de Uso Fluxo Principal Como o caso de uso é uma descrição da interação entre os atores e o sistema, deve-se evitar descrever passos internos do sistema, por exemplo O sistema armazena a informação no banco de dados. System

Casos de Uso Fluxo Principal: passos obrigatórios Todos os passos que indicam troca de informações entre os atores e o sistema. Por que esses passos são obrigatórios? Caso de Uso: Reservar um filme (errado) 1.O cliente entre em contato com o funcionário da videolocadora. 2.O cliente informa seu nome. 3.O cliente solicita uma reserva. 4.O funcionário confirma a reserva.

Casos de Uso Fluxo Principal: passos obrigatórios Como seria um dialógo entre um cliente e o funcionário? Reservar um filme (errado) Cliente:Boa tarde! Funcionário: Boa tarde! Em que posso serví-lo? Cliente: Meu nome é João e eu gostaria de reservar um filme. Funcionário: Pois não, senhor. Acabo de efetuar a reserva. Cliente: Grato! Exemplo: No fluxo principal da locação de fitas deve conter obrigatoriamente os passos que indicam os momentos nos quais o funcionário registra o nome do cliente e a identificação das fitas.

Casos de Uso Fluxo Principal: passos obrigatórios O Caso de Uso correto seria: Caso de Uso: Reservar um filme 1.O cliente entre em contato com o funcionário da videolocadora 2.O cliente informa seu nome. 3.O cliente solicita uma reserva, informando o nome do filme. 4.O funcionário confirma a reserva, informando o prazo de validade. 1. A informação obrigatória precisa estar presente no Caso de Uso, pois será necessário estabelecer quais serão os métodos que devem ser implementados pelo sistema.

Casos de Uso Fluxo Principal: passos obrigatórios Os passos obrigatórios em um caso de uso pode ser de dois tipos: a)eventos de Sistema: são passos indicativos de que alguma informação é passada dos atores para o sistema. b)respostas Caso de Uso: do Reservar sistema: um São filme passos indicativos de que alguma informação é passada do sistema para os atores. 1.O cliente entre em contato com o funcionário da videolocadora 2.[EV] O cliente informa seu nome. 3.[EV] O cliente solicita uma reserva, informando o nome do filme. 4.[RS] O funcionário confirma a reserva, informando o prazo de validade.

Casos de Uso Fluxo Principal: passos complementares Corresponde normalmente à comunicação entre os atores (sem envolvimento do sistema), exemplo O cliente chega ao balcão com as fitas que deseja locar. Descrição de ações ou atitudes dos atores, por exemplo O cliente chega ao balcão com as fitas que deseja locar, ou o cliente vai embora com as fitas. Perguntas ou interações cujo objetivo não é passar informação, mas indicar a mudança de estado, como por exemplo: O sistema informa que a reserva foi feita com êxito.

Casos de Uso Fluxo Principal: passos complementares Os passos complementares não são fundamentais na versão essencial do Caso de Uso, mas podem ser importantes no caso de uso de projeto (Real), exemplo: O cliente seleciona a opção reserva no menu de opções. O exemplo não representa uma operação do sistema, pois o cliente não passou nenhuma informação ao sistema. A ação consiste apenas em uma mudança de estado, que possivelmente corresponderá a uma navegação na interface.

Casos de Uso Fluxo Principal: passos não recomendados Caso de Uso: Emprestar fitas (errado) 1.O cliente chega ao balcão com as fitas que deseja emprestar. 2.O cliente informe o nome. 3.O funcionário registra o nome do cliente. 4.O sistema verifica se o cliente tem cadastro e se o cliente não está suspenso por não-pagamento de empréstimos anteriores. 5.O funcionário registra cada uma das fitas. 6.O sistema verifica no banco de dados o registro das fitas e marca cada uma como emprestada. Posteriormente, o sistema adiciona cada fita ao empréstimo corrente e soma o valor das fitas ao total do empréstimo. 7.O funcionário encerra o empréstimo. 8.O cliente vai embora com as fitas.

Casos de Uso Tratamento de exceções Fluxo Principal Fluxo alternativo Fluxo de exceção 35

Casos de Uso Tratamento de exceções Após elaborar o fluxo principal é preciso descrever o que poderia dar errado em cada um dos passos descritos. Uma exceção não é necessariamente um evento que ocorra raramente, mas um evento capaz de impedir o prosseguimento do caso de uso se não for devidamente tratado. Exemplo: No pagamento de uma conta pode ser usado cheque, cartão ou dinheiro. Mesmo que 1% das contas sejam recebidas em dinheiro e 99% em cheque ou cartão, isso não torna o pagamento em dinheiro uma exceção, mas uma opção pouco freqüente. O fato do cliente não ter meios para pagar a conta é uma exceção, pois impede que o processo seja concluído. 36

Tratamento de exceções Exceções ocorrem normalmente nos passos que correspondem aos eventos dos sistema [EV], ou seja quando a informação é passada do ator para o sistema. Nestes casos o sistema normalmente realiza algumas validações, exemplo do caso de uso Emprestar fitas: OK OK FE1 OK OK OK Casos de Uso FLUXO PRINCIPAL 1. O cliente chega ao balcão com as fitas que deseja locar. 2. O cliente informa o seu nome e entrega as fitas ao funcionário. 3. [EV] O funcionário registra o nome do cliente e inicia a locação. 4. [EV] O funcionário registra cada uma das fitas. 5. O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação. FE1. O cliente não possui cadastro 1. O cliente deve informar seus dados p/ cadastro. 2. [EV] O funcionário registra o cadastro 3. Retorna ao Fluxo Principal no passo 3. Neste momento o sistema realiza uma consulta (que não é representada no caso de uso) para verificar se o cliente está cadastrado: O cliente é cadastrado? NÃO!!! 37

Casos de Uso Tratamento de exceções Outras exceções possíveis para o caso de uso Emprestar fitas O cliente tem crédito? O número máximo de locações foi excedido? 38

Casos de Uso Tratamento de exceções Um tratamento de exceção tem pelo menos 4 elementos: Identificador: Corresponde ao número da linha do fluxo principal ou do fluxo alternativo onde a exceção ocorre. Exemplo: Fluxo Principal 1.O cliente chega ao balcão com as fitas que deseja locar. 2.O cliente informa o seu nome e entrega as fitas ao funcionário. 3.[EV] O funcionário registra o nome do cliente e inicia a locação. 4.[EV] O funcionário registra cada uma das fitas. 5.O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação. 6.O cliente deixa a locadora com as fitas. 3a. O cliente não possui cadastro 1.O cliente deve informar seus dados para cadastro. 2.[EV] O funcionário registra o cadastro 3.Retorna ao Fluxo Principal no passo 3. 39

Casos de Uso Tratamento de exceções Fluxo Principal 1.O cliente chega ao balcão com as fitas que deseja locar. 2.O cliente informa o seu nome e entrega as fitas ao funcionário. 3.[EV] O funcionário registra o nome do cliente e inicia a locação. [FE1] 4.[EV] O funcionário registra cada uma das fitas. 5.O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação. 6.O cliente deixa a locadora com as fitas. FE1: O cliente não possui cadastro 1.O cliente deve informar seus dados para cadastro. 2.[EV] O funcionário registra o cadastro 3.Retorna ao Fluxo Principal no passo 3. 40

Casos de Uso Tratamento de exceções Exceção: Uma frase que explica qual exceção ocorreu, pois em uma mesma linha podem ocorrer diferentes tipos de exceções. Exemplo: Ações corretivas: uma seqüência de ações que devem ser executadas para corrigir a exceção. Finalização: última linha do fluxo que indica se e como o caso de uso retorna ao fluxo principal depois das ações corretivas. Fluxo Principal 1.O cliente chega ao balcão com as fitas que deseja locar. 2.O cliente informa o seu nome e entrega as fitas ao funcionário. 3.[EV] O funcionário registra o nome do cliente e inicia a locação. [FE1] [FE2] 4.[EV] O funcionário registra cada uma das fitas. 5.O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação. 6.O cliente deixa a locadora com as fitas. FE1: O cliente não possui cadastro 1.O cliente deve deve informar informar seus seus dados dados para cadastro. para cadastro. funcionário registra o cadastro 2.[EV] O funcionário registra o cadastro 3.Retorna ao Fluxo Principal - passo 3. 3.Retorna ao Fluxo Principal - passo 3. FE2: O cliente possui pendências (débito) cliente paga seu débito. 1.O cliente paga seu débito. 2.[EV] funcionário registra a quitação do débito, eliminando assim a 2.[EV] pendência O funcionário registra a quitação do débito, eliminando assim a pendência 3.Retorna ao fluxo principal no passo 3. 3.Retorna ao fluxo principal no passo 3. 41

Casos de Uso: Devolver Fitas Variantes do fluxo principal (Fluxos alternativos) Admite-se que o Fluxo Principal seja uma seqüência não ramificadas de passos, mas algumas vezes é necessário representar fluxos alternativos. 1. O cliente entrega as fitas que deseja devolver FLUXO PRINCIPAL 2. [EV] O funcionário identifica cada uma das fitas. 3. [EV] O funcionário indica que não há mais fitas para devolver. 4. [RS] O sistema informa o valor total a ser pago. 5. O cliente realiza o pagamento 6. O funcionário conclui a devolução. Dinheiro? Cheque? Cartão? 42

Casos de Uso Exemplo: Caso de Uso: Devolver fitas Fluxo Principal 1.O cliente entrega as fitas que deseja devolver 2.O funcionário identifica cada uma das fitas. 3.O funcionário indica que não há mais fitas para devolver. 4.O sistema informa o valor total a ser pago. 5.O cliente realiza o pagamento: 1. Dinheiro - Ver variante 5.1 2. Cheque - Ver variante 5.2 3. Cartão - Ver variante 5.3 6.O funcionário conclui a devolução. 5.1: Dinheiro: 5.1.1. O cliente entrega a quantia em dinheiro 5.1.2. O funcionário registra a quantia 5.1.3. O sistema informa o troco. 5.1.4. O funcionário entrega o troco ao cliente. 5.2: Cheque: 5.2.1. O cliente entrega o cheque 5.2.2. O funcionário solicita a presença do gerente. 5.2.3. O gerente dá o visto no cheque. 5.3: Cartão: 5.3.1. O cliente entrega o cartão de crédito. 5.3.2. O funcionário envia a informação sobre o cartão para o serviço de autorização, com o valor e o nome da loja. 5.3.3. O serviço de autorização envia o código 5.3.4. O cliente confirma a autorização. 43

Casos de Uso Variantes do fluxo principal (Fluxos alternativos) Caso de Uso: Devolver fitas Fluxo Principal 1.O cliente entrega as fitas que deseja devolver 2.O funcionário identifica cada uma das fitas. 3.O funcionário indica que não há mais fitas para devolver. 4.O sistema informa o valor total a ser pago. 5.O cliente realiza o pagamento [FA1] [FA2] [FA3] 6.O funcionário conclui a devolução. [FA1] : Pagamento com Dinheiro: 5.1.1. O cliente entrega a quantia em dinheiro 5.1.2. O funcionário registra a quantia 5.1.3. O sistema informa o troco. 5.1.4. O funcionário entrega o troco ao cliente. [FA2] : Pagamento com Cheque: 5.2.1. O cliente entrega o cheque 5.2.2. O funcionário solicita a presença do gerente. 5.2.3. O gerente dá o visto no cheque. [FA3] : Pagamento com Cartão: 5.3.1. O cliente entrega o cartão de crédito. 5.3.2. O funcionário envia a informação sobre o cartão para o serviço de autorização, com o valor e o nome da loja. 5.3.3. O serviço de autorização envia o código 5.3.4. O cliente confirma a autorização. 44

Análise de Casos de Uso Procedimento de aplicação: O modelador estuda a descrição textual de cada caso de uso para identificar classes candidatas. Para cada caso de uso, seu texto (fluxos principal, alternativos e de exceção, pós-condições e pré-condições, etc.) é analisado. Na análise de certo caso de uso, o modelador tenta identificar classes que possam fornecer o comportamento do sistema (de cada caso de uso). Na medida em que os casos de uso são analisados um a um, as classes do SSOO são identificadas. Quando todos os casos de uso tiverem sido analisados, todas as classes (ou pelo menos a grande maioria delas) terão sido identificadas. Na aplicação deste procedimento, pode-se utilizar a 45 categorização BCE.

Análise de Casos de Uso (continuação) Caso de Uso Essencial Cadastrar um cliente Fluxo principal 1. O cliente chega ao balcão para fazer seu cadastro 2. O atendente informe o procedimento e solicita o nome do cliente e um comprovante de renda (com valor total da renda atualizado) 3. [EV] O atendente registrar o nome e a renda do cliente 4. [RS] O sistema exibe a classificação do cliente e o percentual de desconto autorizado. 5. O atendente informa ao cliente que seu registro foi feito com sucesso. Fluxos de exceção FE1 - Cliente não lembra sua renda 1. O cliente não tem um comprovante de renda 2. O atendente solicita que seja providenciado 3. O cliente se dispõe a providenciar 4. O registro é suspenso. Fluxos alternativos Não há

Análise de Casos de Uso Categorização BCE Na categorização BCE, os objetos são agrupados de acordo com o tipo de responsabilidade a eles atribuída. Objetos de entidade: usualmente objetos do domínio do problema Objetos de fronteira: atores interagem com esses objetos Objetos de controle: atuam como intermediários entre objetos de fronteira e de entidade, definindo o comportamento de um caso de uso específico Categorização proposta por Ivar Jacobson em 1992 Possui correspondência com o framework model-viewcontroller (MVC) 47

Análise de Casos de Uso Categorização BCE Estereótipos na UML: «boundary», «entity», «control» 48

Análise de Casos de Uso Categorização BCE Objetos de Entidade Representam conceitos encontrados no domínio do problema (domínio do negócio) Servem como repositórios para informações e regras de negócio manipuladas pelo sistema. Características: Normalmente armazenam informações persistentes. Várias instâncias da mesma entidade existem no sistema. Participam de vários casos de uso e têm ciclo de vida longo. Exemplo: Um objeto Pedido participa dos casos de uso Realizar Pedido e Atualizar Estoque. Este objeto pode existir por diversos anos ou mesmo tanto quanto o próprio sistema. 49

Análise de Casos de Uso Categorização BCE Objetos de Entidade Responsabilidades típicas: 1. Informar valores de seus atributos a objetos requisitantes 2. Realizar cálculos ou impor restrições relativas a regras do negócio, normalmente com a colaboração de objetos entidade associados 3. Criar e destruir objetos-parte (para o caso de objetos-todo) 50

Análise de Casos de Uso Categorização BCE Objetos de Fronteira Realizam a comunicação do sistema com os atores traduzem os eventos gerados por um ator em eventos relevantes ao sistema eventos de sistema apresentam os resultados de uma interação dos objetos em algo que pode ser facilmente compreendido pelo ator Existem para que o sistema se comunique com o mundo exterior. Por conseqüência, são altamente dependentes do ambiente. 51

Análise de Casos de Uso Categorização BCE Objetos de Fronteira Dois tipos principais de objetos de fronteira: Os que se comunicam com o usuário (atores humanos): relatórios, páginas web, interfaces gráfica desktop, etc. Os que se comunicam com atores não-humanos: protocolos de comunicação. Sistemas externos Dispositivos atrelados ao sistema 52

Análise de Casos de Uso Categorização BCE Objetos de Fronteira Responsabilidades típicas Notificar aos demais objetos os eventos gerados pelo ambiente do sistema Notificar aos atores o resultado de interações entre os demais objetos Nomes de classes de Fronteira não devem conter verbos ou sugerir ações Devem lembrar qual o canal de comunicação com o mundo externo que a classe representa. Ex.:FormularioMatricula, SistemaFaturamento, LeitoraCartoes 53

Análise de Casos de Uso Categorização BCE Objetos de Controle São a ponte de comunicação entre objetos de fronteira e objetos de entidade. Responsáveis por controlar a lógica de execução correspondente a um caso de uso. Decidem o que o sistema deve fazer quando um evento de sistema ocorre. Eles realizam o controle do processamento Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um caso de uso. Traduzem eventos de sistema em operações que devem ser realizadas pelos demais objetos. 54

Análise de Casos de Uso Categorização BCE Objetos de Controle Responsabilidades típicas: Realizar monitoramentos, a fim de responder a eventos do sistema (gerados por objetos de fronteira) Coordenar a realização de um caso de uso através do envio de mensagens a objetos de fronteira e objetos de entidade. Assegurar que as regras do negócio estão sendo seguidas corretamente. 55

Análise de Casos de Uso Categorização BCE Objetos de Controle Responsabilidades típicas: Coordenar a criação e remoção de associações entre objetos de entidade (embora isso possa ser feito pelos objetos de entidade). Criar e destruir objetos de entidade. Manter valores acumulados ou derivados durante a realização de um caso de uso. Manter o estado da realização do caso de uso. 56

Análise de Casos de Uso Importância da Categorização BCE A categorização BCE parte do princípio de que cada objeto em um SSOO é especialista em realizar um de três tipos de tarefa: comunicar com atores (fronteira), manter as informações (entidade) ou coordenar a realização de um caso de uso (controle). A categorização BCE é uma receita de bolo para identificar objetos participantes da realização de um caso de uso. A importância dessa categorização está relacionada à capacidade de adaptação a eventuais mudanças. Se cada objeto tem atribuições específicas dentro do sistema, mudanças podem ser menos complexas e mais localizadas. Uma modificação em uma parte do sistema tem menos possibilidades de resultar em mudanças em outras partes. 57