UML - Diagrama de Sequência - Cadastrar Produtos

Seu diagrama aparenta estar OK, mas o diagrama de sequência não precisa ter todos os detalhes. Os diagramas de interação servem para alocar responsabilidades aos participantes, não são uma boa ferramenta para modelar o comportamento interno da classe.

Só estou achando estranho você conseguir obter uma entidade logo a partir do seu construtor. Geralmente essa pergunta é feita para um repository e não para a própria entidade. OK?

Se vc postar o caso de uso seria bom para complementar a minha opinião.

Rodrigoy,

eu tenho difuculdade com OO, pois trabalho com Delphi e estou mudando de tecnologia, no caso nós estamos querendo fazer o sistema em OO pelas vantagens tem.

penso assim:

1- tem o ator
2- tenho a interface que será implementada pela classe de controle onde a classe de controle será onde coloco minhas regras de negocio e as chamadas dos métodos das classe de entidade. “Não sei se estou certo.”

continuando… então quando quero utilizar o metodo cadastrar por exemplo:

da iterface chamo o método cadastrar que esta na classe de controle…
“para fazer essa chamada a esse metodo não é so instaciar um obj da classe de controle e chamar o metodo??”
e esse metodo da classe de controle é implementado pela classe Produto que tem o método cadastraProduto();

“Não sei se era isso que você perguntou mas é o que eu acho que sei…”

Segue o Caso de Uso eu não especifiquei muito so coloquei as operações basicas, OK!!!

Mais uma vez muito obrigado, cara!!

Welligton, tranquilo, todos estamos aqui para aprender… alguns comentários…

O caso de uso é o texto. O diagrama é só para ajudar. Tenho um artigo no curso online grátis que fala um pouco sobre caso de uso CRUD (apesar que geralmente caso de uso assim nem chega a existir). Quando falei sobre caso de uso é o texto que estava me referindo. Nesse post eu escreví um caso de uso simples:

http://www.guj.com.br/posts/list/37661.java#201019

Seu raciocínio está certo, mas geralmente um entity não consegue se criar a sí próprio (vixe). Geralmente temos um repository que serve para buscar entities (faça uma busca aqui no fórum que vc vai achar material, ou acesse o site do www.martinfowler.com, no catalogo de patterns). Este mesmo repository pode ter uma operação add(Entity) que cadastra.

Regras de negócio devem ao máximo serem alocadas aos entities e não para as classes de controle. Aliás, os stereotypes padrão da UML 2.0 são <<boundary>> , <<control>> e <<entity>>.

Você já tem o texto do caso de uso?

Sim eu tenho o descritivo…eu pensei que fosse o diagrama.

Obrigado pelas dicas…já entrei nesse site que você falou e ja cadastrei lá…depois vou ver como é esse curso…

Olhei o exemplo que você fez…nós também fizemos algo do tipo…vou postar para ver o que você acha, blz?

Outra coisa que eu fiquei “voando”, falei da classe de controle <> não é la que colocamos as regras de negocio e as chamadas dos métodos…não é tipo o “meio de campo entre a interface e a entidade”, voce deixa separado os metodos de uma classe e coloca as regras de negócio na controle???

então segue o descritivo do “caso de uso Produtos”

Não consigo baixar doc. cole o texto. O que falei é que devemos ao máximo alocar regras de negócio para entidades e não para as classes de controle.

OK?

Caso de Uso: Produtos

Ator Principal Gestor de Compras
Atores Secundários Gerente

Descrição
O Gestor de Compras pode cadastrar um novo produto, alterar, remover e pode pesquisar os dados do produto.

Fluxo Principal

1. O Gestor seleciona a opção de cadastrar o produto.
2. O sistema abre uma nova tela de cadastro de produtos
3. O gestor pode cadastrar um produto.

Fluxo Alternativo

1 - Pesquisar produto:
1.1 – O sistema abre uma tela de pesquisa de produtos onde o usuário poderá informar o código ou o nome do produto.
1.2 - O sistema mostra os detalhes do produto encontrado.

2 - Novo produto:
2.1 - Apaga os campos que estão preenchidos.
2.2 - O sistema habilita os campos para que sejam preenchidos.
2.3 - O ator informa os dados do novo produto a ser cadastrado.

