A essência do diagrama de caso de uso

Question

Para uma atribuição de escola, temos que fazer um diagrama Usecase. Mas a documentação que temos, não é muito prolongado. Ele apenas descreve o que componentes de um usecase consiste em, e um exemplo.
Temos que fazer uma usecase sobre um sistema de biblioteca. Temos encontrado 11 casos de uso, mas não vou incomodá-lo com todas elas.

IIRC, um usecase descreve um uso típico de um sistema, certo? Mas o que as coisas pertencem em um diagrama de caso de uso, e como eles se conectam juntos?

O que temos agora são quatro atores (membro, empregado, gerente e contador). Os que têm mais problemas com são membro e funcionário.
O funcionário é aquele que está usando o sistema. Será que um membro ainda pertence aqui como ator?

Alguns casos de uso que temos:

• Membro adere à biblioteca.
• Membros altera seus registros.
• Membro empresta um livro.
• Peças membros da biblioteca (unsubscribes).
• livros Membros um artigo.
• Membro retorna livro.
• Membro paga (uma parte) das taxas e multas.

Os casos de uso tornam-se no diagrama. Mas deve haver mais casos de uso, como, empregado entra membernumber, empregado entra booknumber e assim por diante (usos?).

Alguém pode galpão (?) Uma luz sobre isso?

Editar: Como são seqüências de ação descrita? Já me disseram que você pode ver uma associação usa como uma chamada de método para algum tipo de rotina que se repete? Isto está certo? E como é estendida usado?

Answer 1

IIRC, um usecase descreve um típico o uso de um sistema, certo? Mas o que fina [g] S integram num diagrama usecase, e Como eles se conectam juntos?

Seus diagramas de Caso de Uso (sim, um projeto típico terá mais de um) provavelmente deve ser os diagramas mais simples em sua suíte UML. Eles devem mapear Atores / Roles que você definiu diretamente para os casos de uso de seu sistema. Na verdade, eles devem se concentrar principalmente em um único ator e só incluir outros atores se eles devem participar de um determinado caso de uso.

Aqui está um exemplo que eu saí do Google:

Amostra Use Case Diagram http://java.sun.com /mailers/newsletters/fundamentals/img/usecase.png

Observe a simplicidade. Um ator, um sistema, 5 Casos de Uso. Nada mais.

Além disso, como @Eric P sugeriu e minha imagem de exemplo implica, você deve título seus Casos de uso com um "[verbo] [Object]" estrutura; ou seja, "membro empresta um livro" torna-se "pedir emprestado um livro". O assunto em falta de seu caso de uso frase ( "membro") está codificado no seu diagrama de caso de uso como como um ator com uma associação para o caso de uso.

O funcionário é aquele que está usando o sistema. Será que um ainda membro pertence aqui como ator?

Receio que a resposta para isso é subjetivo. Alguns vão dizer não, isso porque o sistema só está sendo usado pelo empregado, em seguida, o empregado é o único ator. Eu, pessoalmente, discordo.

Por quê? Por um lado, Casos de Uso são parte dos requisitos fase de coleta. Eles estão lá para ajudá-lo a organizar a eventual funcionalidade do sistema. Mas negar o ator Member simplesmente porque sua crença atual é que a tecnologia não será utilizada pelo Member é limitar-se nessa fase.

E se o seu eventual sistema de é automatizado, o que significa que o Member vai para um terminal de check-out um livro ela mesma? Se você fez uma suposição durante levantamento de requisitos, você pode perder funcionalidade importante.

Editar: Como são seqüências de ação descrito? Já me disseram que você pode ver uma associação usos como uma chamada de método a algum tipo de rotina que se repete? Isto está certo? E como é estendido usado?

Casos de Uso Diagramas são de alto nível . Eles devem mostrar a sua funcionalidade de alto nível (na forma de cada Caso de Uso) e os atores que os utilizam e nada mais. Não desarrume o seu uso Diagramas de Casos com estende e inclui; aqueles devem ser raras e só caso especial. O maior erro rookie você pode fazer (e acreditem, eu fiz isso!) É tentar modularizar seu código dentro do seu diagrama de caso de uso. Sim, eu sei, é a primeira coisa que qualquer pena programador seu sal tenta fazer, mas diagramas de Caso de Uso não são o lugar para ele.

Em relação seqüências de ação: em um conjunto típico de diagramas UML, cada um Caso de Uso tem associado a ele um ou mais Diagramas de Atividade . Estes são aproximadamente análogo a um fluxograma e servir como uma representação gráfica da estrutura típica narrativa Caso de Uso que a maioria dos livros de Engenharia de Software incentivar.

De qualquer forma, espero que isso ajude. Se você tiver outras dúvidas, não hesite em perguntar!

Answer 2

eu fui ensinado que everyones aproximar de diagrama de caso de uso são um pouco diferentes, então eu não sei se isso se aplica a você, mas atores são geralmente aqueles que têm contato direto com o sistema. Então, um membro não seria um ator menos que ele verifica o seu próprio cartão de biblioteca ou algo assim, porque ele teria que passar pelo empregado.

Os casos de uso deve cobrir tudo, mas não ser muito detalhado. Então o funcionário iria verificar a adesão, se ele não existir, vá para criar casos de uso de membros, verificação mais para taxas pendentes. Se a associação está em boa posição, livro de digitalização, etc.

Answer 3

Parece que você tem uma compreensão lamacenta do que casos de uso são. Aqui estão alguns recursos para você ir na direção certa:

• Casos de Uso - Uma Introdução
• caso de uso UML Diagramas

Answer 4

O ator é a pessoa que usa o sistema, por isso, se o empregado é o único a usar o sistema, então eles devem ser o ator. Você também pode ter múltiplos atores possíveis, se por exemplo uma função está disponível tanto para os funcionários e gerentes.

Assim, você pode querer reformular seus casos de uso para algo como "Adicionar novo membro", "conta de membro Alter", etc.

Quanto a nível de detalhe, gostaria de incluir o máximo de detalhes possível, sem ficar "técnico". sugestões de Brandon não são muito bons.