Jump to content

Casos de Uso para um Banco Alimentar


XicoXperto
 Share

Recommended Posts

Boas pessoal

Dei casos de uso numa das cadeiras que tive, mas para ser sincero nem nunca me dei ao trabalho de estudar/perceber aquilo, agora que estou no projecto final necessito de fazer casos de uso para apresentar aos "clientes".

Andei a pesquisar na net, e vi muitas coisas, e baseado no que vi fiz o diagrama, gostava que o pessoal desse uma vista de olhos e fizesse criticas construtivas, se estou (ou não) no caminho certo, o que deveria melhorar, etc...

Obrigado pessoal, isto será de grande ajuda  😞

http://img59.imageshack.us/img59/2525/bausecases.th.jpg

_____

editado:

esqueci-me da imagem

Link to comment
Share on other sites

Viva.

Se eu fosse cliente e me mostrasses esse diagrama, a primeira coisa que conseguias era assustar-me! 😞

Se isso é o diagrama de casos de uso para um banco alimentar claramente que o primeiro passo não foi dado: identificação de actores.

O diagrama é enorme, parece ter muita informação redundante(por exemplo muitos Gestão->Adicionar->Remover->Editar);

Tem uma quantidade enorme de casos de uso mas, cada um contém apenas uma palavra;

Há poucos verbos que são muito úteis nos casos de uso porque permitem perceber rapidamente a utilidade de cada um;

Com tudo isto o diagrama torna-se confuso e difícil de perceber, eu diria que parece mais um diagrama de menus do que de casos de uso.

"Adicionar elementos à família" parece fazer parte de Gerir Famílias.

Adicionar, Remover e Editar eu acho que podia estar apenas na descrição dos casos de uso e não a encher o diagrama. Se há algo de especial na gestão ou listagem que seja necessário ter em conta, talvez não precise de estar detalhado logo no diagrama geral.

"Histórico" nos utilizadores é o quê? Consultar? E consultar o quê? "Consultar histórico de operações"?

"Ajuste" e "Mínimo de stock" nos Stocks também não percebo.

A Distribuição parece-me importante, e suponho que seja de produtos, mas não posso ter a certeza. O actor associado à distribuição é o Administrador. Ele faz a distribuição de produtos? Vai entregar produto a produto a casa das pessoas? As pessoas é que vão buscar a algum lado, ou melhor, levantar produto? Ou será que o administrador define apenas o que será entregue a quem? "Parâmetros de distribuição" não sei o que são, não sei se é possível ao administrador consultar os parâmetros, defini-los ou ambos. O "histórico" na distribuição é bastante vago...

A impressão não tem qualquer actor, e também é complicado perceber o que é para imprimir. No banco alimentar talvez seja útil a quem distribui os produtos imprimir uma lista de produtos a entregar a cada família ou pessoa, não sei. Vejo ali na impressão o número da segurança social, o nome e a idade; é relevante imprimir isso, ou melhor, é relevante apresentar isso nos diagramas de casos de uso? Se é importante imprimir o número de segurança social porque é que não existe um caso de uso: "Imprimir NISS da pessoa." ou "Imprimir NISS do representante da familia."

Há apenas 2 actores no sistema, parece-me pouco, ainda por cima o administrador é que faz tudo. Costumam existir vários tipos de voluntários, cada um com as suas responsabilidades e necessidades. No diagrama só existe um tipo de voluntário e este apenas acede ao histórico.

É verdade que não puseste aqui a lista de requisitos. Entregaram-te alguma lista de requisitos? Ou é suposto inventares os requisitos que dão origem a estes casos de uso?

Link to comment
Share on other sites

Estou a ver que afinal estou redondamente enganado em relação aos casos de uso  🙂

Se eu fosse cliente e me mostrasses esse diagrama, a primeira coisa que conseguias era assustar-me!

Concordo! XD

O diagrama é enorme, parece ter muita informação redundante(por exemplo muitos Gestão->Adicionar->Remover->Editar);

Pensei que era suposto ter todos os promenores

