ti-enxame.com

Diferenças entre DFD (diagrama de fluxo de dados) e diagrama de atividades

Preciso conhecer essas diferenças para entender como usá-las corretamente.

Quais são as diferenças entre o DFD e o diagrama de atividades?

21
llazzaro

Na verdade, é razoavelmente lógico. Você só precisa olhar para os nomes.

Nos diagramas de fluxo de dados , as linhas entre "caixas" representam dados que fluem entre os componentes de um sistema. Como eles mostram apenas o fluxo de dados, eles não fornecem uma indicação de seqüenciamento.

Nos diagramas de atividade , essas linhas são simplesmente transições entre atividades e não representam fluxo de dados. Eles representam mais o seqüenciamento de atividades e decisões. Você pode dizer por que ordem as coisas acontecem.

Essa é uma explicação simplista, mas deve ser um bom ponto de partida. Informações adicionais podem ser obtidas na Wikipedia para DFDs e diagramas de atividades .

22
paxdiablo

Viés explícito: sou um defensor das DFDs.

@John está correto em que os diagramas de atividades podem sejam usados ​​para representar o fluxo de objetos. @ pax igualmente corretos raramente são.

Duas grandes vantagens do DFD para mim:

  1. Link para o modelo de objeto. Os armazenamentos de dados em um DFD fornecem uma maneira realmente agradável de vincular os dados produzidos/consumidos ao modelo de objeto. Muito útil para manter a consistência e garantir que seu pensamento esteja alinhado.

  2. Eles enfatizam o fluxo de controle. Com demasiada frequência projeta sequenciamento excessivo. Os diagramas de atividades oferecem suporte à simultaneidade - mas requer que o usuário (a) lembre-se e (b) use-o. Portanto, o padrão é over-serialization. DFDs não. Eles expõem as dependências da sequência real sem nenhum esforço extra por parte do usuário. Consequentemente, eles também facilitam a visão de relações causais. Se os processos aeb exigem entrada de dados D, é óbvio no diagrama. E, portanto, a atividade paralela é óbvia.

Não me interpretem mal - não sou contra as atividades. Onde o fluxo de controle é a principal consideração, usarei um AD sobre um DFD. Mas empiricamente eu diria que acho os DFDs uma ferramenta mais útil em ~ 70-80% dos casos.

Claro, YMMV.

14
sfinnie

Apenas uma opinião humilde de alguém que teve que explicar processos, tanto de computador quanto de manual, para a alta gerência e os CIOs. Descobri que simples é melhor e, libra por libra, os DFDs transmitem a mensagem quando, na verdade, me perguntam sobre detalhes. Dito isto, a melhor abordagem é sempre praticar o enredo e responder em respostas simples.

Um comentário final sobre a era das ferramentas e produtos. Lembre-se de que na maioria dos casos, eles estão administrando o negócio e funcionam muito bem. O ditado "você o quebra (ou substitui) e você o possui" pode fazer de você um herói ou transformá-lo em um palhaço.

Temos um CIO que deseja substituir todos os aplicativos de mainframe pela simples razão de serem de tecnologia antiga. É preciso pesar as consequências e entender se a substituição pode lidar com a carga de trabalho. Você já se perguntou por que JPMC, Credit Swiss, Walmart e Bank of America para citar alguns mainframes ainda em execução?

Minhas desculpas por levá-lo nessa direção. Verifique se, independentemente da ferramenta de análise usada, todos os aspectos da substituição estão documentados, incluindo carga de trabalho, E/S, usuários simultâneos, curva de adoção e escalabilidade.

1
Jeff Sullivan

Se olharmos mais de perto para um diagrama de fluxo de dados, podemos notar que, quando um nó coleta dados de todas as suas bordas, ele começa a processá-los. E para processar, ele precisa de um token de atividade, que representa o acesso a um processador. Geralmente, o processo de obtenção desse token é omitido, mas deve existir. Normalmente, o nó inteiro como um token é colocado em uma fila de extremidade dupla, na qual, no outro extremo da fila, atividades livres (processadores ou threads) são armazenadas. Um conjunto de encadeamentos é um exemplo perfeito dessa fila e os nós prontos para trabalhar são representados como tarefas. Assim que um nó atende à atividade, ambos são retirados da fila e o processamento real é iniciado. Quando o processamento termina, a atividade é retornada à fila. Dessa forma, podemos pensar na atividade como um tipo especial de token.

Portanto, os diagramas de fluxo de dados e de atividades são apenas variantes simplificadas de um diagrama geral de fluxo de dados ativos, com atividades ou tokens de dados omitidos. Mas, geralmente, os dois tipos de tokens podem ser representados em um diagrama simultaneamente.

Os programadores costumavam pensar em encadeamentos como atividades, mas se os observarmos mais de perto, notamos que quando um encadeamento está pronto para ser executado, ele fica alinhado com os processadores, e a execução real é iniciada apenas quando um processador livre alterna para esse encadeamento. Isso é analogia absoluta, pois as tarefas são executadas em um conjunto de encadeamentos. Portanto, do ponto de vista simplificado, um encadeamento é uma atividade e, do ponto de vista mais rigoroso, um encadeamento é um token de dados e a única atividade real é um processador físico. Isso mostra que os tokens de atividade não são diferentes dos tokens de dados. E, de fato, podemos omitir a rota do nó que persegue uma atividade e considerar um nó de fluxo de dados como uma atividade em si, que começa a funcionar imediatamente quando todas as suas arestas (entradas) contêm dados.

0
Alexei Kaigorodov

Data Flow representa o fluxo dentro de um módulo ou um código independente. Contudo Sequence Diagram representa a sequência de atividades entre os diferentes módulos.

Sim, em alguns momentos eles podem transmitir as mesmas mensagens.

Eu basicamente uso Sequence diagram em documentos de interface que serão compartilhados com outros módulos/elementos, no entanto DFD será usado em documentos de design de baixo nível que serão usados ​​para desenvolver o código em um módulo ou elemento de rede.

0
Nadeem Haleem