Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Kamal Hammoutene on November 13, 2012, 07:41:39 pm
-
The current "intented behavior" of the Package Browser can lead to important dependencies to be overlooked.
- For example, in package A with an element Ea: if I reference an element Eb (defined in package B which is not in package A hierarchy) by creating a link to/from Ea, the current Package Browser do not show this dependency in the element list.
IMHO, this is very misleading, if you want, for example, to export for review all the elements and links contained in package A.
Anybody has the same worry?
-
Yes, me. I wrote a script to create an xref on a nightly basis to find out cross package links. It would be nice to see something in EA which supports that. However, I've no idea how that could look like on a general basis.
q.
-
The package browser shows elements, not relations.
If you want to export all elements and links contained in package A you'll have to use another method.
Besided, if you wanted to know all dependencies from within your package then you'll also have to take into account the attributes or parameters that use another class as their type.
And maybe also all behaviors that somehow call an operation on an element in another package, and ...
Geert
-
The package browser shows elements, not relations.
If you want to export all elements and links contained in package A you'll have to use another method.
.....
Geert
What I like in the Package Browser, it is that I can bring a reviewer of my model (my package) in EA without having him to deal with diagrams and their contents. The reviewer will work in an Excel-like environment so no training would be necessary.
My remark is made in a context of using EA for Systems Engineering (SysML) and not for software. I need to be able to manage all requirements allocated to a sub-system for example (looking at their status, priorities, ...). Many requirements are standards/compliance requirements which are defined in projects-wide areas (i.e. outside my package)>
-
As Geert said, the Package Browser is intended to show the elements contained in a package. Not everything that is referenced by a package. If it was intended to show the references then it would. It's just meant for a different use case from what you're trying to use it for. That doesn't make it wrong or misleading.
If you want a list of all the requirements impacted by a package in a table view then run a custom sql query using the #Branch# subsititution and joining two copies of t_object to the t_connector table.
-
As Geert said, the Package Browser is intended to show the elements contained in a package. Not everything that is referenced by a package. If it was intended to show the references then it would. It's just meant for a different use case from what you're trying to use it for. That doesn't make it wrong or misleading.
If you want a list of all the requirements impacted by a package in a table view then run a custom sql query using the #Branch# subsititution and joining two copies of t_object to the t_connector table.
Thank you for your suggestion.
Where I can find the MS-SQL database schema so I can write my SLQ query?
If you have a query which does similar things, I am interest too.
-
The schema is created via the SQL you can download from Sparx' resources. You should have it at hand when you work with a MS-SQL database.
q.
-
The schema is created via the SQL you can download from Sparx' resources. You should have it at hand when you work with a MS-SQL database.
q.
Thanks.
yes, I can look at the SQL instructions to create the database and tables but it does not tell me how tables are linked and what are the definition of the attributes (column tables).
Can I safely use the UML standard definition (i.e UML specifications) and map them to the EA SQL database?
-
No the EA database and the UML specifications are two very different things.
There is no official database documentation. The best you can do is buy the book from Thomas Killian: Inside EA (https://leanpub.com/InsideEA)
Geert
-
No the EA database and the UML specifications are two very different things.
There is no official database documentation. The best you can do is buy the book from Thomas Killian: Inside EA (https://leanpub.com/InsideEA)
Geert
It does imply, that If I create complex queries for making consistency checks or generating special reports, I am not guaranteed that it will still work with a new EA release. >:( >:( >:(
Sorry, but querying directly the database looks like hacking to me and something to forbidden in a professional environment.
-
I am not guaranteed that it will still work with a new EA release. >:( >:( >:(
The DB schema is the least thing Sparx Systems will change in an incompatible manner, believe me. That strictness already causes various other problems, because solutions for these would need to change the EA DB model.
Best regards,
Günther
-
I am not guaranteed that it will still work with a new EA release. >:( >:( >:(
The DB schema is the least thing Sparx Systems will change in an incompatible manner, believe me. That strictness already causes various other problems, because solutions for these would need to change the EA DB model.
Best regards,
Günther
Thanks Günther for your input.
I am sorry to disagree.
Us, users of EA, either modellers or administrators, we have no need to know the DB schema. We should stay at the conceptual level (e.g. UML, SysML, BPMN, ...). This will guarantee that Sparx could change the DB schema as much as they want (for speed, standardization, reuse, ...) without impacting our use of EA.
This is a just a good and sound "old" sotware engineering practice. ;)
-
Indeed. However, another good old practice says: you have to have a hack some time.
q.
-
... just open the EAP file from within MS Access and knock yourself out - I found having EA Sparx open side-by-side with MS Access helps a lot in figuring out relationships between UML elements and their representation in the sparx DB. Very painful process though.... :(
-
I know. That's what I did writing my book...
q.
-
... just open the EAP file from within MS Access and knock yourself out - I found having EA Sparx open side-by-side with MS Access helps a lot in figuring out relationships between UML elements and their representation in the sparx DB. Very painful process though.... :(
I'd like to have the official Sparx recommendation how to proceed (SQL, EAP file, ...) so I can make a report on all relationships that I have represented in a given package.
-
In that case you better ask Sparx, and not the users.
Try [email protected]
Geert
-
In that case you better ask Sparx, and not the users.
Try [email protected]
Geert
I was assuming that Sparx was also using the forum to answer some of the questions from their privileged position.
If I ask Sparx and have a reply, I am pretty sure that many users want to be aware of the answer. So let's use the forum for sharing knowledge between users and Sparx. Of course, bug reports should not part of this forum.
-
No, I mean it. That isn't my opinion, that would be the response from a Sparx employee if he saw your question. (for which there's no guarantee)
Geert
-
Geert is correct. If you want an official, logged, researched (and obligatory) response from Sparx, you make an official request (by email, or in a bug report or a feature request).
It is quite common for users to have an official dialog with Sparx and then post the essence of their problem and the Sparx response on the forum.
-
I was assuming that Sparx was also using the forum to answer some of the questions from their privileged position.
I don't know about privileged position, but I do have a desk by a window... 8-)
I am not able to give an official recommendation. However, it is my personal opinion that you are better off using EA's custom SQL query functionality rather than opening your EAP file in MS Access because then you can make use of the #branch# macro that SimonM mentioned earlier in this thread.
-
Anybody knows, in the Package Browser , if the "filter" functionality is supposed to work when searching for elements when you are in the "show hierarchy" mode.
It works well if you are not in "show hierarchy" mode.
-
As Geert said, the Package Browser is intended to show the elements contained in a package. Not everything that is referenced by a package. If it was intended to show the references then it would. It's just meant for a different use case from what you're trying to use it for. That doesn't make it wrong or misleading.
....
Sorry to come back again to this discussion.
Let's take a concrete example:
I have created a model with actors, use cases and requirements. The requirements are linked to the use cases.
My model is organised by Use Cases. A requirement is written in a "User Story" style: "As a 'actor name', I want to be able to .....".
When I use the package browser, I can see everything.
Now, I wanted to provide a different view on the requirements which is organised by actors. So I have created a package by actor and within each package, a requirement diagram where I dragged and dropped the requirements which are relevant to the current actor.
I then open a package browser on this package, and the result is NOTHING.
I still believe that the Package Browser should list the elements referenced in the diagram even if it was not "the intented use of the package browser".
-
Kamal,
If you want something like that you better use the List view of a diagram.
That will show you a tabular view of all elements show on a diagram.
To open this view right click on a diagram in the project browser and choose View Diagram As|List View
You can switch back and fourth between the list view and the diagram view.
Geert
-
Kamal,
If you want something like that you better use the List view of a diagram.
That will show you a tabular view of all elements show on a diagram.
To open this view right click on a diagram in the project browser and choose View Diagram As|List View
You can switch back and fourth between the list view and the diagram view.
Geert
Thank you (again) Geert but it does not solve my problem.
The List view works at the diagram level and *not* at the package level.
-
I know that.
If that doesn't help you then I only see two options:
1) you send a feature request (http://www.sparxsystems.com/support/feature_request.html) to Sparx and you wait.... and wait.... and wait.... without even knowing whether or not your request will be implemented.
2) You get your hands dirty and write an sql search that show you all requirements referenced on diagrams in your currently selected package, and you have your solution this afternoon.
Geert
PS. I can help you writing the query if you want.
-
I know that.
If that doesn't help you then I only see two options:
1) you send a feature request (http://www.sparxsystems.com/support/feature_request.html) to Sparx and you wait.... and wait.... and wait.... without even knowing whether or not your request will be implemented.
2) You get your hands dirty and write an sql search that show you all requirements referenced on diagrams in your currently selected package, and you have your solution this afternoon.
Geert
PS. I can help you writing the query if you want.
I trust Sparx to be able to see the value of this request.
I can also imagine that it won't be a difficult development by adding "linked" elements in the Package Browser list.
Sparx can also put a check box in the Package Browser to specify if you want or not to see the referenced elements.
I can help you writing the query if you want.
Yes please.
-
Try this:
select distinct o.ea_guid as CLASSGUID,o.Object_Type as CLASSTYPE,o.Name as Name,d.name as DiagramName ,package.name as PackageName ,package_p1.name as PackageLevel1,package_p2.name as PackageLevel2 ,package_p3.name as PackageLevel3
from ((((((t_diagram d
inner join t_diagramobjects do on do.Diagram_ID = d.Diagram_ID)
inner join t_object o on o.Object_ID = do.Object_ID)
inner join t_package package on d.package_id = package.package_id)
left join t_package package_p1 on package_p1.package_id = package.parent_id)
left join t_package package_p2 on package_p2.package_id = package_p1.parent_id)
left join t_package package_p3 on package_p3.package_id = package_p2.parent_id)
where
o.Object_Type = 'Requirement'
and package.Package_ID in (#Branch#)
and o.Name like '#WC#<Search Term>#WC#'
Geert
-
Try this:
select distinct o.ea_guid as CLASSGUID,o.Object_Type as CLASSTYPE,o.Name as Name,d.name as DiagramName ,package.name as PackageName ,package_p1.name as PackageLevel1,package_p2.name as PackageLevel2 ,package_p3.name as PackageLevel3
from ((((((t_diagram d
inner join t_diagramobjects do on do.Diagram_ID = d.Diagram_ID)
inner join t_object o on o.Object_ID = do.Object_ID)
inner join t_package package on d.package_id = package.package_id)
left join t_package package_p1 on package_p1.package_id = package.parent_id)
left join t_package package_p2 on package_p2.package_id = package_p1.parent_id)
left join t_package package_p3 on package_p3.package_id = package_p2.parent_id)
where
o.Object_Type = 'Requirement'
and package.Package_ID in (#Branch#)
and o.Name like '#WC#<Search Term>#WC#'
Geert
Will do. Many thanks.
-
Try this:
select distinct o.ea_guid as CLASSGUID,o.Object_Type as CLASSTYPE,o.Name as Name,d.name as DiagramName ,package.name as PackageName ,package_p1.name as PackageLevel1,package_p2.name as PackageLevel2 ,package_p3.name as PackageLevel3
from ((((((t_diagram d
inner join t_diagramobjects do on do.Diagram_ID = d.Diagram_ID)
inner join t_object o on o.Object_ID = do.Object_ID)
inner join t_package package on d.package_id = package.package_id)
left join t_package package_p1 on package_p1.package_id = package.parent_id)
left join t_package package_p2 on package_p2.package_id = package_p1.parent_id)
left join t_package package_p3 on package_p3.package_id = package_p2.parent_id)
where
o.Object_Type = 'Requirement'
and package.Package_ID in (#Branch#)
and o.Name like '#WC#<Search Term>#WC#'
Geert
Will do. Many thanks.
Works well as a temporary solution. Thanks Geert.
I am expecting Sparx to give their inputs on this topic because as I said previously, we shouldn't query the database directly.
-
as I said previously, we shouldn't query the database directly.
I'm not sure about that when talking about SQL Searches.
These searches are an official and documented feature of EA.
So presumably if Sparx would ever change their database structure, they should be able to provide some kind of conversion tool or backwards compatibility layer for the SQL Searches.
That argument doesn't apply when talking about say Crystal Reports directly querying he database, or usage of queries in add-ins.
Geert
-
as I said previously, we shouldn't query the database directly.
I'm not sure about that when talking about SQL Searches.
These searches are an official and documented feature of EA.
Unfortunatly Geert, there is no official documentation of the database schema.
For example, how did you manage to know which tables and attributes in the tables were relevant to your great SQL query?
-
True, there's little to no documentation of the db schema.
I learned the structure by trial and error, but then again, most of it is rather trivial.
Geert
-
As Geert said, the Package Browser is intended to show the elements contained in a package. Not everything that is referenced by a package. If it was intended to show the references then it would. It's just meant for a different use case from what you're trying to use it for. That doesn't make it wrong or misleading.
....
Sorry to come back again to this discussion.
Let's take a concrete example:
I have created a model with actors, use cases and requirements. The requirements are linked to the use cases.
My model is organised by Use Cases. A requirement is written in a "User Story" style: "As a 'actor name', I want to be able to .....".
When I use the package browser, I can see everything.
Now, I wanted to provide a different view on the requirements which is organised by actors. So I have created a package by actor and within each package, a requirement diagram where I dragged and dropped the requirements which are relevant to the current actor.
I then open a package browser on this package, and the result is NOTHING.
I still believe that the Package Browser should list the elements referenced in the diagram even if it was not "the intented use of the package browser".
Actually, the problem is worse as if you document such a packahe with a RTF template, you cannot access/document referenced in the diagram.
Sparx, please give you point of view.
-
Sparx, please give you point of view.
As others already mentioned, may be you should clarify such requirements as official feature request (http://www.sparxsystems.com/support/feature_request.html) or bug report (http://www.sparxsystems.com/support/bug_report.html) to Sparx' support ([email protected]).
-
Sparx, please give you point of view.
As others already mentioned, may be you should clarify such requirements as official feature request (http://www.sparxsystems.com/support/feature_request.html) or bug report (http://www.sparxsystems.com/support/bug_report.html) to Sparx' support ([email protected]).
Done over a month ago.
What I would like is that many users are pushing for it too. As I said in a previous post, I cannot imagine that the implementation would be complex.
-
Three different representatives of Sparx contributed to this topic and I believe your email query has been responded to as well.
Allow me to re-iterate.
This is not a bug. The Package Browser is working for what it was designed to do, which does not include displaying related elements.
You have been provided with multiple ways to get a report similar to what you wanted to display.
You are free to request this as a feature, but please remember that for various reasons not all features will be implemented.
-
Dear Kamal,
about a year ago i have written an add-in which some queries for showing impacted elements and maybe there is such a implementation which you are needing.
If you send me an email, i will send this add-in to you. Maybe it helps you, maybe not.
-
Try this:
select distinct o.ea_guid as CLASSGUID,o.Object_Type as CLASSTYPE,o.Name as Name,d.name as DiagramName ,package.name as PackageName ,package_p1.name as PackageLevel1,package_p2.name as PackageLevel2 ,package_p3.name as PackageLevel3
from ((((((t_diagram d
inner join t_diagramobjects do on do.Diagram_ID = d.Diagram_ID)
inner join t_object o on o.Object_ID = do.Object_ID)
inner join t_package package on d.package_id = package.package_id)
left join t_package package_p1 on package_p1.package_id = package.parent_id)
left join t_package package_p2 on package_p2.package_id = package_p1.parent_id)
left join t_package package_p3 on package_p3.package_id = package_p2.parent_id)
where
o.Object_Type = 'Requirement'
and package.Package_ID in (#Branch#)
and o.Name like '#WC#<Search Term>#WC#'
Geert
Hi Geert,
This nice SQL query is not working anymore (it used to work).
I got an error message "Invalid column name #Branch#"
How #Branch# is defined?
Thanks a lot for your help.
-
#branch# is only defined in the internal find Search Builder. It does not work a simple SQL executed from Respository.Execute or the query builder SQL pane.
-
Can you please tell me what the (#Branch#) does in your Query. It seems to be useful for me, but I have each element matching the query six times in my results.
...
and package.Package_ID in (#Branch#)
...
Additionally here is my query:
select
c.ea_guid as CLASSGUID,
c.object_type as CLASSTYPE,
c.name as Name,
c.stereotype as Stereotype,
package.name as PackageName,
package_p1.name as PackageLevel1,
package_p2.name as PackageLevel2,
package_p3.name as PackageLevel3,
c.package_id AS Package
from (((((t_object c
inner join t_objectproperties op on op.Object_ID = c.Object_ID)
inner join t_package as package on c.package_id = package.package_id)
left join t_package as package_p1 on package_p1.package_id = package.parent_id)
left join t_package as package_p2 on package_p2.package_id = package_p1.parent_id)
left join t_package as package_p3 on package_p3.package_id = package_p2.parent_id)
where c.package_id in (#Branch#)
and c.stereotype = 'requirement'
and op.Property <> 'Target_Release'
-
You have it multiple times because you join with t_objectproperties, and I guess you have 6 tagged values with a name different from 'Target Release'
Seems a bit weird to do this since you don't use anything from the tagged values in your result.
If the join is there simply to filter the results then you better use a exists clause then a join.
#Branch# is a macro that is being replaced by a comma separated list of package ID of the currently selected package and it's sub-packages.
Geert