Vejo ali na impressão o número da segurança social, o nome e a idade; é relevante imprimir isso, ou melhor, é relevante apresentar isso nos diagramas de casos de uso?

Hmm, não sei...

"Histórico" nos utilizadores é o quê? Consultar? E consultar o quê? "Consultar histórico de operações"?

Sim. Então isto deve ser referenciado no propio balão? balão= "Consultar historico de operações"?

A impressão não tem qualquer actor

Esqueci-me completamente das ligações.

É verdade que não puseste aqui a lista de requisitos. Entregaram-te alguma lista de requisitos? Ou é suposto inventares os requisitos que dão origem a estes casos de uso?

Falaram me de ideias.

Isto é o seguinte, é suposto criar uma aplicação para efectuar a divisão do stock de alimentos pelas familias carenciadas, sendo que é necessário:

- ter em conta, digamos, "grau de pobresa", se existem idosos e/ou crianças, e ainda se a familia é numerosa

- a distribuição tem de ser calculada pela aplicação, no entanto, deve poder ser alterada manualmente caso desejem, e os seus parametros de distribuição devem ser configuráveis.

- poder adicionar "pessoas" com toda a informação pretendida e depois juntar as pessoas para criar a "familia" (isto é a minha abordagem, talvez exista uma maneira mais simples)

- existe necessidade de um historico de operações efectuadas pelos administradores (são estes que tratam de qualquer tipo de inserção de informação no sistema), sendo assim é necessário uma secção de gestão de utilizadores

- os alimentos (produtos) tem que, para alem de uma secção de gestão (do produto), uma parte para gestão apenas do stock

- a parte de impressão deve ter variadas listagens, sejam elas para o voluntario saber o que distribuir e a que familia, para os administradores, com as familias e seus elementos, produtos, e históricos do que as familias receberam.

Depois de ter reflectido sobre o que disseste, penso que a minha ideia de casos de uso está completamente errada  😛

No entanto, muito obrigado, se puderes dar me ideias, um trajecto, ou mesmo dizer me o que estudar era optimo!

Thanks 😞

Link to comment
Share on other sites

A ideia dos casos de uso é cada um deles identificar uma possível utilização do sistema por parte dos actores possibilitando-os de atingir um fim. Agora o grau de detalhe de cada um deles depende da visão que se pretende dar do sistema. Obviamente que casos de uso muito específicos vão distrair quem olha para o diagrama do que é mais importante. Casos de uso pouco específicos podem ser insuficientes para se perceber bem o que é pretendido. Pode-se jogar aqui com isto. Mas lembra-te que cada caso de uso pode ter uma descrição textual em que se detalhem alguns procedimentos que não sejam muito relevantes para a visão geral do sistema.

Olhando para o teu diagrama não é fácil identificar as funcionalidades que descreveste no teu último post na secção de ideias. O teu diagrama destruiu o que era importante com casos de uso demasiado específicos.

Dito isto posso sugerir por exemplo o seguinte.

é suposto criar uma aplicação para efectuar a divisão do stock de alimentos pelas familias carenciadas, sendo que é necessário:

- ter em conta, digamos, "grau de pobresa", se existem idosos e/ou crianças, e ainda se a familia é numerosa

Ou seja, o Administrador faz a divisão do stock de alimentos. Aqui está um caso de uso identificado: "Dividir Stock Alimentos". É necessário ter em conta o grau de pobreza: outro caso de uso "Calcular Grau Pobreza". Se a família é ou não numerosa e como se vai calcular o grau de pobreza pode constar na descrição textual do caso de uso "Calcular Grau Pobreza". Os dois caso de uso anteriores estão relacionados, dividir o stock inclui calcular o grau de pobreza. Para dividir o stock talvez seja importante também consultar o stock disponível. Se isso é automático, geralmente não se mete qualquer ligação a um actor, mas como também pode ser feito manualmente faz-se então uma ligação ao administrador. Na descrição pode-se dizer que é um caso de uso automático e qual a acção que o activa, porque no diagrama já fica óbvio que o Administrador o pode fazer.

