Is there a tool that can generate diagrams (similar to Doxygen using Graphviz) but in the formats described by this paper: Lisp Looks Different
Program Style Distribution: Determine which programming style (Functional, OO, Imperative or Macro) dominates a software package, also to determine the size of complexity in each package.
Class Method Relation View: Visualizes the relationships between classes and methods (in Lisp, classes and methods are separated). The goal is to identify possible independent or loosely coupled components of the system.
Generic Concer View: Helps to identify and locate cross-cutting concerns associated with generic functions.
Class Type View: Helps to identify different types of classes, based on their structure, more precisely on the attributes to methods ratio.
tio
For the meaning of the colors and shapes, please refer to the document. It would be nice if there are equivalent tools for other languages as well.
Have you looked at Mondrian, which the paper cites was what was used to generate those diagrams?
More generally, have you looked at Moose, of which Mondrian is but a part?
I'm not sure I've seen one that produces diagrams exactly like those above, but there are quite a few more software visualization tools around.
Obvous first step: contact the paper's authors and ask what tools they used, and do they have any code they can share.
Related
I am trying to develop a simulation in OpenModelica of a flow that has a single substance that will be liquid or vapor. The Modelica.Media.Water models do have two phases, but are extremely complicated, and would be very hard to reproduce for a completely different substance.
I would like to find a simple example of a two phase medium that I can work from. There is a partial package TemplateMedium and a partial package PartialTwoPhaseMedium, but I don't see any examples of how to write a completely new Medium that can be in either of two phase.
If anyone can provide a simple example, or just a list of the minimum set of properties and equations that are required that would be extremely helpful as a starting point.
To address some of the question in comments:
I am just getting started on this model, so I am trying to understand the details of how the Media model is constructed, and what my specifics are included in the model versus what has to be added for each new media. I working with propylene, so there is good data available. This is one of the media that is included in CoolProp, so being able to use ExternalMedia and CoolProp would be very useful, but I believe that these are not yet working with OpenModelica, from a number of comments and bug reports.
Generally, your medium model can be written in Modelica or you can reuse an existing external library. Writing good medium models is a lot of work, so reusing existing libraries is usually a good idea. This is the approach taken by ExternalMedia (open source) or TILMedia (commercial).
If you are interested in an open-source workflow, ExternalMedia in combination with Coolprop is a reasonable decision. All three projects OpenModelica, ExternalMedia and CoolProp accept contributions from the community, so maybe you should help improving these instead of writing your own library. There is a lot of work going on already, I am unsure of the current status. Writing qualified bug reports (including steps to reproduce the problem) is also a very welcome way to contribute.
For some applications, it might be good to have the Medium model directly in Modelica. This is the approach taken by Modelica.Media (obviously), HelmholtzMedia and the commercial media libraries from XRG or Modelon (not 100% sure about that). There are some more implementations, but these are neither open source nor commercial, only information are e.g. conference papers.
The examples you can look at include the R134a medium from the MSL or the code from the HelmholtzMedia library.
Also, looking at the ExternalMedia implementation might help.
For fluids that cannot change phase, there are some good examples in the Annex60 library.
As you have a pure substance that can change phase, your new medium should extend from PartialTwoPhaseMedium.
PartialTwoPhaseMedium is partial, defining only what functions are there, but (mostly) not the algorithms of the functions.
You will have to write an algorithm for each and every function that is available in the interface and does not have an algorithm in order to be fully compatible.
For a start, you should implement at least one of the setState funtions, e.g. the setState_ph function.
Then later, implement at least one setSat function and the BaseProperties.
If you implement your own medium, you also have the choice of how to model it: Using the full multiparameter Helmholtz energy equation of state, a simpler equation of state like Peng-Robinson or other cubic EoS, some polynomials or splines, table-based methods like TTSE or SBTL and probably many more options.
I was self-studying various UML diagrams and I understood most of them except for Class Diagram and Object Diagram.
I can not get my head around how they wil be converted into code.
The trick that I learnt is this: all nouns become classes and verbs become methods of the classes.
All good till there but after that, how is the diagram converted into code?
Have a look at a diagram here that I got from the internet:
So, assuming that the language is Java, how will you code a software based on this?
A UML diagram solely describes the internal architecture of a given piece of software.
The information contained in your UML diagram is therefore:
What classes are contained
What methods and properties do they contain
How do they relate to each other
Each block with a header ("Train" for instance ) represents a class, listing its properties and methods.
As such the UML diagram does not state anything about a GUI or how the user interacts with the software. It is up to you or a UI/UX designer to create an interface you can implement, that uses the functionality outlined in this UML diagram.
You can think of a UML diagram as a description of the architecture of a piece of software, that is very shallow but is well suited for an overview of the project.
It is not a recipe.
I hope this was useful to you.
When you have a class diagram, you have a representation of the classes (and its members) that you should have in code.
So, your noun/verb analysis (what you were talking about), has already been done when you have a class diagram.
A class diagram is just a visual representation of your classes, converting them to code is just easy if you know the syntax of the language that you want to use.
I need to define simple classes and interfaces (Ex. IClassInterface) in a language neutral way and then use a variety of code generation tools to generate the code files in a variety of languages such as C#, Java, etc... Does anyone know of a standard; ratified or otherwise; that I can use for the neutral representation. I know UML is often used for creating diagrams, but I am actually looking for something that can easily be parsed, extended, and used to drive other automated processes. Maybe this is actually possible with UML, although I am not sure what the markup language might look like if one exists.
I could create my own definition using XML or something similar, but I would prefer to avoid reinventing the wheel if possible.
UML
I think you might be looking for XMI (XML Metadata Interchange)
There is IDL (for example, Google's protocol buffers), and WSDL, which can be used to produce interfaces and classes by many web service frameworks. (You typically do not have to use the generated code as an actual webservice.)
The wikipedia entry for IDL lists a number of implementations of IDL. Although IDL is mainly for describing interfaces, some implementations also use it to describe objects (e.g. Microsoft IDL.)
Both of those frameworks deal with meta-model:
XText (Eclipse)
MPS (JetBrain)
Do you have example of practical applications based on meta-model transformation with those tools?
We created whole bug tracker using MPS. Code generation is not the goal but mean to get some executable code. The goal is to give a tool to developer that allows creating DSLs with minimum effort.
Cool thing about MPS is that it also provides you with an IDE for your language. And different DSLs you create are compatible, i.e. you can create DSL that extends Java with closures and another DSL that enables external methods, and these extensions will work together.
They are different in term of document storing the metamodel.
Regarding XText, this article illustrates one usage, when it comes to y create your own programming languages and domain-specific languages (DSLs).
Once you have a language, you want to process it and this means usually to transform your model into another representation.
The facility responsible for this transformation is called generator and consists of a bunch of transformation templates (e.G. XPand) and some code executing them. On some event, the model is read in and the transformations are applied to produce code.
Example of such a model transformation:
dot3zest, which comes with a DOT to Zest interpreter (which now uses the Xtext switch API generated for the DOT grammar) is support for ad-hoc DOT edge definitions.
Regarding MPS, you have here a serie of practical examples,
like this code generation to GPL such as Java, C#, C++ or XML:
(source: googlecode.com)
I think the main usage of XText is firstly to create a DSL from the grammer you defined and an eclipse workbench auto-generated for you. Secondly, it can transform the scrpit written in your DSL into java. The built-in expressions from XText2 is a plus.
The framework gives you a free IDE to support your writing DSL you created. And the DSL is the ulimate product to provide. It can be used to abstract the rules and logics from the real world. For example, in our project, the product config rule. Only specialist knows them, so they write some in the DSL you create.
Maybe its because I've been coding around two semesters now, but the major stumbling block that I'm having at this point is converting the professor's project description and requirements to actual code. Since I'm currently in Algorithms 101, I basically do a bottom-up process, starting with a blank whiteboard and draw out the object and method interactions, then translate that into classes and code.
But now the prof has tossed interfaces and abstract classes into the mix. Intellectually, I can recognize how they work, but am stubbing my toes figuring out how to use these new tools with the current project (simulating a web server).
In my professors own words, mapping the abstract description to Java code is the real trick. So what steps are best used to go from English (or whatever your language is) to computer code? How do you decide where and when to create an interface, or use an abstract class?
So what steps are best used to go from English (or whatever your language is) to computer code?
Experience is what teaches you how to do this. If it's not coming naturally yet (and don't feel bad if it doesn't, because it takes a long time!), there are some questions you can ask yourself:
What are the main concepts of the system? How are they related to each other? If I was describing this to someone else, what words and phrases would I use? These thoughts will help you decide what classes are useful to think about.
What sorts of behaviors do these things have? Are there natural dependencies between them? (For example, a LineItem isn't relevant or meaningful without the context of an Order, nor is an Engine much use without a Car.) How do the behaviors affect the state of the other objects? Do they communicate with each other, and if so, in what way? These thoughts will help you develop the public interfaces of your classes.
That's just the tip of the iceberg, of course. For more about this thought process in general, see Eric Evans's excellent book, Domain-Driven Design.
How do you decide where and when to create an interface, or use an abstract class?
There's no hard and fast prescriptions; again, experience is the best guide here. That said, there's certainly some rules of thumb you can follow:
If several unrelated or significantly different object types all provide the same kind of functionality, use an interface. For example, if the Steerable interface has a Steer(Vector bearing) method, there may be lots of different things that can be steered: Boats, Airplanes, CargoShips, Cars, et cetera. These are completely unrelated things. But they all share the common interface of being able to be steered.
In general, try to favor an interface instead of an abstract base class. This way you can define a single implementation which implements N interfaces. In the case of Java, you can only have one abstract base class, so you're locked into a particular inheritance hierarchy once you say that a class inherits from another one.
Whenever you don't need implementation from a base class, definitely favor an interface over an abstract base class. This would also be handy if you're operating in a language where inheritance doesn't apply. For example, in C#, you can't have a struct inherit from a base class.
In general...
Read a lot of other people's code. Open source projects are great for that. Respect their licenses though.
You'll never get it perfect. It's an iterative process. Don't be discouraged if you don't get it right.
Practice. Practice. Practice.
Research often. Keep tackling more and more challenging projects / designs. Even if there are easy ones around.
There is no magic bullet, or algorithm for good design.
Nowadays I jump in with a design I believe is decent and work from that.
When the time is right I'll implement understanding the result will have to refactored ( rewritten ) sooner rather than later.
Give this project your best shot, keep an eye out for your mistakes and how things should've been done after you get back your results.
Keep doing this, and you'll be fine.
What you should really do is code from the top-down, not from the bottom-up. Write your main function as clearly and concisely as you can using APIs that you have not yet created as if they already existed. Then, you can implement those APIs in similar fashion, until you have functions that are only a few lines long. If you code from the bottom-up, you will likely create a whole lot of stuff that you don't actually need.
In terms of when to create an interface... pretty much everything should be an interface. When you use APIs that don't yet exist, assume that every concrete class is an implementation of some interface, and use a declared type that is indicative of that interface. Your inheritance should be done solely with interfaces. Only create concrete classes at the very bottom when you are providing an implementation. I would suggest avoiding abstract classes and just using delegation, although abstract classes are also reasonable when two different implementations differ only slightly and have several functions that have a common implementation. For example, if your interface allows one to iterate over elements and also provides a sum function, the sum function is a trivial to implement in terms of the iteration function, so that would be a reasonable use of an abstract class. An alternative would be to use the decorator pattern in that case.
You might also find the Google Techtalk "How to Design a Good API and Why it Matters" to be helpful in this regard. You might also be interested in reading some of my own software design observations.
Also, for the coming future, you can keep in pipeline to read the basics on domain driven design to align yourself to the real world scenarios - it gives a solid foundation for requirements mapping to the real classes.