Tag Info

Hot answers tagged

18

These functions both have to do with collisions, but what they do is very different, so giving them names that more clearly describe what they actually do will make it easier for future developers to understand the difference without having to look at the logic inside. The method that checks if the object is colliding with another object could be called ...


10

Exactly those classes which are necessary to understand the aspect of the system which that particular class diagram depicts. It could be the entire domain model, or all classes that make up the external API of a particular layer or subsystem, or whatever you think is important. But note that class diagrams are not the only type of diagram, nor the most ...


10

In a class diagram, you don't show the act of instantiation. That is something that a sequence or communication diagram would show. Class diagrams show the static structure of a system. If a class A "depends on" a class B, then you could look at the association and dependency relationships. Dependency is the weaker of the two and is usually used if the ...


9

It makes no sense to say that a class can implement an interface. Either it does or it doesn't, and that's determined as the code is written. Specific instances (users) can't make that decision for themselves, although they can set an IsAdministrator flag instead. If the IsAdministrator flag is insufficient, then (as @superM said) the design you want is ...


9

No, it's much faster to write code than to draw diagrams on a computer. To generate a Java class from a diagram you would have to draw the diagram, and then type in most of the code anyway. Sure, you might not have to type get/set methods, but Lombok does a better job of solving that problem. For example, it's much easier to simply type "class X ...


9

The three links Association, Aggregation and Composition form a kind of scale on how closely two classes are related to each other. On the one end of the scale, there is Association, where objects of the two classes can know about each other, but they do not affect each others lifetime. The objects can exist independently and which class A object knows ...


7

I think the last few years have shown a preference for using class diagrams to document existing code as opposed to generating code. Diagrams give the reader of the code a quick look at the overall structure of the systems in terms of its classes and relationships. Of course, the successful use of diagrams is dependent on the diagrams being kept in sync ...


7

A server or database doesn't go into a class diagram. A class diagram, at the highest level, shows the classes and their relationships with each other. Adding more detail would first indicate public members, and even more detail would indicate private members of the class. You may show classes that interact with the database (your data model, as an example), ...


6

You can add an open arrow head to the composition or aggregation line, pointing toward the child to indicate directionality in the relationship. If the child knows about the parent, then simply don't include an arrow at all. I believe this works, because composition is a stronger form of an association link. The diamond indicates a composition or aggregation ...


5

Show them if and only if they help understanding whatever aspect of the system that diagram is supposed to show. UML is a tool for communication. If you can't say what a diagram communicates, you shouldn't have that diagram.


5

In order to better discuss the image, I annotated your image with some numbers. Hopefully this will help me be more clear in my writing. There are really three types of lines used here - association (1), composition (4->2), and inheritance (3). A solid line connecting two classes, such as between Client and BookComponent is simply an association ...


5

You can draw an UML sequence diagram out of this easily, but a class diagramm won't tell you much, except for some logical errors. Let's draw up a sequence diagram first: Now, let's remove Factory for a moment, what do we have? Hmm, are we sure we're missing something? Basically all your Factory module does is, it shortens a namespace into its last ...


5

What you want is a Decorator. An Administrator would be a subclass of User, and its primary member attribute would be a User object. Thus a Student Adminstrator would be an Administrator containing a Student (which is a subclass of User, right? The Administrator-specific attributes are set in the Adminstrator class, with the User methods passed through ...


4

I annotate the line with "*..*". For 1-to-many it would be "1..*". It's a standard way of denoting multiplicity. http://en.wikipedia.org/wiki/Cardinality_%28data_modeling%29 http://www.agilemodeling.com/artifacts/classDiagram.htm


4

Isn't using an interface for this type correct? Using an interface in this case would work, but you would have to duplicate behavior between Directory and File (like having a maximum of 256 chars for the name). You would be better off making FileSystemElement an abstract class (assuming your language of choice supports it) Which also answers your second ...


4

Subclasses and subtypes bring a lot of baggage with them in the form of inheritence and the desirabality of supporting the Liskov Substitution Principle. It would be pretty foolish to start creating subclasses simply to support an arbitrary naming convention. It's unclear why you would need separate classes for what you are describing. How is StandLeft ...


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 ...


4

Your external API (the connection to the content management system) is not a class, it's an interface. As illustrated in this Stack Overflow question, it would look something like this:


4

Not quite sure if I understand your question. I think you just have a composition relationship of system to system (see diagram). A system can backup another system. I don't think you need to look at multiple inheritance here. It's possible to overdo things with inheritance. Try to use composition instead when you can.


4

According to Wikipedia and also according to the UML reference , UML does not contain a diagram type called "inheritance diagram". That does not mean some tool vendors invented their own definition of what an inheritance diagram should be (like this one). When using UML means, to display just an inheritance tree, IMHO the most obvious solution would be to ...


4

[Disclaimer: I'm not a UML jockey, so don't take my word for it.] I think, it would look like this. Some details omitted for brevity.


3

Normally, you have two classes in your diagram: Order and Product. As an order usually means that the customer has ordered 1 or more (1..*) products, you model this by creating an association from the class Order to the class Product. This coincides with adding a collection of Product instances to your Order instances, i.e. most code generators will give ...


3

First point: this is fairly non-trivial. Second point: the fact that the Java environment makes the Java compiler directly available will help a lot in implementing this. I believe you should be able to collect most (all?) the information you need by walking the AST with the compiler tree API. At least from the looks of things, the part you'll care the most ...


3

I believe the term you are looking for is Software Architect. Here's Wikipedia's definition of Software Architect And here's SEI's definition of Software Architect However, the criteria you provided are a bit nebulous. making the right choice of language/paradigm It's pretty rare that a project is able to swap out its existing language or overall ...


3

The closest I can think of is a usage relationship. Possible stereotypes: "use", "call", "create", "instantiate", "send". SomeDAO ---<<use>>---> SomeEntity


3

I'd say that there is nothing wrong with this. Method overloading is a pretty standard practice, for multiple reasons. If you have the same exact functionality, just for two different series of parameters, then using the same exact name makes perfect sense, and it also helps to clarify that the parameter list should be roughly the only real difference ...


3

I work at a Fortune 100 company as a Senior Architect. We're about as uptight about UML as you find in the industry, and we don't worry about these kinds of things. Basically, if including an external system (typically using a separate package notation) helps explain something, then include it. If it is just there for some insignificant corner case that ...


3

ID is a way for the database to connect a room to an event, there's no need to duplicate that in the class. So I'd definitely choose private Room room;. This will create a much better object model than having a bunch of IDs. As to your other question, I'd say it depends on your needs whether you need a two-way reference or not. From modeling point of view ...


2

There is a special stereotype for such dependency. Class INSTANTIATES Class2, if it creates its instances. Exists in UML standard. ( I checked 2.4.1 - contemporary and 2.5 - the next one.)


2

I agree with @Thomas Owens that class diagrams in UML are not meant to show instances in general. However, I must add that UML does provide mechanisms to depict instantiation: the InstanceSpecification element provides a way to model instances, such as alpha in your example. the dependency notation (a dashed arrow with plain arrowhead), flowing from the ...



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