Hot answers tagged

59

Yes, UML CASE tools were one of the hot items of the 90s... and then failed to deliver. The fundamental reason for this is that UML (or most any other kinds of) diagrams help to understand the problem and/or the program solving it only insofar the diagram is abstracting away the implementation details of the actual code. Thus (for any nontrivial piece of ...


43

Never. Heck, it's been years since I last created any UML. Line diagrams on whiteboards and scraps of paper don't count. In fact, we just removed the sole UML question from the guide we use during interviews, because none of us really cared about the answers.


34

So when I was at uni (a while ago now), I was told that UML was the future, UML will replace programming and we'll just generate code from diagrams etc. They were wrong. That will happen about the time people abandon speech and go back to cave painting. Real-world problems, and the programs that solve them, have an essential complexity that cannot be ...


18

Your problem is a lack of communication between you and your managers/stakeholders. They don't understand the problems that making frequent changes can cause - even if you have an agile process in place. But equally the developers don't understand the need that the program is designed to solve or the business process as well as you should. Why do I say ...


16

That looks like SQLite's syntax diagrams. Their FAQ says: How are the syntax diagrams (a.k.a. "railroad" diagrams) for SQLite generated? The answer is a link to this wiki page on "Generating Syntax Diagrams Using Tk". The wiki links to this Tcl source code for generating the diagrams.


12

I use just enough UML (in terms of both the types of diagrams and the content of the information in the diagram) to get my point across to allow myself or someone else to implement the system or subsystem. And the only reason I use UML is because its a widely known set of symbols that each mean something very specific, so there's no ambiguity - any software ...


12

When it comes to architecture it always depends. When building a simple throw away application you document way less than when building a large service oriented architecture. When building an application in an agile organisation you document less then when building an application in a highly governed waterfall organisation. When it comes to determining what ...


12

The more appropriate UML diagram to depict a platform's architecture is a component diagram. If you want to go a level lower, then you'd also need to draw one or more package diagrams, and perhaps even a deployment diagram. The diagram you linked to is not a UML diagram, it's a "marchitecture / marketecture" diagram. It's not really supposed to be ...


10

UML: Sequence Diagram Tutorial The data is included as the parameters within the messages. For example the instance buyersBank of the Bank class takes an accountNumber and returns the balance for the buyersBank instance. Update: I have highlighed the key points from the OMG specification. pg 491-494 Asynchronous Messages have an open arrow head. ...


10

Ironically, UML is supposed to be flexible. In the real world, it is not supposed to be a pedantic exercise in doing it one right way. It is about effectively communicating and documenting a system/process/idea. To answer your question, I'm with the others. I've never fully utilized full-on, formal UML.


8

This question is too large to be answered exactly point by point. There are books about design, and other books about user experience, which explain in every detail how to make the software, consumer products, books, advertisements, toys for babies more attractive to the target audience. Actually, your question is similar to: I'm a designer, I have some ...


8

NO The legend was based on the failed assumption that writing: class ClassName extends SomeThing { } ...it's hard and needs automation. You still may find the occasional believer, or crowds of believers. But that's how it goes with religions and cults.


8

Multiple endpoints are acceptable within an activity diagram. Here's a number of sites backing up that assertion. This DeveloperWorks article every activity diagram should have at least one final state symbol with "at least one" implying that multiples are allowed. This snippet from the book Java Server Programming on page 1551 An ...


6

I used UML very regularly for about four years for a product that generated all (most) of its code skeletons from Rational Rose. The last five years there have been more of "boxes and arrows" mostly invented on the spot and usually enough to get the general idea across. Formally correct UML only a few times during this time.


6

Been there, didn't find it too useful. Generally the diagrams specific enough to generate some code from them, mainly class diagram, don't add much in the way of actually understanding the program and you can't generate code from the overview diagrams like use case or overview-level activity that are crucial for documentation. One diagram that is useful for ...


6

The best documentation I've been given to implement was drawn as wireframes with notes. Each page of the documentation was one wireframe with as many notes as necessary. Each state of any element that needed further explanation spawned another page. For example, a standard drop-down is obvious, but an expanding menu would get notes about sliding effects ...


6

That is a syntax diagram. I think I first saw them in Grogono's "Programming in Pascal", from 1980, but they were used in Wirth's 1973 report on PASCAL.


6

That is a standard component diagram that is found in UML. I've heard some people call them a "lollipop diagram" because the sticks with small circles on the ends to represent a provided interface look like lollipops or a "ball and socket diagram" because of the balls and sockets used to represent provided and needed interfaces


5

I'm not an expert on diagramming, but I like using shapes with multiple points to specify an alternative path, such as Diamonds or Triangles


5

An ER Diagram is out there to visualize a design, which was made to accomplish a certain job. Understand what the job is first, then ask questions to the diagram. "How is an order stored?", "How do I retrieve user information", "How can I tell which user ordered a certain product between these intervals and with these options?". Such questions might help ...


5

Heard of Nassi-Shneiderman diagrams, although I don't use them myself. I can't help posting a link to the rejection letter that Nassi and Shneiderman received from Communications of the ACM when they first proposed the diagram: http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejection_letter.html


5

I would focus on use-cases and user-stories. I could document them, perhaps in a wiki, and give each one an ID (like UC00001). Then when I wrote unit tests and/or integration tests, I'd label them with the use case they inform. Then when I get to two unit tests that can't both pass because they're mutually exclusive, I'd throw those two use cases back at ...


5

All the documents you described will work to describe your system from the perspectives they capture. A class diagram is to show the structure of your project without needing to see the code, the fact your code is very structured is irrelevant. A DFD does not need to have a data storage listed, not all systems store data, but its still important to map how ...


4

Gernerally speaking if minor changes required updates to UML diagrams then I would consider the diagrams to be too detailed. I have found the best use of UML diagrams is to succinctly convey the design of a system. It's incredibly beenficial to be able to look at a class diagram or a deployment diagram and get a feel for the software compared to trawling ...


4

We've never used them. Edit Yes, I (we) have heard of them. Thanks for asking! :-) Seriously, we just don't use them. We ususally keep the diagraming to simple flow diagrams which are generally easier to read and understand.


4

First, define use cases for the transaction you are modeling. Define versions of the use case for happy path, and each of the rollback scenarios you wish to model. Each of these use case variations can be presented as a separate sequence diagram. Consider a very simple transaction -- client updates two tables, T1 and T2. Both updates need to succeed, or ...


4

Classic UML Diagram References Two great references for UML and its many diagram types include Martin Fowler's UML Distilled in which each diagram is described in much the same way as you might expect a pattern to be described (it is named, described, the forces on it are enumerated, and the applicability is identified). A more comprehensive reference is ...


4

Well, it depends on the view the diagram belongs too. If the diagram is part of the Logical View or the Use Case View, it should not dive into the very details of the implementation because this view is concerned with the functionality provided to end users and may be used communicate the architecture to end users, domain experts and others who do not care ...


4

The level of abstraction provided by Entity Relationship Diagrams created with modeling tools, the entity model provided by EF, and UML class diagrams is almost the same. When I create my POCO entities I generally put them in my Model project with my other domain classes, and so a class diagram of the domain model contains the same POCO entities found in the ...


3

from UML Basics The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur... so yes, it is perfectly valid to represent the sequence step 'ask the user for something'; each arrow does not necessarily correspond to one specific message



Only top voted, non community-wiki answers of a minimum length are eligible