Análise OO. Análise. Antónia Lopes Desenvolvimento C. Objectos 09/10. Antónia Lopes

Transcrição

1 Análise OO 36 Análise Análise é a investigação do problema Análise de Requisitos é o termo que designa a investigação das necessidades e condições que o sistema, e o projecto em geral, têm de satisfazer. Envolve, nomeadamente:! compreender o contexto do sistema! identificar os requisitos funcionais a forma como o sistema deve responder às interacções com os seus utilizadores (as correctas e incorrectas) e a erros de software e hardware! identificar os requisitos não funcionais e proceder a negociação de requisitos conflituantes de diferentes stakeholders! identificar potenciais modificações! identificar funcionalidades de sistemas já existentes Documentos detalhados com requisitos fornecidos pelos clientes Entrevistas Workshops conjuntos Conhecimento do Domínio Real World Experience 37

2 Análise OO 38 Análise OO A análise e o desenho OO consideram o domínio do problema e a solução da perspectiva dos objectos. Análise OO: o centra-se na procura dos objectos/conceitos do domínio do problema o envolve o desenvolvimento de requisitos e especificações como modelos de objectos muito diferente das visões tradicionais centradas nos dados ou funcionais 39

3 Outras Abordagens Exemplo: Jackson Structured Programming (70 s) Estrutura dos programas inspirada na estrutura dos dados (streams de input e output) e usa apenas iteração, sequencialização e selecção 40 Produtos da Análise OO Modelo de Casos de Uso: Capturar requisitos funcionais o capturam a forma como os utilizadores ou outros subsistemas externos usam o sistema Modelo do Domínio: Compreender o contexto do sistema o identifica e dá nome aos conceitos e às entidades do contexto do sistema o identifica e dá nome às relações entre os objectos do domínio o define um glossário de potenciais classes 41

4 Modelo de Casos de Uso: Casos de Uso Este modelo inclui descrições textuais de Casos de Uso (Use Cases) que! São histórias sobre a utilização do sistema de forma a alcançar um determinado objectivo (business goal)! Oferecem uma forma sistemática e intuitiva de capturar os requisitos funcionais! Complementam documentos que descrevem os requisitos na forma The system shall do que são mais dirigidos para teste/verificação! Focam-se no valor acrescentado que o sistema tem para um actor No contexto dos casos de uso, um actor é um parceiro externo que interage com o sistema. Exemplos: uma classe de utilizadores; um papel que os utilizadores podem tomar; sistemas externos 42 Modelo de Casos de Uso: Casos de Uso Para que não servem os casos de uso:! Para descrever o funcionamento interno do sistema! Para descrever como o sistema está implementado O sistema é, neste contexto, visto como uma caixa preta!! Apesar de serem especialmente usados no contexto da análise OO, a natureza dos casos de uso não é centrada em objectos! Os casos de uso admitem vários formatos:! breves! informais! elaborados 43

5 Sistema POS para Posto de Venda Caso de Uso Processar Venda: uso de formas verbais breve O Cliente chega à caixa com as coisas que quer comprar. O empregado da caixa usa o POS para registar cada uma dessas coisas. O sistema apresenta a conta total e os detalhes sobre cada uma das compras. O cliente indica a forma como quer pagar, que é validada pelo sistema. O sistema actualiza os stocks. O cliente recebe um recibo do sistema e parte com as suas compras. 44 Modelo de Casos de Uso: Casos de Uso A análise de requisitos deve focar-se quer nas situações normais quer nas situações em que há erros. Uma abordagem para estudar ambos os tipos de situações é considerar instâncias de casos de uso chamadas cenários.! Um cenário é uma descrição passo a passo de uma interacção de um ou mais actores com o sistema, assumindo que o sistema funciona correctamente. Consiste em pares de pedido-resposta.! Deve começar-se por considerar cenários onde o utilizador não comete erros cenário principal/sucesso e depois devem-se considerar os cenários alternativos que cobrem as possíveis situações de erro ou situações problemáticas. 45

6 Sistema POS para Posto de Venda Caso de Uso Processar Devoluções: informal Cenário Principal. O Cliente chega à caixa com as coisas que quer devolver. O empregado da caixa usa o POS para registar a devolução de cada uma dessas coisas. Cenários Alternativos. Se a compra foi feita com cartão de crédito e a transacção de reembolso não é possível, informar o cliente e proceder ao reembolso em dinheiro. Se a compra devolvida não é encontrada pelo sistema, informar o empregado da caixa e sugerir-lhe que insira o código manualmente. 46 Modelo de Casos de Uso: Casos de Uso Além da definição de cenários, os casos de uso podem ser refinados e enriquecidos com outros tipos de detalhes, nomeadamente:! Actor principal, cujos objectivos se concretizam por utilização dos serviços do sistema em causa! Stakeholders e seus interesses: quem são os envolvidos no caso de uso e quais os seus interesses! Pré e pos-condições: o que deve ser verdadeiro no início, e portanto se assume, e o que deve ser verdadeiro no fim do caso de uso (e que valha a pena registar e transmitir ao leitor)! Requisitos especiais relativamente a requisitos não funcionais 47

7 Sistema POS para Posto de Venda Caso de Uso Processar Venda elaborado Actor Principal Empregado da Caixa Stakeholders Empregado da Caixa: facilite o processo de pagamento com fiabilidade Cliente: Serviço rápido com pouco esforço. Quer provas de compra que permitam devoluções. Empresa: Fisco: Serviços de Pagamento: Pre-Condições O Empregado da Caixa foi previamente identificado e autenticado. Pos-Condições A compra é guardada. O respectivo imposto é calculado. Contabilidade e inventário são actualizados. Comissões são registadas. Recibo é gerado. Autorizações de pagamento aprovadas no processo são registadas. Cenário Principal 1. O Cliente chega à caixa com coisas que quer comprar. 2. O Empregado da Caixa dá início à nova venda. 3. O Empregado da Caixa dá entrada ao código de um produto. 4. O POS regista item e apresenta a sua descrição, preço e total. O preço é calculado a partir de um conjunto de regras. O empregado repete 3-4 até indicar que terminou. 5. O POS apresenta o total com o imposto respectivo. 6. O Empregado diz ao cliente o total e pede o pagamento. 7. O Cliente paga e o Empregado processa o pagamento. 8. O POS regista a venda como completa e envia-a juntamente com a informação do pagamento para o sistema de contabilidade e de gestão de stocks. 9. O POS apresenta recibo. 48 Sistema POS para Posto de Venda Cenários Alternativos/Extensões *a. Em qualquer altura o sistema falha: 1. O Empregado da Caixa recomeça o sistema e pede a recuperação do estado anterior 2. O Sistema reconstrói estado anterior. 3a. Identificador inválido: 1. O Sistema assinala-o e rejeita a entrada. 3-6b. Cliente diz ao empregado para cancelar a venda: 1. O Empregado cancela a venda. 4a. O preço indicado para a compra não é o pretendido 1. O Empregado insere preço novo 2. O sistema apresenta novo preço. Requisitos Especiais Interface em écran grande e texto visível a 1m Lista de Pontos de Variação (dados ou tecnológicos) 3a. Identificador de item é inserido através de leitor óptico ou teclado. Frequência Pode ser quase contínua 49

8 Modelo de Casos de Uso: Diagramas de Casos de Uso! Os Diagramas de Caso de Uso são uma notação que o UML oferece para representar graficamente os vários casos de uso existentes, focado nos actores que envolvem.! Fornecem sucinta e visualmente o contexto de uso dos sistemas. Porque mostram a fronteira do sistema e o que fica fora dele, são também usados como diagramas de contexto Use case 1 Use case 2 50 Diagrama de Casos de Uso do POS 51