- existe necessidade de um historico de operações efectuadas pelos administradores (são estes que tratam de qualquer tipo de inserção de informação no sistema), sendo assim é necessário uma secção de gestão de utilizadores

Existe então a possibilidade de registar operações. Neste caso até se pode considerar um sistema só para o registo de operações que pode ser visto como um sub-sistema do sistema do banco alimentar. Neste caso pode-se até criar um actor que nem é humano mas sim um módulo de registo de operações. A cada operação que seja para registar pode-se fazer uma ligação a este actor, que indica simplesmente que este módulo será usado.

No módulo de registo de operações pode-se indicar então que o módulo do banco alimentar pode registar operações, e que o administrador pode usar este sistema para consultar operações. Isto é só para mostrar que podes dividir um sistema em vários sempre que um fique demasiado complicado.

Não estou a dizer que faças isto, são só ideias para quando a coisa fique complicada. Fiz um pequeno diagrama só para teres ideia do que estou a dizer. Não sei se concordas mas olhando para ele é mais fácil perceber como é que o sistema é usado assim, do que quase estar a listar menus.

Use_Case_Model.jpg

Link to comment
Share on other sites

Hmm, acho que estou a entender, então não se quer saber o que se pode fazer em cada modulo do sistema, mas apresentar apenas o módulo em si e a interacção que este vai ter com o utilizador. É isso?

... pode constar na descrição textual ...

Falas várias vezes na descrição, eu pensava que os casos de uso eram apenas em diagramas, desconhecia que existe uma parte descritiva.

Obrigado, tendo em conta o que disseste vou reformular o diagrama e re-apresento depois xD

Link to comment
Share on other sites

Podes procurar na wikipedia caso de uso e encontras o seguinte:

Casos de uso são narrativas em texto, descrevendo a unidade funcional, e são amplamente utilizados para descobrir e registrar requisitos de sistemas.

Cada caso de uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto.

É importante notar que não descreve como o software deverá ser construído, mas sim como ele deverá se comportar quando estiver pronto.

Normalmente evitam o uso de termos técnicos, preferindo a linguagem do utilizador final, são empregados tanto por quem desenvolve o software quanto pelos utilizadores do software.

Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua actividade inequivocamente, para tal são usualmente utilizadas as formas verbais activas.

etc.etc.etc...

Link to comment
Share on other sites

e mais:

Há também outros formatos, ou templates para documentos de casos de uso. Normalmente, os casos de uso têm uma secção de "sumário" que pode ser escrita preliminarmente durante o projeto de software para capturar a essência do cenário antes do corpo principal estar completo. Uma secção de "precondições" pode ser usada para conter as condições iniciais que foram assumidas antes do cenário ter começado.

Link to comment
Share on other sites

Ola outra vez,

Vamos lá ver se desta entendi como funciona.

Estes são os requisitos (por alto, sem os promenores de cada):

- Gerir Familia

- Gerir Alimentos

- Gerir Utilizadores

- Efectuar Distribuíção

- Registar Operações

- Imprimir Listagens

- Consultar Listagens

- Consultar Historico Familias

- Consultar Historico Utilizadores

http://img577.imageshack.us/img577/6171/diagramadecasosdeutiliz.png

Uploaded with ImageShack.us

Sendo assim não há necessidade de especificar os tipos de listagem, utilizador, etc, certo?

Link to comment
Share on other sites

A minha primeira reacção foi a mesma, ui com este tamanho não dá 🙂

Até nem está muito mal dividido, mas concordo que fica grande demais e difícil de identificar as funcionalidades a que cada actor tem acesso, e acaba por fugir um pouco à finalidade do diagrama de Use Case.

Em relação a esta tua última versão:

- O tamanho está muito mais adequado.

- Não te esqueças que podes fazer um sub-diagrama para cada caso que tens nesse, isto é, no Caso gerir utilizadores podes gerar outro diagrama onde expões as diversas funcionalidades dentro desse, e indicas que actores têm acesso a quê.

