I currently have a package that contains model diagrams only. These model diagrams include elements from a common library that other packages include in their diagrams. I want to avoid baselining the library package and diagram package separately since the library is very large.
What would be the best way to baseline the package with the model diagram to include all the elements in its diagram?
One solution I made was a VBS script to read the diagrams in the specific package for all elements and bring them into the package to baseline, it will then baseline the package. After baselining, it returns those elements to their original parent packages.
Related
I am using Modelica in my work, where I have modeled a system that contains many models. I want to make it simple to use by creating a package using " within" so this package contains all the models. What I want is to open the package instead of opening many models, which takes time.
Instead of doing everything by hand, I suggest to create your packages with a Modelica tool (OpenModelica, Dymola, SimulationX, ...).
The tool will automatically create the folder structure and the within lines in the .mo files for you. Doing it manually is not much fun.
You could e.g. use OMEdit (part of OpenModelica) to create your package structure as follow:
create your top-level package via File > New Modelica Class
insert sub-models and sub-packages in existing packages via right-click > New Modelica Class
According to this website http://omwebbook.openmodelica.org/
A package is simply a container or namespace for names of classes, functions, constants, and other allowed definitions. The package name is prefixed to all definitions in the package using standard dot notation. An import language construct is provided for Modelica packages.
the package can help us to gather components that build the main model together in same place inside it , just by clicking on the package you open all your components inside it.
to open a package in Modelica we follow the follwing instructions:
After creationg the package you will get a folder with the package name in the place that you chosed to saved it in it , when you open the folder you click on package in order to open your package .
hope this can be helpfull
EDIT : got it shorter.
We created three modules following the prism doc and our requirements.
We did a horizontal slices with modules.
SharedServices
BusinessLogic
UserInterface
In the UserInterface we are using Syncfusion components and other packages, and It would be great to put everything in the UserInterface module but how can we reference nuget assemblies from that module in the shell (to apply theming for example) to avoid having references in each modules & the shell ?
Should we add nugetpackage to each module and the shell (is it bad... ?) or is it possible to have one module which defines base class referencing external assemblies for example and that would be themable (with ResourceDictionary) & usable in the whole solution (shell & other modules) .
Thanks.
Very broad question, it might well be closed, but I try to give you a few guiding thoughts:
Generally, you either slice horizontally (as you did, UI-module with all the views plus logic-module with all the services) or vertically (as your Product-module suggests: views, view models, services for the product in one module, those for the user in another).
You can do both, but then you should "slice through", so one module for product-ui, one for user-ui, one for product-services, one for user-services... you get the idea. That means a lot of modules, though.
Also, when creating your modules, have an idea of what you want to achieve. Modules can encapsulate components to be reused in another app. Or they can encapsulate exchangeable components, so you could create a car-sharing app today and tomorrow swap out the car-module for a bike-module and have a bike-sharing app. Or they can be used to enforce segregation of code based on risk analysis in a regulated environment. What I'm trying to convey: don't create modules just to have modules, make each module have a defined purpose.
Also, define the interfaces for the modules. I don't like modules to reference each other, as it effectively destroys all segregation that would otherwise be there. Create seperate non-module assemblies that only contain public interfaces. Then make your modules contain the implementations as internal types. In an ideal world, no module assembly contains a public type. The interface-assemblies can be either per module or per consumer or per link between modules (those checked boxes in your N2-chart, you have one, don't you?).
You want to keep the number of modules reasonable, as well as the dependencies between them (not as in "assembly references" but through interface-assembly).
how can we reference nuget assemblies from that module in the shell (to apply theming for example) to avoid having references in each modules & the shell ?
You should separate the "interface" part (e.g. base classes or DTOs, not part of the module) and the actual services part (that's the module). Example: unity has a nuget package for the interfaces (Unity.Abstractions) and one that contains the container implementation (Unity.Container). There's nothing wrong with everyone referencing the interface, basically, that's saying "I want to use that interface".
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.
We aim to execute fUML specifications written in Papyrus using the fUML reference implementation. This has not been challenging since an UML model containing a single Class diagram and one or more Activity Diagrams can be directly executed by calling the fUML constructor:
new Fuml(File);
However, it is difficult to specify complex behaviors without basic Integer operations. For example, 'equals', 'greater'...
I am aware that there is some library of such functions that can be selected using OpaqueBehaviors. Therefore, my question is: where and how can those such "basic operations" be found?
Sorry, this question was just pointed out to me recently. But, in case you haven't figured it out yet, I do have an answer for you.
The library you are looking for is the Foundational Model Library, which contains packages such as IntegerFunctions, BooleanFunctions, etc. The normative fUML specification includes a standard XMI file for this library (at http://www.omg.org/spec/FUML/20121019/fUML_Library.xmi, for fUML 1.1). However, to use the library in Papyrus, you need an Eclipse .uml version.
If you want, you can convert the normative XMI yourself: Download the file and open it in the Eclipse UML Editor (not Papyrus). Select File > Save As and save the file with a .uml extension (fUML_Library.uml). You should then be able to import this .uml file into Papyrus and reference the functions in it from your activity models. As long as you maintain the normative element IDs from the original XMI file, the reference implementation will know that these are standard library functions, for which it has built-in implementations.
However, there is actually a .uml version of this library already available for Papyrus. It is included with the additional Moka Model Execution component for Papyrus. If you install this component, then the fUML model library becomes available as a "registered library" that you can import into your model and use as above.
Note that Moka also includes an fUML execution engine that you can use to execute activity models directly within Papyrus (see https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution). However, any models created in Papyrus that can be executed with Moka can also be executed externally from Papyrus using the reference implementation, just as you have done before.
I'm trying to import some source code into EA, and make packages. In my root class diagram, I want to show each package as a visual grouping and have all classes inside that package in one group.
Can this be done?
Thanks
Not automatically. When you reverse-engineer source code, you have the option of creating either one class diagram in each package, or no diagrams at all.
Doing it manually, you can create a diagram which simply contains the packages: by default, EA lists the contents of each package when the package is placed in a diagram.
You could also drag the classes into the diagram and group them using boundaries or swimlanes. Boundaries are created from the "Common" diagram toolbox, while swimlanes are accessed by right-clicking an empty area of the diagram.
Finally, you can play around with the diagram's properties (also accessed by right-clicking an empty area), specifically the ones concerning namespaces and fully-scoped object names; these affect how EA displays packages and elements in a diagram.