Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages for classes #66

Open
alkock opened this issue Jun 2, 2023 · 2 comments
Open

Packages for classes #66

alkock opened this issue Jun 2, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@alkock
Copy link

alkock commented Jun 2, 2023

Is your feature request related to a problem? Please describe.
USE already has a wonderful possibility to create UML diagrams via classes and associations, which can be exported. Particularly with larger systems, a structure according to packages is desirable.

Describe the solution you'd like
A possibility to structure classes into packages that are also displayed in the class diagram view.

Describe alternatives you've considered
A current workaround would be to manually trace the packages with the help of an image editing program. ;)

@alkock alkock added the enhancement New feature or request label Jun 2, 2023
@ChuckLutz
Copy link

This would be a tremendously helpful enhancement; I am interested in building models to capture other OMG specifications, which inevitably are divided into packages and often make references to other models' content, e.g. to MOF::Element.

An undesirable current workaround would probably be to encode package names into class names, e.g. "MOF__Element" or similar.

@h-man2
Copy link
Contributor

h-man2 commented Jan 15, 2024

This one is a big one, because we want to solve more than just packages in the long-run.

Plans are currently:

  • Add support for defining data types, i. e., side-effect free types that don't change the system state (comparable to primitives in Java or structs in C#).
  • Add support for a packaging mechanism including versioning, and a package manager
  • Add support for "import" statements to be able to access package elements without the need to fully qualify them
  • Support visibility definitions (public, private, ...)

Students of mine work on some of these topics at the moment.

If you like, feel free to post ideas about a package mechanism here. So we can discuss a solution, espacially for using packages).
Like for example:

model Shop
import de.haw.hamburg.types.Date

class Invoice
  attributes
    date:Date
...
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants