I am playing with Enterprise Architect for the first time and looking at options for adding Test Cases. I have found a way to add A test case element -
Right-click on element | Properties | Responsibilities > Scenarios > Structured Specification
and this seems to get me where I want quicker as we aren't using Use Case diagrams right now.
While I'm looking at options though I wanted to check, a lot of documentation says, and a Youtube entry shows that you can add a test case from the tool box in a Use Case Diagram. I don't have that option though, in Use Case I just have Actor, Use Case and Boundary. Is this a version thing and it's been deprecated or am I missing a trick ?
Thanks
You can add a test case element from the custom and maintenance toolboxes
Since v14 Sparx has somewhat cleaned up the toolboxes and removed the Test Case (which is not defined in UML) from the UML Use Case toolbox.
Related
I was playing around with openapi-generator, and cant find a way to get it to generate valid scala code for scala-play-server.
I use the petstore.json I downloaded from swagger.io, and run
openapi-generator generate -i petstore.json -g scala-play-server
It seems to kinda work, except, the models it generates look like this:
case class Tag(
id: Option[Long],
name: Option[String]
additionalProperties:
)
... which, of course, isn't valid scala code, and fails to compile.
I tried adding
--additional-properties=disallowAdditionalPropertiesIfNotPresent=false
to command line as some website I googled suggested, but that didn't make any difference (and neither did changing false to true).
I guess, I could just put together a sed script, to run on all generated files and replace additionalProperties: with additionalProperties: Map[String, Any] (or just remove those lines completely - no idea why I would want them there), but thought I'd just ask first in case someone knows about an easy fix that wouldn't be this "hacky" ...
Disclaimer, I am not a scala developer, but I spend a lot of time with the open-api-generator.
It appears this is a known bug that was reported in September 2022. However, it doesn't seem to have any comments or traction. Feel free to add comments to the existing ticket. Sometimes that helps them gain visibility.
I don't know if it matters, but I tested the other scala server generators, and all of them generate the class without the additional properties. So, if you are able to use a different scala server generator, that may be a work around.
Another potential work around, if you don't ever plan to use the additionalProperties feature of OAS, would be to remove it from the mustache template. You can do this via templating. Copy the caseClass.mustache and the model.mustache templates into a directory of your choosing, and delete the references to the additionalProperties. Then, add the template directory to your CLI generator via -t/--template.
I tried using the templating method myself and it works, however you will no longer be able to use the additionalProperties feature from OAS in your schema.
I want to build up a tests library and keep it separated from the libraries under development. My first thought is to go for a structure like the following:
PensLib
--Variants
----BallPoint
----FountainPen
----Tests
------TB_BallPoint
HammocksLib
--Variants
----SingleHammock
----DoubleHammock
----Tests
------TB_DoubleHammock
--Systems
----IndoorWalls
----OutdoorWallAndTree
----CoconutPalms
----Tests
------TB_IndoorWalls
Tests
--PensLib
----Variants
------Test_BallPoint // extends PensLib.Variants.Tests.TB_BallPoint
--HammocksLib
----Variants
------Test_DoubleHammock // extends HammocksLib.Variants.Tests.TB_DoubleHammock
----Systems
------Test_IndoorWalls // extends HammocksLib.Systems.Tests.TB_IndoorWalls
For now let's assume that the way I structure my libraries make sense (which most likely doesn't). I will soon ask more questions on good practices in setting up the testing environment in Dymola and with the Testing Library.
My question is about the correct way to handle relative and absolute paths within models, if possible at all.
The model PensLib.Variants.Tests.TB_BallPoint is used for developing the variant BallPoint
The model Tests.PensLib.Variants.Tests_BallPoint is used for automated testing
I want the model Test_BallPoint to extend the model TB_BallPoint, but I cannot link them. I guess the absolute path PensLib.Variants.Tests.TB_BallPoint is treated as a relative one, since PensLib is found "on the way out" of the Tests library, and from there it goes looking for the rest of the path. Is there perhaps a way to control the path, kind of ..\..\..\PensLib\Variants\Tests\TB_BallPoint?
As you already noted such a setup makes troubles. There are ways around that, namely global name lookup and imports, which I explain briefly further below.
Both solutions are nice when you have such a case in a few situations. But if you have to use it all the time, you make your setup unnecessarily complicated.
Hence, I suggest to make yourself the live easier and change your package structure:
Either create a dedicated test library for every library, maybe PensLib_Tests and HammocksLib_Tests
Or rename the packages in the Tests library and don't use the exact library names
Global name lookup
You can use absolute class paths. They are denoted with a leading ., so this should work:
extends .PensLib.Variants.Tests.TB_BallPoint;
See Modelica Specification chapter 5: Scoping, Name Lookup, and Flattening for details, especially 5.3.3 Global Name Lookup
Importing
You can simply import the library. Lookup of imports is always performed globally.
import PensLib;
extends PensLib.Variants.Tests.TB_BallPoint;
My intention is to have own naming rules in eclipse editor for C programming
Ex: a function should start with File name, it shall contain maximum of 20 character- FILENAME_MaxOf20Char().
When it is violated has to show an warning.
To do this tried to extend org.eclipse.cdt.core.IErrorParser. But this one is parsing from compilor output.
IErrorParser is not the right extension point to use for this.
You want to use the Code Analysis (CodAn) framework and write a custom checker. See this page for documentation.
In a Papyrus Model, I clicked the Use Case Diagram (which is quite simple - contains about 5 use-cases), and selected "Designer -> Generate Java Code".
In response, I got hundreds of new packages, each of which contains hundreds of empty classes, with strange names such as "Aaixixnrpr", "Aclywqwwlr", etc...
What is happening?!
Papyrus SW designer does not have a particular code generation support for "use case" elements, i.e. it will treat an Actor or a Use Case just as a UML class. This means that it will create an empty Java class, unless you add operations/opaque behaviors.
But the Java code generator should not create classes for elements that are not in the model. Can you please double check via the model explorer that elements such as "Aaixixnrpr" do not exist in the model?
Which version are you using? (I recommend to use version 1.0.5 from this update site on an Eclipse oxygen). Btw, I also recommend to use the Papyrus forum for questions like this.
With intellij idea, how do I find out what makes a variable be visible?
An example of when it is hard:
Suppose you look at class A, and you see a variable something. If you jump to source you see that it's defined in trait X. But you don't extend trait X directly. What do you extend, then, that makes this variable visible? If you have a deeply nested hierarchy, tracking can be hard.
Any recommendations or solutions?
EDIT: Please vote for the feature if you're interested: http://youtrack.jetbrains.com/issue/IDEA-124369
I don't think that IntelliJ IDEA has any shortcut for "finding what makes a variable visible".
However you can determine it using the "Find Usages" option (Alt + F7). For example:
import java.nio._
object TempObj extends App {
def func = 2
val p = file.Paths.get("some-path")
func
}
So Find Usages on "file", tells you that its from the Package "file" (in heading of the new Tab it also shows the complete package name, ex: Find Usages of java.nio.file in Project Files).
Whereas Find Usages on func will tell you that its a Method (And the Tab heading now says: Find Usages of func() in Project and Libraries)
So now in way you can determine, what exactly makes the variable visible. This also works for imports since it shows the package from which it is imported and you can then look for import of that packages.
I know of two almost-solutions to this problem.
Go-to-declaration, as you mentioned, solves this problem in the case of local variables.
More generally, the "find usages" feature gives you a neat little breakdown by type and file of different uses of the variable. From this you can see if it's involved in a static import.
It's not perfect, but with a moment's thought these two are generally sufficient to figure out what you want.
Use ctrl+b or F4 to jump to source code. Alternatively you can use ctrl+shift+a to get option/action. You can find shortcuts at http://gaerfield.github.io/ide-shortcuts/ as well. Hope it will help.
From what I understood you want to see the code that creates an Object you use, for instance Mystery someMystery;.
That gives you two options to populate someMystery:
someMystery = ... where ... is your code to populate
someMystery and if that is the case you should follow
that code (with ctrl+B as far as you need to) to the point where it
actually creates the Mystery object.
Use CDI to populate that object instance for you, in which case you should look into the CDI mechanism in order to see in what way the object instance is populated.
In either way IMO there is no way to know for sure if the someMystery instance is of some more concrete class than Mystery, because it is decided in runtime, not in compile time, so your next bet would be to run the program in debug and see what object goes into someMystery, although you are not guaranteed to get the same type of object every time.
PS. My answer is based entirely on my java understanding of the topic, can't say if it is valid for scala also.
This might not be exactly the answer you were hoping to get.
However, quoting yourself,
If you have a deeply nested hierarchy, tracking can be hard.
Have you considered using composition over inheritance? Perhaps this would remove the need for the feature you are looking for.
Deeply nested hierarchy doesn't sound good. I understand your pain about that.
When you override vals or defs there is a little circle next to the line number that shows where it is from even when it is from nested hierarchy. Hovering over vals with the command key down also shows you a little tooltip where it is from.
Does this help?
https://youtu.be/r3D9axSlBo8
if you want class, field or method to be visible, you need to implement them as public. If it was your question.