SSRS

[gb]

Hi
I'm new to using EA and I have about 20 SQL Server Reporting Services Reports that I would like to document using this tool.  Any suggestions as to what model I should use for this?  Do people generally use EA for this purpose?

Thanks in advance for the help
gb

[g.makulik]

Hmmm, as far I remember correctly an SQL Server Report Services Report boils down to some special  XML file to describe the dataset sources and the report formatting sections using fields, groups, etc. from that sources, right?

Of course one can model such thing in UML. I think the best direction to go would be creating a (minimal) profile that allows you to model certain elements you'd like to see in your models. Additionally you might apply some transformation/code generation, that enables you to generate the RDL files that make up the reports. You might check, which results you get from importing the RDL-XML schema definition provided by MS and which structure is used there.

Which of the RDL-XML elements should map to which kind of UML elements is a question of choice, e.g. you might model single reports (and their parameters) as operation embedded in a logically coherent class (report project?) or a (parametrised?) class.

I remember I've once used the 1st variant (without describing it in UML), when organizing the SSRS project structure on a bigger database. At least we had a single stored procedure to serve a particular set of reports consistently that were organized in projects.

It's a bit questionable if it's worth the effort to use UML models for reports, despite you'd like to prototype them similarly as with the EA User Interface Model.

HTH,
Günther

[Sunshine]

I agree with Günther, I think you've just got to ask yourself why do you want to document a report. It is possible to do in enterprise architect however do you want to spend time keeping it up to date. You could reverse engineer the database and show how each report looks via screen layout diagrams and then meticulously map each field in the database onto the report. However it will be quite time consuming and is likely to get out of step with any changes that happen.
Ask yourself if in 12 months time you want to update the reports are you going to look at some model/document or are you going to dive straight into SQL server reporting and change it.
My advice is to work smart and  not model/document things just for the sake of it.  8-)

[Geert Bellekens]

We do model the functional analysis of our reports using UML in EA.
I'll try to explain our approach:

First of all the basis of our reports is the logical information model (which is a PIM level abstracted database model)
All reports show parts of that information model.
We then have the notion of a ReportSet (class with stereotype <<reportset>>) which is on about the same level as an entity.
This ReportSet contains all the fields we usually need from a certain entity.
Sometimes we include information from several entities into a single ReportSet (such as including the address string in a Person ReportSet)
We create <<trace>> dependencies between the ReportSet and the Entities it uses.
Technically the reportset are translated into views on the database

Then we have a ReportGroup (again a class with stereotype <<reportgroup>>. A ReportGroup contains all reportSets that are need for a (group of) Report (s). Sometimes a ReportGroup is used in only one report, but often there is a set of reports that use the same group.

Then last (but not leas) we have the Report itself. We model those using the standard simple user interface modelling in EA, and we link each report with the ReportGroup it uses.

This way of modelling allows us to:
- do functional analysis for our reports
- ensure consistency and reuse between the different reports
- do impact analysis with regards to reporting when changing part of our logical information model

We do not model the technical analysis, nor do we use some kind of code generation.

Geert

[gb]

Great information from everyone.  I appreciate the feedback.  

I agree that modeling the reports just for the sake of using the tool is not very efficient.  However, we need to find a balance between trying to generate code that is going to be out of date as soon as someone modifies a report and ensuring that we have a good understanding of what each report is composed of.  

There are a number of tools on the market that produce "report documentation" but the reality is that most of them are highly technical and can not be used for management / end user review.    

I like the approach of using the User Interface to document what elements the report contains.  That will allow me to show the user what the report will look like (going forward) and then using the tool to document the Report Sets and Groups which can be handed off to the development group.  

The benefit I see for using this with existing reports will be for future changes to the reports.

Overall great feedback.  I appreciate it!