Is it possible to generate code from Use Case, Activity or Sequence Diagram in Enterprise Architect?

Question

I'm a student of software engineering. My lecturer of "Software Architecture and Design" has told us that we can generate source code from all the UML diagrams (or most). I already can / have generated code from class diagram. I'm unable to generate code from other diagrams. Do I have to someway connect those diagrams with class diagrams to do that?

Answer 1

I think I have found the answer. We can generate code. Say I have a "use case". I right-click on it. Go to "advance" and select "instance classifier". Over there I can actually make my "use cases" , "sequence diagram objects" etc the instances of an already created class or I can even create a class right over there.

Answer 2

This is simply nonsense. You can not generate code from any diagram at all. You can however generate code from a UML model. This can (but not must) have a couple of diagrams to help visualization for humans.

Now, code is related to classes. That means you need at least some classes defined in your model. A use case helps understanding why classes will do things they are supposed to do. But in no case can you create code from a use case.

There are other model elements which help support creating more detailed code. Those are e.g. state machines which can translate into equivalent code sections.

Activity and sequence diagram also help visualizing how certain code sections run during execution. But you will not (seriously) use them to create code.

Answer 3

Yes, you can, but it's not as simple as what you're describing. Model-Driven Architecture is an active area of research right now, but it hasn't really "caught on" yet. Its proponents argue that it allows for a higher level of abstraction in much the same way that C offered a higher level of abstraction than assembly language and Java offered a higher level of abstraction than C. I think that this could be very useful in the future if they can get the tooling right.

Actually, this isn't even an entirely new idea - the idea of graphical programming in general (which, if you think about it, is basically a generalization of UML-derived programming) has been around at least since the 1980s that I know of (and probably a lot earlier). In fact, Frederick Brooks Jr. talks about it in No Silver Bullet – Essence and Accident in Software Engineering (which was originally published in 1986 and appears in current editions of The Mythical Man-Month):

A favorite subject for Ph.D. dissertations in software engineering is graphical, or visual, programming, the application of computer graphics to software design. Sometimes the promise of such an approach is postulated from the analogy with VLSI chip design, where computer graphics plays so fruitful a role. Sometimes this approach is justfied by considering flowcharts as the ideal program design medium, and providing powerful facilities for constructing them.

Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will...

His argument was that, at the time it was written, the tooling just wasn't "there" yet; for example, screen sizes were notoriously small. Also, the flow chart is actually a really bad design mechanism. Also,

More fundamentally, as I have argued above, software is very difficult to visualize. Whether we diagram control flow, variable scope nesting, variable cross-references, data flow, hierarchical data structures, or whatever, we feel only one dimension of the intricately interlocked software elephant. If we superimpose all the diagrams generated by the many relevant views, it is difficult to extract any global overview. The VLSI analogy is fundamentally misleading - a chip design is a layered two-dimensional object whose geometry reflects its essence. A software system is not.

I'll leave it to you to judge whether or not you agree with him or whether this still applies.

So, to summarize: yes, it's at least theoretically possible, and there have been considerable efforts to generate code from UML diagrams, but you'll need multiple diagrams to generate much more than basic class structures and method stubs. It's not like you can write a use case diagram, press a button, and magically have a complete software system.