3 - Alterar produto:
3.1 - O sistema habilita os campos para que possam ser alterados.
3.2 - O ator altera os dados.
3.3 - O ator confirma as alterações no produto.

4 - Confirmar:
4.1 - O ator confirma o cadastro do novo produto.
“Produto cadastrado com sucesso”.

5 - Remover:
5.1 – O ator localiza o produto.
5.2 – O ator remove o produto.

6 - Cancelar:
6.1- O ator pode cancelar a operação de alteração e cadastro de um novo produto.

7 - Relatório:
7.1 – O ator pode imprimir relatórios dos produtos

8 - Sair:
8.1 - Quando o ator escolhe esta opção, o sistema sai da tela de cadastro de produtos e retorna para a tela principal.

Fluxo de Excepcional

1 - Produto não encontrado:
1.1 - Caso não seja encontrado nenhum produto, o sistema emite uma mensagem “Nenhum produto encontrado”.

2 – Código para pesquisa inválido
2.1 – Caso o código para pesquisa estiver vazio, o sistema emite uma mensagem “Favor preencher o campo código”.

3 – Produto não cadastrado
3.1 – Caso não seja possível cadastrar o produto, o sistema emite uma mensagem “Não foi possível cadastrar o produto”.

Obrigado pela toque das regras de negócio que coloca-se na entidade!!

Está aí o Descritivo…!! T+

Vamos dar só uma melhorada na leitura do seu UC. Prefira usar o termo ator no texto, se por alguma razão o ator mudar você não precisa alterar o texto todo.

Fluxo Principal

• O Ator seleciona a opção de cadastrar o produto [A1];
• O Sistema abre uma nova tela de cadastro de produtos;
• [P1] O Ator entra com os dados do produto;
• O Sistema cadastra o produto;

Fluxo Alternativos
[A1] - Pesquisar produto

• O Sistema abre uma tela de pesquisa de produtos;
• O Ator informa os dados de busca;
• O Sistema mostra os produtos encontrados;
• O Ator seleciona um produto. Volta para o passo P1 [A2]

[A2] - Remover produto

– O Ator informa que deseja remover o produto;

– O Sistema remove o produto. (não é o ator que remove, é o sistema)

Você está detalhando demais o caso de uso. Determinados detalhes é melhor deixar a responsabilidade para o seu caprichoso programador (mensagens de quando não existe dados para mostrar como exemplo). Outros detalhes como o botão cancelar estarão num protótipo e o programador deverá se preocupar com isso também.

Caso de uso se foca no Ator e não no Sistema. Casos de uso são requisitos e não possuem detalhes de implementação (note que vc só tem uma elipse).

OK?

rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria…mas valeu mesmo pelas dicas sempre pensar na posição de quem está usando o sistema…certo?
Mas você acha que só esta detalhado de mais, a estrutura de maneira geral está boa?
Vou fazer as alterações que você deu as dicas!!
O ator não faz é o sistema, olhei o vacilo que dei…

Então com relação ao diagrama de sequência partindo desse descritivo o que você acha??

Muito Obrigado pelo tempo e atenção!!!

wellington_arantes:

rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria…

Acho que o seu diagrama de seq. está OK, só falei que não entendí a parte que a própria entidade retorna ela mesma. A interação diz como os componentes conversam para resolver o propósito do caso de uso. Aí sim você estará investigando o funcionamento interno do sistema.

O Caso de Uso é requisito. É O QUE o sistema tem que fazer, e não COMO ele faz, então, não precisa pensar em como ele funciona. Um protótipo ajuda a dar uma “cara” para o caso de uso e resolve muitos outros requisitos. Caso de Uso isoladamente não são suficientes para mapear todos os requisitos. Fórmulas e Cálculos também ficam fora do caso de uso.

Vc já pegou a idéia: O FOCO NO ATOR. O caso de uso resolve o que é importante para o Ator.

A estrutura do seu caso de uso está OK, fora os comentários que vc já entendeu…

Ah agora acho que sei explivcar o que fiz, a entidade retornar uma “valor”…

Vou tentar explicar o que pensei.

Na classe de entidade tem o método que retorna um boolean por exemplo.
A classe de controle faz a chamada do método que esta na entidade, o método é executado e retorna um boolean.

Pensei assim…

Na classe produtos terá um método cadastrar que se tudo ocorrer bem ele retorna true, para a classe de controle que retorna true para a interface e se precisar faz os tratamentos com o valor do retorno!!!

