Im currently reading the laymans theory behind the job shop problem written in OR TOOLS. I have come by an annotation that I do not understand, hopefully somehow here could help me.
http://www.lia.disi.unibo.it/Staff/MicheleLombardi/or-tools-doc/user_manual/manual/ls/jobshop_def_data.html
In the above link, step 6.1.3 the notation l is introduced as a part of the conjunctive arcs, can anyone see what this l is a notation for? It isn't in the theory "they" introduce and I can't seem to link it to general job scheduling or mixed graph theory.
Kind regards
I'm at the stage where I have to draw the UML diagram for my software design documentation.
A sample UML diagram snippet that my professor provided look like this:
As you can see there are three handlers in there. However, for my project, I have about 60 use cases/events. And my professor have specifically said to "INCLUDE EVERYTHING".
So does this mean I have to clutter my UML diagram with 60 something handler boxes?
I'm not sure what the common practice on this is. I have tried to reach out to my professor multiple times but I think he might be really busy in a time like this.
Any advice is greatly appreciated as this is due in couple days!
I have been looking around for this for ages, but could not find any way to link a UML note to an operation of a class or to display the provided implementation in the specification of an operation. The idea is illustrated in the picture.
I tried to add the implementation to the operation, but I don't manage to make it appear in my diagram. I also tried making a note and then connecting it to the method, but this leads to unclear floating line-ends.
If anybody could let me know how this could be achieved with visual paradigm or let me know it is impossible, that would be nice.
Thanks in advance.
I have no idea how or whether this is possible with VP (I know for sure that you can't do it with Enterprise Architect which is pretty much UML2.x compliant). But you could hook the link near the position in the appropriate compartment (EA also has a feature to lock the connector at a certain position of an element).
Edit I have looked into Superstructures 2.5:
Comment [Class]
Description
A Comment is a textual annotation that can be attached to a set of Elements.
So actually what you want to do is not UML compliant. A comment can only be attached to an element. Attributes/operations are not UML elements.
I'm trying to find some good reads to clarify this but I'm unable to find it (or maybe I just don't know how to search this properly).
What I'm trying to find is, considering that you have an application that:
interacts with a db;
interacts with Mainframe;
interacts with external providers;
etc...
What is the best approach to draw a diagram that represents this in a functional view rather then in a more techinical view? What kind of books, articles, websites can help me to get a clearer understanding of which approach should I follow?
Thanks in advance.
Well,
First thing that you should ask yourself:
Why I am drawing or want to draw a diagram about this?
Maybe you answer is :
To understand important/significiant communication between those elements.
Then we can say:
Oh maybe sequence diagram may help...
Buy may be you answer is:
Oh I am worry about topology of system components. How those things
will be deployed?
Then we can say that:
Oh, may be deployment diagram will help you...Draw one.
So depends on "context"...
UML diagrams will not solve your problems. They help you to understand tricky and hard part of your system and think about alternative solutions by visual modeling.
Modeling is not "self masturbating" activity. It is like "group sex". You will get most benefit when you do with others...
So the main problem is not to draw which diagram... The main problem is:
What kind of problem you have? With whom you wanto to find solution? What kind of benefit may you get from drawing a diagram?
For UML i definelty suggest Larman book: Applying UML and Patterns :Check at amazon
And lastly, if UML does not fit your purpose, be creative and pragmatic...Use textual desription or even create your "own" visual modeling :-) or do anthing which help you...
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.