Deveria modelar a análise de documentos?

5

eu uso UML

Eu, como a maioria (eu acho), uso a UML como meu principal conjunto de ferramentas de diagramação. A UML é clara e útil para representar a OOP e possui diagramas suficientemente diversos de que há algo para qualquer área que você esteja modelando; sejam árvores de classes, relacionamentos de componentes ou interações específicas entre classes.

Isso significa que eu tenho apenas um modelo

A UML é claramente projetada para representar o domínio implementado.

Os diagramas de classe e objeto são bastante explícitos; Eles incluem métodos e propriedades que raramente podem ser definidos com alguma certeza até que você esteja decidindo detalhes específicos da implementação. Da mesma forma, os diagramas comportamentais apresentam interações explícitas entre objetos (mensagens enviadas, a ordem enviada, etc.).

No entanto, os primeiros modelos analíticos raramente são tão explícitos. Para o contexto, abordo minha análise inicial da seguinte forma:

  1. Descreva os casos de uso a serem cumpridos; com cenários descrevendo a entrada do ator e a resposta do sistema
  2. Descreva as interações a serem cumpridas; este componente / pacote / domínio deve ter interface X e deve suportar uma conversa como ...
  3. Descrever processos atendidos pelo domínio; este domínio deve fazer X e este é o fluxo de trabalho

A partir daqui, tenho um conjunto claro de requisitos e começo a analisar o próprio domínio do problema; definição de objetos / classes, suas associações, o tipo de informação que eles mantêm e os tipos de operações que eles suportam. Por fim, progrido para o projeto detalhado que fornece todas as classes de nível de implementação, concreta os métodos e propriedades exatos das classes definidas no domínio do problema, etc.

Eu uso a UML do início ao fim, mas acabo com apenas o modelo definido pela parte de design do processo. Qualquer coisa criada durante a análise acaba sendo revisada e refinada, ajustada e estimulada até que seja o mesmo que o design implementado. Isto é, tenho apenas um modelo de implementação, não um modelo analítico .

Existe apenas um modelo porque ...

Em suma, a UML incentiva detalhes. Quando estou criando meu modelo analítico, as classes que eu crio têm métodos com parâmetros etc. Quando eu passo para a implementação, isso muda e parece absurdo deixar dois modelos que entram em conflito diretamente entre si.

A UML me incentiva a escrever detalhes de implementação durante a análise, porque os mesmos diagramas e, portanto, o idioma, são usados durante as duas atividades.

Isso é desejável?

Devo adotar uma ferramenta de modelagem menos detalhada para a análise, para que ela não seja incluída no modelo de implementação?

Ou é bom ter apenas um modelo?

    
por Marvin 06.03.2016 / 23:55
fonte

2 respostas

4

Acho que os posts de Martin Fowler sobre os modos UML - UML como esboço , UML como notas , UML como blueprint e UML como linguagem de programação será útil para você. Eu também acho que o trabalho de Scott Ambler em Agile Modeling, especificamente seus escritos sobre Model Storming e Apenas modelos e documentos do tipo Barely Good Enough , também são muito relevantes.

Não concordo com a sua afirmação de que "a UML incentiva detalhes específicos". UML não é um processo. Existem processos que são centrados em UML. O Rational Unified Process, por exemplo, é geralmente ensinado em conjunto com as várias ferramentas do IBM Rational (que incluem coisas como o Rational Rose ou o Rational Enterprise Architect para desenvolvimento orientado a modelo, engenharia avançada e engenharia reversa). Mas a UML é, antes de tudo, uma linguagem. Isso significa que cada construção (cada tipo de diagrama) tem um conjunto específico de regras que governam os símbolos e o significado por trás desses símbolos para permitir que todos tenham um entendimento comum.

Parece que você está tentando incluir muitos detalhes no início. UML é uma linguagem. Só porque a linguagem tem, por exemplo, construções em um diagrama de classes para representar não apenas as relações entre classes, mas variáveis e métodos de membros públicos, privados e protegidos em uma classe, você não precisa usar todas essas construções de linguagem o tempo.

Acho que o fluxo geral do seu processo é bom. Parece que geralmente funciona para você. Eu acho que há duas mudanças que você precisa olhar para ser mais eficaz, no entanto.

Eu recomendaria ver outras coisas além da UML. Para casos de uso, acredito que você tenha algo mais do que um diagrama de caso de uso. Você provavelmente captura histórias de uso ou casos de uso em um formato tabular. Na verdade, em Destilado UML , Martin Fowler até desencoraja o uso de diagramas de casos de uso UML em favor ou textual ou tabular métodos de captura de casos de uso, uma vez que são muito mais úteis e valiosos. Scott Ambler fornece um número de artefatos de modelagem que podem ser úteis para mostrar diferentes aspectos do sistema.

Você também deve considerar o design como um processo iterativo. O fato de seus modelos que você usa para análise de requisitos precisar ser revisado e refinado ou ser lançado posteriormente é normal. Seu design começa ao mesmo tempo que o desenvolvimento de requisitos - você deve estar pensando no contexto de seu sistema (pense em diagramas de máquina de estado UML, diagramas de componentes, diagramas de implementação, diagramas de visão geral de interação). À medida que suas necessidades se tornam mais claras, você pode adicionar mais detalhes. No entanto, você não pode ter um diagrama totalmente preciso até ter código e esse diagrama só é preciso desde que o código não seja alterado.

Recentemente, comecei a defender o código como design . Agile Modeling defende uma fonte única de informações . Idealmente, essa fonte deve ser o código (e testes). No entanto, em um sistema complexo, é difícil apenas ler o código e testar e entender as interações entre os componentes e como o sistema se encaixa em sistemas ainda maiores. Nesses casos, você deseja que quaisquer modelos de design visual (UML ou alguma outra notação) sejam gerados a partir do código, de preferência de forma automática, mas a criação manual está correta em alguns casos.

    
por 07.03.2016 / 14:35
fonte
0

Com base na resposta de Thomas Owens ...

Encorajo-o a considerar a diferença entre "Model-Driven" (o objetivo é gerar diretamente o produto a partir do modelo) e "Model-Based" (o objetivo é criar uma "versão única da verdade" para as partes interessadas humanas )

Por acaso, trabalho principalmente em SysML (um perfil no topo da UML) e estou firmemente no campo "baseado em modelo". Se você está neste campo, as únicas coisas que você precisa em seus diagramas são coisas que especificamente ajudam um certo conjunto de partes interessadas a entender como o sistema funciona. Por exemplo, você pode colocar uma tonelada de coisas em um diagrama de classes, mas isso raramente é útil para as partes interessadas humanas.

Da mesma forma, você precisa pensar cuidadosamente em seus objetivos para diagramas de sequência. Você realmente tem que decidir de que lado você está (Model-based vs model-driven) antes de começar a tentar fazer o diagrama. No ano passado, no QA e no teste 2015, tive uma ótima discussão com um jovem engenheiro holandês que estava trabalhando em modelos em testes. Como ela diz: "Se o diagrama é claro e útil para os humanos, ele não tem informações suficientes para o computador executar. Se você adicionar informações suficientes para que o computador possa executá-las, o diagrama ficará incompreensível para os humanos. "

Espero que isso ajude,

    
por 07.03.2016 / 21:24
fonte