Muito obrigado novamente cara!!!
Valeu muito!!

também fasso parte desse projeto junto com meu brother camarada "wellington_arantes"
Gostaria de tirar certas dúvidas, das quais não consegui entender de maneira correta
se não for incomodo

1-

pelas citações acima, não consigo visualizar qual seria a melhor opção pra um cadastro de produtos, qual seria o ponto de equilibrio???
por que não fazemos um cadastro de produtos todos aqui envolvidos para o diagrama de sequencia, a gente fica falando, falando, falando
q tal fazermos na prática um ideal (com as entidades citadas por wellington_arantes)???
isso ajudaria várias outras pessoas q tivessem dúvidas, para não passarem a mesma dificuldades
poderíamos até deixar na wikipedia

grande abraço a todos

Heero, quando se fala no diagrama de sequência o mais comum é esse tipo de discussão. O que você precisa ter em mente é que o diagrama de sequência é um diagrama de interação, isto é, ele mostra como os componentes trocam mensagens para resolver um requisito (que geralmente é um caso de uso).

Essa resposta é você quem vai ter que investigar. Minhas dicas são: foque o diagrama na comunicação entre os componentes, se seu diagrama descobrir as operações public que resolvem a interação já está muito bom…

Não use o diagrama de sequência para demonstrar a implementação interna do componente. Só isso…

Olá

wellington_arantes:

Muito obrigado novamente cara!!!
Valeu muito!!

Que tal dar umas 5 estrelinhas para o Rodrigo que está ajudando tanto a vocês?

[]s
Luca

Comentários de quem tá començando também …

1. O título do caso de uso não deveria ser o objetivo do ator principal ? E não deveria conter um verbo ?

2. Um CRUD sem nenhum fator de complexidade deveria mesmo ser detalhado neste nível ? Com diagrama de sequencia e tudo mais ? Ou bastaria a narrativa do caso de uso utilizando o escopo do usuário.

2.1 Se o cadastro de produto tivesse alguma interação com entidades de estoque ou alimentasse contadores se justificaria o detalhamento. Estou certo ?

3. É correto criar os casos de uso com a implementação já pronta na cabeça ? Ou deveríamos somente concentrar-nos no que domínio nos diz ?

Fala Rodrigo olhando o caso de uso que você reescreveu me surgiu algumas dúvidas

Pesquisar produto é um fluxo alternativo de cadastrar produto?

No fluxo alternativo [A1] ele pesquisa e encontra um produto!(Sinal que ele esta cadastrado). Se ele já esta cadastrado porque volta ao passo [P1] entra com os dados e logo em seguida cadastra denovo?

[]s Valews pela ajuda

gafanha:

Comentários de quem tá començando também …

1. O título do caso de uso não deveria ser o objetivo do ator principal ? E não deveria conter um verbo ?

2. Um CRUD sem nenhum fator de complexidade deveria mesmo ser detalhado neste nível ? Com diagrama de sequencia e tudo mais ? Ou bastaria a narrativa do caso de uso utilizando o escopo do usuário.

2.1 Se o cadastro de produto tivesse alguma interação com entidades de estoque ou alimentasse contadores se justificaria o detalhamento. Estou certo ?

3. É correto criar os casos de uso com a implementação já pronta na cabeça ? Ou deveríamos somente concentrar-nos no que domínio nos diz ?

Perguntas bem colocadas.

1 - Sim. O título do caso de Uso deve expressar a META do usuário ao utilizar o sistema. No caso aqui, eu preferiria utilizar “Manter Produto”.

2 - Há controvérsias. Se vc usa RUP, provavelmente seria obrigado a fazer todo o detalhamento exigido pelo template. O XP seria mais flexível e, pra falar a verdade, utilizaria Story Cases no lugar dos Casos de Usos.

2.1 - Talvez não. Para que vc utiliza os contadores? Para atender outra funcionalidade do usuário? Por outro lado, se, por exemplo, uma inserção de um Produto dispara um e-mail para o Almoxarifado, isso deveria estar descrito no Caso de Uso e no Diagrama de Sequência.

3 - Não entendi. Explique com um exemplo.

Bruno, esse templatezinho que tenho instruído o pessoal é algumas adaptações que fiz na maneira que o Cockburn descreve no livrro Writting Eff. Use Cases.

