Hello,
Is it wise to describe the current Archi architecture in more formal way in ArchiMate, so that we define building blocks and add requirement to that building bocks.
With this architecture we can set up the wiki in a more structured way or describe the proposals and roadmap per building block?
Without a formal definition of building blocks all the proposals are described in one or more different pages.
Hi Bart,
I fully agree, that's the kind of thing I've wanted to do for a long time.
It could serve several purposes:
- Document Archi itself
- Document some workflow/processes which use Archi as a tool
- Offer some ArchiMate examples which are not related to Archissurance
@Phil: we could even document Archi's motivation and principles...
Regards
JB
Sounds great. Crowd source this... ;D
How should we start? For example can we place the mode on github for versioning?
Quote from: Bart Ratgers on September 16, 2014, 06:18:28 AM
How should we start? For example can we place the mode on github for versioning?
If possible I would try using Michael Tapp's Git plugin (https://github.com/CymaLtd/ArchiGITPlugin). If you don't know it, look at this old thread (https://groups.google.com/forum/?hl=en#!topic/archi-dev/8sCoD6Ctj-c).
I've just set up a shared repository on GitHub (https://github.com/archi-contribs/shared-model-repository) and sync an almost empty model to start. Just request rights on it or provide me your github account.
I must admit that I still have some issues using Michael's plugin but I guess it's just a matter of enhancing documentation. And beside this need, using this plugin can help us creating a whole bunch of shared model that we could all work on.
JB
Hello JB,
I running a beta version of Archi 3.0 and naturally the plugin isn't compatible.
Tomorrow I setup the old Archi environment for describing Archi or try to change the dependencies of the plugin.
Hi use latest beta too...
The plugin is compatible (no API changes between 2.7 and 3.0) but seems to have some limitations like:
- No HTTP proxy support (I'm working on this as I need it at work)
- Importing a model from a git repo has to be done in an empty local directory... even if you already have a clone of the git repo locally.
- After having worked on a model you have to export it on another branch and not the original one. Merge can be done afterward using git branch merge
Other than that, it works, but I can understand its too much pain (and obviously I'm not sure I would use it with colleagues).
JB
Hello JB,
It took a while in my spare time, but I finally found the issue about the not working plugin. I installed a corrupt jar file.
After fixing the file I was struggling to import the git version of your model.
Sadly.. no error messages were shown as something went wrong. But finally I have successfully import the shared model.
I will start this week to model the functions.
Hello Bart,
I guess I faced the same issue ;-)
We should perhaps open some github issues on the plugin's repo.
JB
Yes I agree. Maybe a stupid question, is the plugin's repo a new repository or an existing one?
And if this should be a new repository, where do you want to locate this repository (issue list):
- A part of the Archi?
- or a part of archi-contribs (https://github.com/archi-contribs/archi-modelrepository-plugin)?
BTW, What kind of name we give to the Requirements properties, following your standard. For example: <class>:Requirement, or do you have another suggestions?
Hi Bart,
Quote from: Bart Ratgers on September 30, 2014, 13:18:27 PM
Yes I agree. Maybe a stupid question, is the plugin's repo a new repository or an existing one?
Not sure to understand, but the plugin's repo is Michael Tapp's one : https://github.com/CymaLtd/ArchiGITPlugin
So any issue about his plugin should be opened on his repo.
Quote from: Bart Ratgers on September 30, 2014, 13:18:27 PM
BTW, What kind of name we give to the Requirements properties, following your standard. For example: <class>:Requirement, or do you have another suggestions?
(maybe I need some coffee...) What are you calling "Requirements properties" ? Can you provide a short example ?
JB
Hello JB,
Plugin Repo
Now i understand what you mean with the plugin repo.
Requirements Property
Ok, what i mean is the following; I use the technique to describe a building block by a short description following by a set of requirements. In my report template I use the property name _Req to define a requirement. You use the approach by defining classes, for example: Report:HideView If I adopt your approach what do you prefer as property name for describing a requirement?
I hope that this ease your pain.
A more real live example:
<Application Function> Manage repository
<Documentation> Following the TOGAF definition a repository is a system that manage the architecture related assets. A repository identifies at least a meta-model and an architecture landscape......... etc......
<property name> : <property value>
_Req : Is capable to manage archimate concepts (building blocks), following the ArchiMate 2.1 specification
_Req : Is capable to organize the building blocks in a structured way,like a directory structure in a file system.
_Req : Is capable to copy and paste building blocks.
_Req : Is capable to search and find building blocks based on name, type, description or properties.
Hi Bart,
With this example (and some coffe in between) I understand and my answer to you question:
Quote from: Bart Ratgers on September 30, 2014, 13:18:27 PM
BTW, What kind of name we give to the Requirements properties, following your standard. For example: <class>:Requirement, or do you have another suggestions?
...will be: "another suggestion" ;-)
In think we should separate as much as possible "meaning" (elements and properties) and "representation"(the report done on the model). This means that users should be free to name their elements and properties the way they want (ie. no naming convention to be defined on our side), but should use (for the moment) some specific properties to "tune" the report, these "representation oriented" properties should follow a naming convention.
In your example, "Requirement" properties are "meaning", but you'd like to bind a specific "representation" to them (don't display property name but show an icon instead, as in your report template). IMO this should be done through the definition of a kind of "report profile" somewhere. Hence my suggestion to define some "representation" oriented directive to define the way properties should be rendered:
The idea would be to look for a "Report Profile" view in which we define properties following this pattern: "Report:Property:
propname#
attribute":
- "propname" would be the real name of a user defined property.
- "attribute" would be the property attribute to set (e.g. "icon", "hidelabel", "bold"...).
The property value would contain some hints on how to display it. We could easily extend to define icons, show/hide property name, insert bullet point...
For example, this would be the "profile" for your requirements:
- "Report:Property:Requirement#icon" = "img/req.png"
- "Report:Property:Requirement#hidelabel" = "true"
This means that the model contains an Application Function with some properties names "Requirement" (easier to understand and exchange with other tools -> the "meaning"), but the report show them using a small icon and without label (-> the "representation").
This "profile" or "Report Profile" would be defined in only one view, so changing this view would have a global effect on report. This view being used only for its properties, it could even be a Canvas view that you can save as a Canvas template (and thus easily apply it on several models...).
Drawbacks:
- IMO this is a global profile, so all your "Requirement" properties will be shown according to the report profile.
- I still have to figure out how to do it with JasperReport ;-)
JB
[/list]
Hello JB,
Thank you for the update and I think I understood you well. And I also think we could harmonize and combine some of our ideas together so that we could create a solid reporting or deliverable solution.
For example if we extent the current [models] window with a folder <deliverable> and that folder contains a special kind of a deliverable view, then we able the create more reports from that folder by specifying each report in some kind of deliverable view. You can add properties to that <deliverable> view and create a chain of existing views in Archi, see attached imaged. You can also add things like chapter number and a TOC as some kind of properties and especially you can control the order of the individual views without adding numbers to the individual views, like I do now.
With that, we separate the deliverable from the existing administration in Archi and you can also add the global reporting properties (like: "Report:Property:Requirement#hidelabel" = "true") as a property in the deliverable view.
In my case I have a situation that i describe the enterprise and all the projects within the same model. Based on the project I generate a specific document by adding properties in the view. With a deliverable view I can easily create a Enterprise by selecting some views and more than one segment architectures.
How do you think about that.
Hi Bart,
I fully agree on the idea of having a "Deliverable" folder. I came on the same idea of creating a "report" view to define TOC and link views. I also think it should be doable to extract pictures from a canvas views to store icons and/or background in the model itself.
I suggest that, for the moment, we do a kind of POC with Archi as it is, thus creating a "Deliverable" folder in the "Views" root folder, and limiting code change to potential new methods used by Jasper (if any).
BTW - we should add a view property to display a catalog or a matrix instead of a diagram (I recently had to create a requirement diagram which ended in a big mess: a simple catalog would have been really easier to read...).
JB