Related
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?
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.
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.
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.
I often draw a dataflow on a sheet of paper. Even the planning of my little tools is done on a paper.
There exists UML.
The problem is - I don't like it. All the tools I've used (Visio and a lot of online editors) are just not flexible for my hands. With a pencil you can easily draw shapes and connect them, describe them.
What could you suggest in order to create a diagram of data-flow, sequence diagram, etc. in the fastest, most natural and easiest way except on the computer not the paper :)
****Useful links as posted in comments:** SO Link #1 SO Link #2
Right now I am curious about 2 things and one of them was in my minds quite long ago:
1) Mindmap - I've tried a while ago, quite liked it but abandoned. Hoever will give it another try
2) Whiteboard. It would be the easiest and most natural method, except that taking a photo and storing it somewhere on a computer would make the process repetitive and boring.
Has anyone other interesting ideas? I would really like to hear what others are using to design their software and the progress of it.
Thanks a lot!
Why do you want to hand-draw the UML at all whether it's on paper or on the computer?
I agree that you need a model to represent the design. But even in large projects of about 500 man-months, I observed that only 3-4 sequence diagrams really matter and have a chance of surviving the entire lifecycle of the application. Those 3-4 sequence diagrams (and class diagrams that represent their static time relationships), usually represent the high level design of the application.
Or, look at it this way:
Any decent enterprise application will not have 20 different call flows. There will be one or two generic (or abstract) call flows, which all the concrete use cases implement. Let us take a simple Struts / EJB application. The generic flow will be something like - an action class calling a validator and then calling a stateless session bean, which in turn calls a domain class, which will call a DAO. All the use cases of the application just implement this flow with concrete classes that are specific to that use case.
Do you agree?
If you do not, I would like to hear about applications that have 20 different call flows and survived for 5 years after the first release.
If you agree with me, we are boiling down to 3-4 class and sequence diagrams even for large enterprise applications comprising several thousand classes. Why is it a big deal how you draw and maintain those 3-4 diagrams?
You might say that you want to document all the use cases for training or documentation purposes. During my last 14 years of experience in the real enterprise software world, I don’t remember seeing well 'maintained' UML documentation. First of all, good documents are difficult to produce and are not found that often. Secondly, they are out of sync with the code most of the time. Most of my experience is with large banks, insurance companies, Auto companies, etc. Those environments are just too hectic and their resources are limited (really? Are we talking banks? Yes, difficult to believe, but true) for 'maintaining' good documentation.
So am I suggesting that we get rid of UML?
No. We need visual models to represent complex systems. Human brains seem to be at their best when processing visuals. The visual cortex, which is responsible for processing the visual images, is the largest system in the human brain.
So what is a reasonable solution to easily produce and maintain UML models?
Probably we are better off using the current crop of UML tools to draw those 3-4 high-level UML diagrams. If you hate using them, check option 3 below.
For the diagrams at the next level of abstraction (any useful models should have different levels of abstraction), generate the UML from source code. You can generate both class and sequence diagrams.
In this age of agile methodologies, why not just write the shell classes and generate those 3-4 high-level UML class and sequence diagrams as well? This way there won't be any UML to maintain at all.
The source code is the truth.
Can you argue against that statement? If not, why not generate the models from the source code itself? I am not suggesting the round-trip engineering, by the way. I am just suggesting a one way trip - from code to models.
There are 2 main problems however with the generated UML.
When we hand draw a class diagram, we show the relations between the classes involved in a scenario. Most existing class diagram generating tools allow the user to drop the Java classes (the source code) into the tool and the tool automatically shows the relations between the classes. The problem here is, how does one know about the classes involved in a scenario to begin with?
The second problem is the verboseness of the generated diagrams. There are tools available to generate runtime sequence and class diagrams for a scenario. But the diagrams are often very verbose and defeat the purpose of models, whose purpose is to highlight the important aspects and filter out unimportant details.
Good UML generating tools should address both the above problems. There are a few tools in the Java domain that try to address these problems. Check the discussions below:
What tools should I use to visualize structure of my code
Are there any tools for detecting architectural and design patterns in code?
I hope I answered the original question:
Has anyone other interesting ideas? I would really like to hear what others are using to
design their software and the progress of it.
I am the author of the runtime UML generating tool MaintainJ, but I tried to address the original question in an objective manner. Your comments are welcome.
There are various tools that allow you to create diagrams based on textual input. There's some up-front learning in that you need to learn the syntax. However it's not hard to do. Once you have, creating diagrams can be very fast. There are some downsides; in most cases there's limited ability to change the layout/style. Significance of that will depend on whether you like their style or not.
There's a growing number, here's a few you might want to look at:
UMLet: desktop app, supports most UML plus various other diagrams. Can also create your own custom shapes & connectors. FOSS.
WebSequenceDiagrams.com: online sequence diagrams.
TextUML: desktop app. Focus is executable models, auto-generates class diagrams. FOSS. It also has an online commercial sibling.
hth.
I like using a whiteboard and a camera. For even more flexibility, use post-it notes on the whiteboard.
I use ER diagrams (on the whiteboard) to model my data, and message sequence charts (on the whiteboard) to model the data flow. I'll also do quick mockups of UI pages on the whiteboard.
Asides from that, I use Ruby/Rails to code server side and HTML/CSS/jQuery/JS on the client.
If even Visio is not flexible enough, I'd suggest a digital whiteboard or touchscreen with a whiteboard software. After some accommodation you could probably use a simple tablet (without display) as well - they are really cheap.
Regarding pure software: we are trying to achieve a "pen-like" input method with UML Lab, but it currently supports Class Diagrams only...
I think that the UML and code should be mixed using a class diagram. You model your architecture with the class diagram (e.g package, classes etc....) then you code your business finally multiple iterations between code and model.
I think that UML should more be oriented to code but not to focus on textual input.
The problem with standard languages, such as UML, is that you have to invest a considerable effort to learn the language and the modeling tools. These languages are defined by an expert consortium, e.g. OMG, that proposes a language specification suited to the biggest overlap of design problems in a certain domain.
Why not defining your own language that fits exactly to your needs and your specific problem? Such languages are termed Domain-Specific Languages (DSL). Instead of investing into learning a language that's complex, you invest into the definition of a languages that exactly suits your needs.
There are numerous approaches that support the definition of DSLs. The most widespread is the Generic Eclipse Modeling System (GEMS). Personally, I made great experience with GrGen due to its versatility and the possibility to automate working steps using graph transformation.
No. There are various other ways. UML is just an option.
Pen and Paper Prototyping is a great option too, it doesn't have to follow UML.
Mind Map is another great way.
For more adaptive software processes, UML use is encouraged to be as minimum as possible. Such as, teams that practice Agile or XP tend to use UML less and they would rather rely more on informal means to conceptualize the software. In a rigid structured company, UML can be rigorously followed.
I am looking for insight on modeling. I had a intro course on Design Patterns and basic class diagrams, sequence diagrams, and use cases.
The class diagrams I have found invaluable as a tool of organization in my programming. The use cases are moderately useful so far.
This semester I am in a class going into UML in much more depth i.e. Domain Analysis, Requirements Analysis, Software Design vs. Software Engineering etc.
There is a certain feeling that this is starting to be more voodoo-sciencey or non-concrete when we start trying to be precise with the ambiguities in scenarios, and changing requirements. Is UML past basic class diagrams and use-case diagrams practically useful in productivity in most applications?
It started out voodoo. Diagramming software designs has always been that way. It is a way of showing in pictures what you want to say about the design in a human language. If it was precise enough to generate code from, we'd go ahead and do that and dispense with the coding step altogether.
The only thing UML brings new to the older ways is that it is a standard. Even then, there are so many different kinds of "standard" diagrams that I have to snicker a little when calling it a standard.
However, the activity of design itself is extremely important for all but the most trivial of tasks. The question is whether you are going to spend some time up-front designing your system, or if you are going to do it on-the-fly, after having written a great deal of wrong or unnesscary code. If you want things done quickly and/or well, you do some design up front.
This doesn't just apply to writing software BTW. It is an inherent part of any complex creative activity. My father-in-law, a retired English teacher who writes his children longish postcards when he goes on vacation, actually writes outlines for his postcard messages. Most master painters and sculptors make test drawings first.
No.
All sorts and forms of documentation, are only useful as a means of communication. Documentation for documentations sake is a complete waste of time.
Writing UML is useful and productive only when it comes with a document that explains (in words) what is it you want, why, and how. only then UML can help to illustrate what you are trying to say in the document.
Software teams that produce endless amounts of UML just for the sake of drawing squares, are just wasting time.
You started out with modeling, which is a great thing to do, especially in computer science - you model all the time. Keep in mind UML is a standard for a modeling notation for software systems, nothing more (e.g. it is not an analysis or design methodology) and nothing less (e.g. it is not a way for developers to look productive by drawing nonsense).
You are on the right track, always keep in mind what is actually useful and gives you some value. This is not exactly relevant to your question, but sue cases are not use case diagrams, there are much more, have written form and might help you with much of what you described would be in your next course.
As to your concern, modeling is about abstracting from unimportant details, so some ambiguities might occour. The point is they should be unimportant for the purpose of modeling. For example it does not really matter if you include all the properties of your classes if you want to show the structure of design, e.g. use of some pattern. You can also use public properties without concerning yourself if they are private fields with getters and setters (Java), properties (C#) or generated object methods using metaprogramming (Ruby). The same holds for scenarios captured using use cases - of course you cannot (and should not try to) capture alternative branches using UML, but you can describe the conditions in use case descriptions just enough to avoid ambiguity without having to develop the system first and finding it is wrong afterwards.
As to the voodoo stuff - the problem is that UML is large and so many developers don't know how to use it right and often create more mess than value. Don't be confused by general disrespect for UML, the problem is in tool vendors, commitees and lazy developers... Behind many concepts in UML are well known formal models backed by academic science work, e.g. the state diagrams come from Harel statecharts (http://linkinghub.elsevier.com/retrieve/pii/0167642387900359). So my opinion it is not as much voodoo in principle, it is just oversold with tools not supporting the standard and also the standard tries to be and combine everything (it is an unified language...), however this slowly improves.
My advice for you would be try to learn what is important - those formalisms, analysis and design methods, try them practically and decide for yourself what is useful. If for no other reason, learn UML because it is the language for analysis and design, although large, it is still better than its ~50 predecessors combined:).
From my experience: Not really.
I never came across a really useful sequence diagram. Sequence diagrams stop being useful when the documented process becomes too complex, as you have a hard time following all the lines. But to understand a trivial process, I don't need a sequence diagram. When used as a design tool you will waste a ridiculous amount of time adjusting the diagrams, cussing MS Visio or whatever you use.
The notation however can be useful for a small snapshot when discussing something on a whiteboard. But this is valid for any notation style; UML is just well established, increasing the chances you are understood correctly.
Class diagrams are useful, both in design and in a posteriori documentation. But IMHO you shouldn't be too pedantic about them.
Not in MHO. It's completely superfluous as far as I am concerned.
I have seen UML mentioned several places in the last few years, but never had a compelling reason to use it at work so far. Is there any value in putting the time and effort to learn it? (I am a Ruby on Rails developer.)
Edit: I'm also looking for stories about how UML has made a difference in your projects to give me an idea of how I might use it.
Yes. It is the international standard methodology for systems analysis and design. When moving from the initial analysis phase through the project life-cycle, the UML gives a good road-map on where to go and how you got there. A few benefits:
It shows requirements in a way that clients / customers / management can understand.
You can iterate the model and not lose track of where the model was before
Shows exactly how you got from point A to point B
It's a standard, so anyone who knows UML will be able to interpret your diagrams
The "quickest" way to share ideas without needing to go through the entire code-base
No, save your time and don't learn it. If you are a coder and work alone and are a very careful person, you can completely ignore UML.
But, if you work with other people and want to share the result of your work, UML is a Unified language, a lingua franca that even non technical customers understand (at a certain level).
Yes and no.
Yes, learn the basics. Have a quick look at at the different diagram types etc. and have a general idea. That will help you eliminate your hesitance when someone boasts about UML.
No, if your work doesn't require to work with UML, you don't necessarily need to know UML to write good applications. If you need to discuss something on a white board just draw a few circles. That'll do.
It only helped me to produce documentation to management to impress them a little. Other than that I only find the deployment diagrams somewhat useful, that's all.
If you look at UML as a merely graphical language you consider just a very small part of it. You should instead look at UML as the primary language of the Model Driven Architecture framework which is very well implemented in Eclipse.
In Eclipse UML is (correctly) considered as a Platform Independent language with a solid syntax defined by the MOF (ECORE in Eclipse) and semantics defined by the UML specification (http://www.omg.org/spec/UML).
In Eclipse there are good implementation of the two main languages defined by the OMG for Model To Text and Model to Model transformation specifications which are respectively MOFM2T (ACCELEO in Eclipse) and QVT.
Also Eclipse provides an implementation of the Object Constraint Language (OCL) which is used by both QVT and MOFM2T to evaluate queries on models.
All this means you can easily define your own Model to Text and Model to Model transformations , in the form of Eclipse plugin, turning your UML models into whatever you need.
Now I use that to automatically generate thousands of LOC, documentation and tests with an impressive return on investment.
However I know the majority of people doesn't even know UML is a language but think it is just about tiny pictures.
Look at this links for some simple example
http://lowcoupling.com/post/46522537374/the-model-driven-architecture
http://lowcoupling.com/post/47800863669/qvt-in-place-transformations
http://lowcoupling.com/post/47347056110/models-to-text-transformations-with-mofm2t-and-acceleo
I think it's a question of scale in two dimensions: size of problem and size of team.
When a design gets to a certain size diagrams become useful in two ways: first, they help you reason about design issues. second they help you communciate the design to other poeople.
So if the team is say 20 or 30 it really does help to have some clear documentation of pieces of the overall design.
Personally I use UML maybe four or five times a year, but when I need it, I really need it. It really is better to ase a standard diagramming technique that devise your own. And with good tools it's pretty painless.
I would say that I use only a small subset of UML, class diagrams and occasional collaboration diagrams.
UML is a great language to model software for business requirements, but there is a growing community that points some disadvantages for some lacking features.
What are the most significant disadvantages that you find crucial for UML and what could it be a good alternative to solve this lacking features?
The biggest one is that it's yet another layer of red tape that gets in the way of just $#%$#% coding the thing and making it work.
The fact that people use it to "model software for business requirements", as you put it, and other such process-oriented claptrap. UML started out as a conventionalised way for programmers to communicate software to other programmers in a pictorial form. In that sense it's just formalised napkin-scribbling - and as such it is very effective. You can draw a UML class diagram on a whiteboard and I can understand it without quibbling over notation.
But somewhere along the line someone got the idea that a drawing notation could somehow be a process in it's own right, or at least a formal part of a larger process. And that's just silly. UML diagrams are a fine way to illustrate books, and quite useful as a means for engineers to scribble ideas back and forth. But that's where it should have ended.
I can say at least three:
It takes a lot of time to keep the diagram reasonable and synchronized with the actual code. UML diagrams don't run, but require a lot of time. So they are good only if your organization size can manage them
You cannot represent every condition in a sequence diagram. It's impossible if you want to deliver. So state diagrams should convey basic facts, not all the possible outcomes.
Good UML software costs money and it takes some time to master properly.
So, I think UML is good as a complementary documentation role, and only if the size of your organization allows it.
Solutions... well, in the end, diagramming is just a way to convey high level information to another person, in space or time (e.g. could be you in some year time). Extreme Programming shifts the burden of information retrieval from dead tree to living brain. Of course, it assumes that the living brain never forgets, and never quits. Extreme programming uses redundancy to reduce the impact of such occurrences. In a large company, a strong layoff round could wipeout entire teams, so storing information into brains can be risky. On the other hand, large companies have human power to waste, hence the diagramming.
Also, as WDuffy points out, if you are a designer, and you have to communicate to a team of programmers what they have to implement, it's much easier to use a UML diagram. Of course, a small company with a small team has generally small goals, and you can organize people with a different style. A small company UMLing will only produce UML diagrams of their revolutionary product, and then it will be bankrupt.
UML is not good nor bad. It can be a good tool, but it must be used in the proper context.
Lacking features?
well, I found that UML is strongly aimed at an Object Oriented vision of the world. Our company mainly developed in python, with a strong focus on module level routines. Objects were lightweight data containers, but all the logic was done at the module level. It's difficult to properly model this implementation style at the UML level, unless you resort to some "hacks" in the terminology. I guess it's difficult to model in UML for functional or procedural languages.
Another thing I find annoying is the assumption of use case modeling as a diagram. My experience is that the best way to convey a use case is to write a short story or a short code tingling the feature you want to convey. The story should be short, one page maximum.
This approach has two advantages: if your story is a written prose, the Q/A team can read and test it easily. If your story is code, you can put it as a functional test and let it run during the night. A diagram does not satisfy any of these value added needs.
One issue with UML is due to its universality: things in UML cannot be always implemented directly in the target language, or some languages have capabilities that cannot be expressed in UML. So it can be better to know the implementation language beforehand, which restrain its universality.
See also the criticisms section on UML wikipedia page:
Standards bloat
Problems in learning and adopting
Cumulative Impedance/Impedance Mismatching
Dysfunctional interchange format
It's not Agile
What should have been the last word on UML was written by frustrated student "Candide Smith", well, really Eiffel author Bertrand Meyer.
Another disadvantage of UML is that it tends to overemphasize design, which can lead to 'analysis paralysis' (people over-analyze their problem) and feature creep (loosing sight of the actual problem). A UML design can only take you so far in solving a problem, and you have to be careful to jump into the code soon enough (but not sooner ;-).
UML is somewhat less applicable to the brave new world of loose typing and NoSQL databases. It has OO ideas of Class as a data structure rather than classification embed in it.
Another disadvantage, although not self-inflicted, is that it doesn't explicitly to facilitate abstraction. Everyone I know uses UML tools for more abstract modelling, but the way standards are written that is not obvious.
Another problem with UML (and big design up front in general) is that it's sometimes hard to anticipate all the nitty gritty implementation problems that you'll run into that may affect your design until you actually start implementing something. Granted, I'm a bioinformatics research programmer that works on small one-man projects, but I don't even believe in any design up front, at least for small projects. I believe in the following:
Make it work. (Just get a prototype up and running that has all the basic functionality, no matter how much it sucks. This forces you to see all the little nitty gritty details that might not come through in a formal analysis. Having an actual implementation of your idea makes it easier to see whether the idea was even really worth doing in the first place or whether it should be scrapped altogether.)
Make it right. (Only now, when you have a working prototype and you know that all the nitty gritty implementation problems are at least in principle solvable do you worry about good design. Refactor the heck out of it to follow good programming practices, reduce coupling, do proper error handling, yada yada yada.)
Make it fast. If it's application code, you'd better have proof that you've found the slow part. If it's generic library code, you'd better have good reason to believe that the piece of code could reasonably be the slow part in some use case for the library, i.e. don't optimize a function that noone would ever call in a loop.
For Class Diagrams in UML it only makes sense to use them if there is automated way to generate code directly from diagram. I have implemented such UML editor tool based on 4-tiers meta levels recommended by OMG (Object Management Group) and we had great success using UML in team of 5 devs over 2 years doing around 20-30 architectural iterations. The diagram was the root artifact of automated build chain making impact on hundreds of derived artifacts, APIs, generated Docs, DDLs, projects, tests etc.
So by itself UML in Class Diagrams part is great "programming" language if you actually do programming in it.
For Class Diagrams in UML if it is not translatable in automated way, then its fail.