Para falar a verdade, no fluxo [A1] faltou um primeiro passo:

• O Ator informa que deseja buscar um produto;
  (Acho que isso vai dar mais sentido)

O caso de uso possui um fluxo básico, é a maneira mais comum do ator atingir o objetivo. Dessa maneira comum, surgem jeitos alternativos do ator atingir o objetivo ou por alguma razão o objetivo não pode ser alcançado.

A leitura do caso de uso nos diz que onde no fluxo básico [A1] ocorre. Isso facilita a decomposição de cenários que podem ser os seus Casos de Teste. O que chamamos de cenário 0 (zero) é o próprio fluxo básico:

• O Ator seleciona a opção de cadastrar o produto;
• O Sistema abre uma nova tela de cadastro de produtos;
• O Ator entra com os dados do produto;
• O Sistema cadastra o produto;

Como temos um fluxo alternativo, temos o cenário 1 (pesquisar produto):

• O Ator informa que deseja buscar um produto; (o passo que esqueçí)
• O Sistema abre uma tela de pesquisa de produtos;
• O Ator informa os dados de busca;
• O Sistema mostra os produtos encontrados;
• O Ator seleciona um produto.
• O Ator entra com os dados do produto;
• O Sistema cadastra o produto;

No fluxo alternativo [A2] que ocorre dentro de [A1], temos mais um cenário (remover produto):

• O Ator informa que deseja buscar um produto; (o passo que esqueçí)
• O Sistema abre uma tela de pesquisa de produtos;
• O Ator informa os dados de busca;
• O Sistema mostra os produtos encontrados;
• O Ator seleciona um produto;
  – O Ator informa que deseja remover o produto;
  – O Sistema remove o produto.

A indicação do ponto onde ocorre o fluxo alternativo é importante para a decomposição de cenários de maneira quase automatizada (algumas ferramentas ajudam nessa tarefa).

A lição 4 do curso on-line grátis da ASPERCOM explica isso melhor…

OK?

Tudo o que foi dito aqui ficaria melhor representado com protótipos de telas e um diagrama que ilustre a navegação entre elas. Isso seria:

• Mais prático (ajuda o programador/web designer)
• Mais fácil (evita discussões relacionadas a estilos pessoais de escrita)
• Mais rápido
• Mais intuitivo (utiliza imagens em vez de linguagem escrita)

Exato, é a eterna questão do CRUD Use Cases, sobre sua aplicabilidade ou não. Foi o que falei no post abaixo:

http://www.guj.com.br/posts/preList/37595/202235.java#202235

Usei esse post mais para demonstrar a técnica.

Rodrigo tomei a liberdade de editar seu caso de uso! Derrepente você olhando as diferenças você consegue intender minhas dúvidas.

Tambem li [Cockburn] Writting Eff. Use Cases. Acho que uma troca de ideia vai ser de grande valia pelos menos para mim.

Caso de Uso: CRUD Produto

Fluxo básico

1 O Ator solicita o cadastro de um produto;

2 O Sistema sistema possibilita que o ator entre com os dados do produto; (Não acho legal mencionar interface)

3 O Ator entra com os dados do produto;

4 O Sistema cadastra o produto;

Fluxos alternativos

1.1 Ator solicita a alteração de um produto

1.1.1 Sistema possibilita que o ator pesquise o produto a ser alterado;

1.1.2 O Ator informa os dados de busca;

1.1.3 Sistema mostra os produtos encontrados;

1.1.4 O Ator seleciona um produto.

1.1.5 O Ator entra com novos dados do produto;

1.1.6 O Sistema altera o produto;(Se o produsto já esta no sistema sinal que ele ja esta cadastrado, então ele não deseja cadastrar mas sim alterar)

1.2 Ator solicita a exclusão de um produto

1.2.1 Sistema possibilita que o ator pesquise o produto a ser excluido;

1.2.2 O Ator informa os dados de busca;

1.2.3 Sistema mostra os produtos encontrados;

1.2.4 O Ator seleciona um produto a ser excluido;

1.2.5 O sistema exclui produto.

[b] Eventos que façam com que ocorram fluxos alternativos:

1.1 Ator solicita a alteração de um produto
1.2 Ator solicita a exclusão de um produto

