使用统一建模语言图对Go进行编程

UML still gives you tools useful for analysis and design of components, interfaces, and data. Go is not an OO language, so you cannot use inheritance, polymorphism, methods, etc. You don't need a new paradigm, you may need an old one: Structured Analysis and Structured Design.

If you like planning and modeling more than programming you should just stick with Java.

If you like building and maintaining the actual code and working systems you should try just planning your Go program on a piece of paper or a whiteboard and get programming.

The fact that methods are declared outside the definition of the struct itself should not be significant; it is just a minor syntax difference. The methods belong to the struct type just as surely as if they were inside the braces. (They are declared outside the braces because methods aren't limited to structs.)

The real potential problem with using UML with Go is that UML is normally used with traditional object-oriented design (i.e. class hierarchies), and Go takes a different approach to inheritance and polymorphism. Maybe UML can be adapted to Go's type system—I'm not familiar enough with UML to say—but your design approach will probably need to change somewhat whether you continue using UML or not.

Go is not intended to be used in the everything-is-an-object style of Smalltalk and Java. Idiomatic Go programs generally contain a large percentage of procedural code. If your design process focuses on object modeling, it will not work well for Go.

Go Structs contain properties/state, but no methods, and methods/functions that use Structs as parameters (even the ones that do magic so that it makes a Struct look like an object), don't contain methods, or state.

As you may know, in C++ you can also declare methods on structs - just as in classes with the only difference that you won't be able to use access modifiers.

In OOP languages you declare methods of a class inside the class definition, giving the feeling that these methods are somehow part of the class. This is not true for most languages and Go makes this obvious.

When you declare something like the following pseudo-code in a traditional OOP language:

class Foo {
    public function bar(x int) {
        // ...
    }
}

the linker will export a function that will look something like:

Foo__bar(this Foo, x int)

When you then do (assume f is an instance of Foo):

f.bar(3)

you are in fact (and indirectly, more on that later) doing:

Foo__bar(f, 3)

The class instance itself will only contain a so called vtable with function pointers to the methods it implements and/or inherits.

Additionally, methods do not contain state, at least not in the contemporary programming world.

Does this mean I should be using another Methodology to model a Go Program or does UML sufficiently model the language constructs?

UML should suffice.

Is it time for a new (perish the thought!) diagramming technique, for the brave new world where behavior is no longer controlled by an object?

Naa.

Can behavior be modeled without reference to the state that it is affecting?

Yes, that's what interfaces are for.

I am trying Data Flow Diagrams out, to see if they fit better to the paradigm. So far so good, but I think I am going to come unstuck when I model the Methods of a struct, the compromise in the DFD being that they are treated as Functions. :(

Do not get lost in abstractions, break them. There is no perfect paradigm and there will never be.