Repository navigation
Adding functions to draw UML diagrams from requirements - #414
Conversation
MaximilianSoerenPollak
changed the title
MaximilianSoerenPollak
changed the title
|
The created documentation from the pull request is available at: docu-html |
Added programaticall functionality for UML diagramm drawings. Adaptations to Metamodel are coming in future PR Ref: closes eclipse-score#364
dca1afd to
a0dc967
Compare
Removed assets and README as discussed. Pictures will instead be rendered inside documentation. Documentation moved to be more user facing.
AlexanderLanin
left a comment
AlexanderLanin
left a comment
There was a problem hiding this comment.
Code is "good enough" for the desired use case. Except the print statement.
I have no idea whether it draws correct images.
And I doubt that it's extendable / maintainable.
Both restrictions are "ok".
| if not needs_inc: | ||
| return set() | ||
|
|
||
| needs_implements = set(chain(*(needs[id]["implements"] for id in needs_inc))) |
There was a problem hiding this comment.
Interesting pattern with chain!
I guess it's the same as (pseudocode) set([e for e in needs[id]["implements"] for id in needs_inc])
There was a problem hiding this comment.
Yes exactly, it kind of makes it I guess a bit easier to read as it's not a 'double' list comprehension and just straight up flattens the list it grabs.
Was one of the nicest and simplest ways I found without having another helper func to flatten the list of lists.
There was a problem hiding this comment.
Not sure yet which is more readable :D
There was a problem hiding this comment.
Neither I guess neither is more readable than, just two for loops, but both are faster.
The images are drawn correctly, the only thing @hoe-jo mentioned was that the 'scope' of some of them (for example 'logical interface' being drawn in the same whitebox as the component). Other than that it follows correctly and links correctly. This however seems to be rather difficult to implement in this Iteration (without just starting from scratch). Edit: Agree to the 'doubtful expandability', this will be very difficult to expand upon with any meaningfull big feature. This approach is to make it work right now, but as mentioned in talks, as soon as new 'sensible' bigger feature comes in it makes sense to spend time to redo this from the ground up (if that is still a thing we want to implement then) |
|
@AlexanderLanin overall question, in this PR I have included a lot of docstrings, some with examples some without. Edit: I Guess the only real function that had no example / little to no merit to have a docstring was the gen_alias one, as that literally is a rather easy to understand oneliner. I deleted that, for now will keep the rest, but adapt wording where applicable. |
The examples helped. Some of the parameter explanations are better off with renaming the parameters IMHO. E.g. |
Removed the caching as it's no longer needed with this structure Remove debug print statement and no longer needed imports Renamed variables and changed/removed docstrings for more clarity Ref: closes eclipse-score#364
Converted classes into functions. Classes no longer needed as caching works without __repr__ overwrite now. Ref: closes eclipse-score#364
9ee5566 to
ab1f18e
Compare
Currently draft PR to gather feedback and comments.
The neccessary changes in the Metamodel are going to be introduced by another PR from @hoe-jo
This is the 'first' implementation of these
UMLdiagram functionalities. They are rather more direct than general, but fulfill the current 'wants' that were raised.However, to allow for future growth and anticipate complexity getting higher as well as having more control over grouping of drawn items, a more general solution should be worked on.