Existem outros ainda por simplicidade não os coloquei!
[/b]

[]s

Se esse é a sua versão definitiva, na minha opinião, não gosto de numerar. Outro ponto, você está descrevendo cenários e não casos de uso. Note que seus “fluxos alternativos” são um exemplo de utilização completa.

Bom, Bruno, casos de uso possuem diversos estilos de escrita. Isso varia de projeto para projeto. Atualmente estou usando Casos de Uso mais para mapear objetivos “de grande valia” para o usuário, isto é, CRUD estão fora. Para cruds não uso nem protótipo de tela e nem diagrama de navegação (como o Taz falou). Um simples texto numa lista de requisitos é suficiente:

FEAT 331: Permitir o cadastro de produtos;
http://www.agilemodeling.com/essays/fdd.htm

Razão: CRUD possui um risco tão baixo que não vale a pena. Caso de Uso é uma boa ferramenta para mapear objetivos que são arriscados para o projeto. Possivelmente esses objetivos terão um caso de teste derivado do caso de uso que valide esse objetivo. Além disso, esses casos de uso são os que realmente necessitam de uma investigação mais aprofundada em análise e arquitetura (aí é que entra mais UML).

Vou repetir o meu lema: Bom senso… o desenvolvimento de sistemas se baseia em bom senso…

De qualquer modo, nesse tópico, evoluí a discussão mais para elucidar a aplicação da técnica para quem está começando…

OK?

rodrigoy:

Outro ponto, você está descrevendo cenários e não casos de uso. Note que seus “fluxos alternativos” são um exemplo de utilização completa.

Não intendi o que você quis passar você poderia detalhar um pouco mais para mim?

De qualquer forma eu prometo ler [Ambler] um dia…

Você não acha que a busca de produtos seria a mesma tanto para alterar quanto para excluir? Mas isso é só um detalhe. Aquela parte dos “eventos” também não é “tradicional”.

Ahh tá!!!

A parte de eventos fui eu que coloquei mesmo so para explicitar aqui no post ela realmente não faz parte…

Difícil encontrar isso por aí. O pessoal de “qualidade” interpreta mal o RUP e quer obrigar os desenvolvedores a usar “templates” para que eles não se “desviem para o lado negro da força”. Se faltar uma vírgula, o Caso de Uso precisa ser revisto. Imagina se faltarem alguns Casos de Usos de alguns CRUDizinhos ali, aí a “casa cai”. :roll:

Bom dia Rodrigo, Taz!

Hoje pela parte da manhã um amigo meu de trabalho me disse que leu o tópico e ficou com algumas dúvidas! Geradas pelas partes citadas abaixo.

Meu amigo chegou até a mim hoje de manhã e disse mais ou menos assim:

-Bruno estou preocupado estive lendo o tópico ao qual você estava discutindo sobre casos de uso. E vi que as pessoas raramente fazem casos para as coisas que nós estamos fazendo, algumas pessoas fazem somente prototipos de interface e diagramas de navegação, outros nem ao menos o fazem.
-Porque mesmo Bruno que estamos fazendo estes casos de uso?

Eu respondi:

-Bom hoje estamos trabalhando em uma equipe que ainda não conseguiu alcançar um nivel bom de conhecimento do dominio ao qual nosso projeto esta relacionado.
-Se eu fosse adotar a premissa que todos da equipe tem um bom conhecimento como eu e você e decidi-se por não fazer os casos de uso, na hora do projeto e implementação veriamos que esta faltando conhecimento de dominio para que essas disciplinas sejam feitas.
-Eu acho realmente importante que agente se prenda explicitar alguns poucos detalhes que o cliente exigiu, para que amanhã não entregamos o produto errado.
-Afinal de contas existem regras e detalhes que são realmente muito importante para o nosso cliente como: Um agendamento não pode sobrescrever o outro. Este é um exemplo de detalhe que o nosso cliente exige e ainda esta muito subjetivo na cabeça da nossa equipe.

The end! hehehe

Convenci meu amigo de equipe, mas será que essa é realmente a melhor forma de resolver meu problema? (Todos temos medo de deixar escapar o mesmo bom senso que todos almejam)