Dessa forma evitas o crescimento do teu Diagrama principal, sem omitires informação relevante.

- Tens um conceito, pessoa que me parece um pouco ambíguo. Se esse conceito se refere apenas aos beneficiários do Banco Alimentar, talvez devesses trocar o nome (beneficiários ou utentes, embora o primeiro me pareça mais correcto). Não te esqueças que este tipo de Diagramas servem para expor o sistema a terceiros, muitas vezes sem conhecimentos de programação ou gestão de sistemas, pelo que os termos devem ser o mais claros possível. Se se refere a uma pessoa no sentido lato, então tanto os utilizadores como os administradores também são pessoas...

- O sistema  de registo de operações parece-me um pouco desnecessário. Primeiro, se estás a descrever um sistema, não faz sentido que o sistema seja utilizador dele próprio. Segundo, está a colocar o caso Consultar histórico Utilizadores dentro desse sistema mas não tens maneira de introduzir utilizadores nele...  Se os utilizadores são os mesmos do banco alimentar, então não deveria estar representado como um sistema à parte.

Parece-me mais correcto integrares os 2 casos no sistema do banco Alimentar, Sendo que o Consultar histórico é mais um caso normal, ao passo que o registo é um caso a ser incluido por outros casos (sem utilização directa de um actor, visto ser uma funcionalidade automatizada).

Link to comment
Share on other sites

Muito melhor o teu últimos diagrama, no entanto, parece que não percebeste bem quando dividi o sistema no meu exemplo em dois dai aquelas observações do Flinger quanto ao registo de operações.

O meu boneco foi com a ideia de:

- Mostrar que podes ter sub-sistemas de um sistema. No sub-sistema de registo de operações se reparares eu não meti nenhum caso de uso "Consultar Histórico de Utilizadores" mas sim "Consultar Operações". Esse sub-sistema permite registar e consultar operações, ele não conhece o banco alimentar muito menos utilizadores. É simplesmente uma coisa que regista operações sejam elas quais forem!

- Eu imaginei que seria bom indicar quais as operações a registar. Repara na ligação entre "Criar Pessoa" e "Módulo Registo Operações": indica que criar pessoa irá usar o módulo de registo de operações e ao olhar para ele facilmente se conclui que é para isso mesmo - registar operações. Esta era uma forma simples de representação. A alternativa de meter includes em todas as operações para o caso de uso "Registar Operação" pode gerar um grande diagrama...

No entanto isto só parece trazer confusão... mais vale esquecer a história dos sub-sistemas.

Boa-sorte

Link to comment
Share on other sites

Muito melhor o teu últimos diagrama, no entanto, parece que não percebeste bem quando dividi o sistema no meu exemplo em dois dai aquelas observações do Flinger quanto ao registo de operações.

Só depois de postar é que vi o teu esquema, e me apercebi que ele tinha confundido um pouco o conceito.

@XicoXperto

A divisão o 7_up faz é totalmente válida, não se pode é misturar os conceitos... São dois sistemas distintos, tanto que estão representados em Diagramas distintos. Nada impede que um sistema seja Actor do outro (como está no diagrama do 7). Um actor é uma entidade que interage com um sistema, seja um ser humano ou um outro sistema automatizado.

Vendo que não tinhas percebido bem essa divisão dei a hipótese de integrares tudo num só sistema. É outro caminho válido.

O mal deste tipo de exercício é que tendem a ser um bocado dependentes da interpretação de cada um, e não existe uma maneira "correcta" de os fazer. No fim tudo se resume a se o cliente percebeu exactamente como o sistema vai funcionar, e se concorda com isso.

Quanto ao que me perguntaste sobre os sub-diagramas,é algo assim:

Diagrama Banco Alimentar:

http://img15.imageshack.us/img15/8742/bancoalimentar.png

Diagrama Gerir Utilizadores:

http://img848.imageshack.us/img848/8399/gerirutilizadores.png

O programa que costumo usar, Visual Paradigm, permite-te criar através da IDE estes sub-diagramas, clicando no Caso que queres.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.