I have a class diagram which has a dictionary (in python terms) as an attribute. This is the basic structure:
serverEntry = { creditCardObj1 : accountBalance1, creditCardobj2 : accountBalance2, ...}
To clarify, creditCardObj1 is an instance of a class CreditCard while accountBalance1 is an integer value and similarly for the other entries in the dictionary.
I read that in Java, it is called HashMap. In any case, I would like to implement it in my UML class diagram. Any tips on how to do that. I am using Visio 2007 so it would even more helpful if someone can explain in terms of that.
I won't put much effort into this, as another answer has been chosen already. That answer does not cover the closest thing in UML to a HashMap: the qualifier. It is drawn as a rectangle between a class and an association. Inside the rectangle is a name and a type. What it means is that given an instance of that type, the association will yield some number of instances of things on the other end of the association. That number of instances is specified with a multiplicity.
For your purposes, you would put creditCard: CreditCard inside the qualifier rectangle, and Integer on the other end of the association, with a multiplicity of 1.
I believe that this question is more about UML than about the programming language. Thus, please allow me to use the language I feel more comfortable in.
C# calls it Dictionary too, Dictionary<string, T> for example with a string for the HashKey. The UML Class Diagram in Visual Studio (I am using the Community Edition of VS 2015 here) is fortunately close enough to code so that the UML Model basically is the language's meta-model and the diagram is just a different view to the real code.
This comes in handy because real programming problems - like the one you asked for - can be addressed directly in the diagram. (Also: no extra code generation or additional parsing necessary to get or maintain the diagram).
I like the way Visual Studio solved this. They offer two options, one that is focussed more on the technicalities (show as Association)
and one that is focussed more on the domain (show as Collection Association).
I am usually using the first one only if I need the diagram to emphasize that the Dictionary class is involved, in every other case the second option is my preferred option.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
More specifically, how do you model a functional program, or one developed using the Functional Style (without classes) using a diagram, and not textual representation.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
Most of the other diagram types (Use case diagrams, activity diagrams, sequence diagrams...) are perfectly applicable for a purely functional programming style. Even class diagrams could still be useful, if you simply don't use attributes and associations and interpret "class" as "collection of related functions".
Functional programmers have their own version of UML, it is called Category Theory.
(There is a certain truth to this, but it is meant to be read with a touch of humour).
UML is a compendium of different types of modeling. If you are talking about the Object Diagram (Class Diagram), well you are not going to find anything that fits your desired use. But if you are talking about an Interaction Diagram (Activity Diagram) or Requirements Diagram (Use Case Diagram), of course they will help you and are part of the UML base.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
I realize this is an old thread but I'm not understanding the issue here.
A class is merely an abstraction of a concept that ties the functionality of it's methods together in a more human friendly way. For instance, the class WaveGenerator might include the methods Sine, Sawtooth and SquareWave. All three methods are clearly related to the class Generator. However, all three are also stateless. If designed correctly, they don't need to store state information outside of the method. This makes them stateless objects which - if I understand correctly - makes them immutable functions which are a core concept in the functional paradigm.
From a conceptual perspective I don't see any difference between
let Envelope Sine = ...
and
let Envelope Generator.Sine = ...
other than the fact that the latter might provide greater insight into the purpose of the function.
UML is an object approach because at graphical level you can not define functional modeling. A trick is to directly add constraints and notes at model and not in the diagram levels. I mean that you can write a full functional documentation on each model element directly in the metamodel and only display an object view using the UML editor.
This is maybe stupid but I found this demo in French language exactly on the same subject and using EclipseUML Omondo :
OCL and UML 2.2 (demo in French language 3mn): http://www.download-omondo.com/regle_ocl.swf
This demo explains how to add constraints directly on methods at metamodel level. The interesting point of this demo is that using a single model for the entire project allows to be flexible enough to extend traditional UML and avoid SysML, BPMN, DSL additionals models because all information is built on the top of the UML 2.2 metamodel. I don't know if it will be a success but this initiative is very interesting because reduce modeling complexity and open new frontiers !!
I haven't actually tried modelling a large system in UML and then going for a functional implementation, but I don't see why it shouldn't work.
Assuming the implementation was going to be Haskell, I would start by defining the types and their relationships using a class diagram. Allocate functions to classes by their main argument, but bear in mind that this is just an artefact of UML. If it was easier to create a fictional singleton object just to hold all the functions, that would be fine too. If the application needs state then I would have no problem with modelling that in a state chart or sequence diagram. If I needed a custom monad for application-specific sequencing semantics then that might become a stereotype; the goal would be to describe what the application does in domain terms.
The main point is that UML could be used to model a program for functional implementation. You have to keep in mind a mapping to the implementation (and it wouldn't hurt to document it), and the fit is far from exact. But it could be done, and it might even add value.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.
I have been asked on a school project to show the UML diagrams I used - if I did -
to realise the project. But the project I was working on was in C and has been functionally programmed.
Thus I want to justify that using a class diagram when not using object oriented langage was pointless, but I am afraid that this is not true and haven't been able to confirm this hypothesis. It seems pointless to me but I'd like to know if it is the case, since may be thinking the code in a OOP way could help understanding how it works.
Is there any benefits regarding the way to think and build a functionnal program in using a class diagram ?
Of course, yes. The use of class diagram is not so extensive as in classical OOP, where very often having a class diagram means only automatic coding routine is left, but still it is very useful for:
Planning of data structures (We still should understand data and their interconnections)
Creating the hierarchy of methods. (Grouping of methods up to their data and tasks)
Tying together methods and some special data. (What method works with what classes of data)
If the language supports OOP, you can use a class diagram translating it into code.
And even if you haven't any OOP features supported, you can always profit from at least the first point.
Really, the only possible use of the class diagram, that is forbidden by functional programming, is creation of methods with side effects on instances. And that is not much connected to the class diagrams. On the contrary, class diagrams are not mentioned for modelling of that. Rather the Composite Structure Diagrams are.
There is a point in creating a diagram.
Think of a struct as a class.
A struct maybe contains other structs.
So you have a relation from one type to another. With UML you can model the relationships of your structs and this is really helpful in larger projects.
If you dedicate a file.c to a struct you could think of a real class, if every function of the file.c takes an instance of the struct as parameter.
If you are going to document FP with OO you will deviate your FP to OO. That might not be the worst, but definitely class diagrams in FP are pointless.
However, UML has more to offer than class diagrams. You will definitely benefit from state diagrams. Eventually from timing diagrams. And in a limited sense from sequence diagrams. The latter would only make sense if you can show "information tokens" equivalent to messages used in SDs.
Finally a higher level picture could be sketched using activity diagrams.
I am asking about Algorithms that would be useful in Querying the Semantic web DB to get all the related RDFs to an original Object.
i.e If the original Object is the movie "inception", I want an algorithm to build queries to get the RDFs of the cast of the movie, the studio, the country ....etc so that I can build a relationship graph.
The most close example is the answer to this question , Especially this class , I wan similar algorithms or maybe titles to search in order to produce such an algorithm, I am thinking maybe some modifications on graph traversing algorithms can work, but I'm not sure.
NOTE: My project is in ASP.NET. So, it would help to use Exisiting .NET libraries.
You should be able to do a simple breadth-first-search to get all the objects that are a certain distance away from a given node.
You'll need to know something about the schema because some neighboring nodes are more meaningful than others. For example, in Freebase, we have intermediate nodes that link a film to an actor and a role. You need to know to go 2-ply deep to get at the actor and the role because just saying that the film is related to the intermediate nodes is not very interesting.
Did you take a look at "property paths"?
Property Paths give a more succinct way to write parts of basic graph
patterns and also extend matching of triple pattern to arbitrary
length paths. Property paths do not invalidate or change any existing
SPARQL query.
Triple stores and SPARQL engines such as OWLIM and AllegroGraph support them.
I need to make some drawing to explain programming logic at the whiteboard.
I often need to manipulate collections of objects.
Which symbol can I use to visually show a collection ?
I wish to have an example for better understanding, because I was told to use aggregation/composition in UML style, but I don't really see it. For instance, if I want to represent a collection of Object ABC...
Do you use an established symbology, or do you just ad hoc your drawings? Usually, I'd go for an entity-relationship diagram with a crow's-foot going from the collection entity to the contained objects, UML, or whatever the people I'm talking to understand. That last part is usually the key...!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
More specifically, how do you model a functional program, or one developed using the Functional Style (without classes) using a diagram, and not textual representation.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
Most of the other diagram types (Use case diagrams, activity diagrams, sequence diagrams...) are perfectly applicable for a purely functional programming style. Even class diagrams could still be useful, if you simply don't use attributes and associations and interpret "class" as "collection of related functions".
Functional programmers have their own version of UML, it is called Category Theory.
(There is a certain truth to this, but it is meant to be read with a touch of humour).
UML is a compendium of different types of modeling. If you are talking about the Object Diagram (Class Diagram), well you are not going to find anything that fits your desired use. But if you are talking about an Interaction Diagram (Activity Diagram) or Requirements Diagram (Use Case Diagram), of course they will help you and are part of the UML base.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
I realize this is an old thread but I'm not understanding the issue here.
A class is merely an abstraction of a concept that ties the functionality of it's methods together in a more human friendly way. For instance, the class WaveGenerator might include the methods Sine, Sawtooth and SquareWave. All three methods are clearly related to the class Generator. However, all three are also stateless. If designed correctly, they don't need to store state information outside of the method. This makes them stateless objects which - if I understand correctly - makes them immutable functions which are a core concept in the functional paradigm.
From a conceptual perspective I don't see any difference between
let Envelope Sine = ...
and
let Envelope Generator.Sine = ...
other than the fact that the latter might provide greater insight into the purpose of the function.
UML is an object approach because at graphical level you can not define functional modeling. A trick is to directly add constraints and notes at model and not in the diagram levels. I mean that you can write a full functional documentation on each model element directly in the metamodel and only display an object view using the UML editor.
This is maybe stupid but I found this demo in French language exactly on the same subject and using EclipseUML Omondo :
OCL and UML 2.2 (demo in French language 3mn): http://www.download-omondo.com/regle_ocl.swf
This demo explains how to add constraints directly on methods at metamodel level. The interesting point of this demo is that using a single model for the entire project allows to be flexible enough to extend traditional UML and avoid SysML, BPMN, DSL additionals models because all information is built on the top of the UML 2.2 metamodel. I don't know if it will be a success but this initiative is very interesting because reduce modeling complexity and open new frontiers !!
I haven't actually tried modelling a large system in UML and then going for a functional implementation, but I don't see why it shouldn't work.
Assuming the implementation was going to be Haskell, I would start by defining the types and their relationships using a class diagram. Allocate functions to classes by their main argument, but bear in mind that this is just an artefact of UML. If it was easier to create a fictional singleton object just to hold all the functions, that would be fine too. If the application needs state then I would have no problem with modelling that in a state chart or sequence diagram. If I needed a custom monad for application-specific sequencing semantics then that might become a stereotype; the goal would be to describe what the application does in domain terms.
The main point is that UML could be used to model a program for functional implementation. You have to keep in mind a mapping to the implementation (and it wouldn't hurt to document it), and the fit is far from exact. But it could be done, and it might even add value.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.