[Editado]
Agorinha meu gerente do setor me veio pedir para eu detalhar o Caso de uso Administra Estrutura Logica do Sistema. E ainda explicitou faz na forma de adicionar, remover e alterar nó do sistema !!Nada mais que isso!! Tudo para não gastar tempo!
Ai eu fico pensando sera que é realmente válido ser subjetivo assim? Tratar qualquer coisa como um nó? 90% da equipe não tem ideia de que um nó pode representar no sistema e de como as diferenças entre nó vai influenciar na sua administração!

Acho um risco muito alto ser muito subjetivo!

Acho que ter bom senso não é ser subjetivo!
[/Editado]

Esse tipo de questionamento é ótimo e é ele que realmente leva a desenvolver software de qualidade. Traduzindo:

• Pq estamos fazendo da maneira X? A maneira X tem se mostrado útil?
• Quantas vezes os artefatos gerados pela maneira X foram requisitadas em outras iterações do projeto?
• Vale a pena desperdiçar recursos construindo artefatos da maneira X? Não podemos melhorar, fazendo da maneira Y?

Perceba quanto tempo já gastamos falando sobre estilos de escrita de um bom Caso de Uso (maneira X). Veja bem, não estou dizendo que vc deve abolir Casos de Uso do seu projeto. Estou recomendando que use-os apenas nos lugares onde eles são mais apropriados.

Se vc precisa deixar documentado de alguma maneira que um agendamento não pode sobrescrever outro, vc poderia descrever claramente isso, da seguinte forma (maneira Y):

Requisitos

Agendamento

AG01 - Agendamentos não podem ser sobrescritos. Caso haja uma tentativa de sobrescrição o sistema apresenta a mensagem “Agendamento já realizado para a Data XX/XX/XXXX e para o Recurso XXXXX”

AG02 - …

AG03 - …

Simples, objetivo, rápido, barato e efetivo.

Se X é melhor e mais efetivo que Y, a equipe dirá, e não o cara da qualidade que nunca sequer programou uma linha de código em Java e que não passa noites a fio durante a implantação do projeto.

Veja a história: como a indústria japanesa, hoje, consegue fabricar carros de melhor qualidade que a indústria americana? Eles conseguiram criar uma cultura onde os próprios funcionários eram estimulados a melhorar a qualidade do produto final. Como eles poderiam contribuir? Melhorando o processo de montagem. Dessa maneira, quando qq funcionário detectasse um problema na linha e sugerisse uma melhoria, era papel da Área de Qualidade analisar a viabilidade de se implantar essas melhorias e de , caso dessem certo, institucionalizá-las. Essa é a base do CMMI.

A questão final é: como vc vai estimular os desenvolvedores a darem opinião sobre o processo de desenvolvimento? Obrigando-os a preencher templates de documentos!? Sinceramente, acho q não é por aí…

Concordo plenamente!

Mas tem horas que templates são uteis! Pena que a utilidade não é tão visivel assim na prática.

Ex.:
1- Você manda o cara implementar algo sem nem ao mesmo ter conhecimento do dominio! A implementação dele mela.

2-VocÊ manda o cara fazer um caso de uso seguindo um template a partir dai ele obtem um conhecimento bom do dominio e faz um implementa ção boa! O problema que esse cara fica com a visão po eu já sabia tudo eu não precisava daqueles chatos casos de usos. Esse cara não se da conta que foi o caso de uso que gerou o conhecimento de dominio para que ele fizese uma boa implementação. Não podemos nos tornar um pre-conceituosos em relação a casos de uso… Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso

Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso

O que é mais importante em qualquer projeto é sua SIMPLICIDADE e a CUMPLICIDADE das pessoas que o conduzem. Se vc não conseguir essas duas coisas, Casos de Usos não vão levá-lo ao sucesso.

Taz:

Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso

O que é mais importante em qualquer projeto é sua SIMPLICIDADE e a CUMPLICIDADE das pessoas que o conduzem. Se vc não conseguir essas duas coisas, Casos de Usos não vão levá-lo ao sucesso.

Como diria meu Professor de Administração de Empresas tudo se resume em Sinergia! E realmente é verdade.

Oi pessoal
Estou modelando meu sistema de trabalho de conclusão de curso, é um sistema de hotelaria, mas estou com dificuldades no diagrama de sequencia. Pois a primeira parte é de Gerar Hospedagem, ou seja, cadastrar, excluir, alterar…Mas como coloco isso no diagrama de sequencia???

Se alguém souber.

Desde já fico grata!