Modeling a Report in a Domain Model

[Dorian Workman]

I need to model a Report object.  As with any Report, it will have a few attributes of its own like Report Name, Report Date, etc.  But the rest of its attributes are pulling data from attributes of other domain objects.

How do I correctly model these "non-native" attributes?  Should I use the Type field to indicate the class and attribute from where this info should be sourced?

Thanks.

[Dorian Workman]

I might have found the answer in this post of Geert's: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1260229964/2#2

Does my situation fall into his third bullet of an "Inter-Class Constraint"?  Sounds like it does.

[Geert Bellekens]

Dorian,

I wouldn't use constraints for that.
The way I see it reports are very much on the same level as GUI screens or messages that you sent to other applications.
They somehow represent the core data of your system.

Usually there are three layers involved in modelling something like this:

• The GUI/Message/Report itself

In theory these elements have (almost) nothing then derived attributes because they can be calculated from the information in the "lower" level. Because all of the attributes are derived here you might as well leave that implicit, but that is up to you.

• The DTO (Data Transfer Object) layer

DTO are elements that group data in order to be transported (to the GUI, a Report, a Message,...)
Again these contain data coming from the lower level, so nothing but derived attributes

• The logical or System Information Model

Here you will find the core data. These are the entities the backend works with like the "account", "order", etc...
[/list]

Between the layers there is a "mapping" e.g. the way the attributes are derived from the layer below.

At my current client we tend to describe only the E2E mapping, so from the field in the GUI/Message/Report to the attribute in the SIM.

You could describe the mapping in EA, but we choose to document that in an external Excel file. (linked to EA to validate the entities/attributes)

Geert

[Paolo F Cantoni]

I need to model a Report object.  As with any Report, it will have a few attributes of its own like Report Name, Report Date, etc.  But the rest of its attributes are pulling data from attributes of other domain objects.

How do I correctly model these "non-native" attributes?  Should I use the Type field to indicate the class and attribute from where this info should be sourced?

Thanks.

Hi Dorian,

To some extent the answer depends on what you mean by Report.  A while back we did a proof of concept exercise where we created a metamodel of a Report (by this I mean the kind of thing a user requests - has name, queries, renderings etc.  This was specified at the DIM (Domain Independent Model - a level above the OMG CIM).  Instances of Reports were then specifiable at the CIM (Computationally Independent Model - Conceptual) Level.  These Conceptual specifications could then be transformed to more physical ones down. the model levels.

To develop the DIM model we started off with the Microsoft SSIS RDL (Report Definition Language), reverse engineered that then converted it via transformation to a set of classes and then abstracted those.  This meant we had a unified model that allowed us to specify the reports at a highly conceptual level and then eventually convert them to SSIS RDL , or Crystal Reports or Oracle Reports etc

This model allowed us to reuse specifications at all levels:
All these reports have this security specification,  all those use this same datasets, of those this subset use the following common renderings etc etc...

We could even create PDF report specification documents directly from the model - that looked just like (actually better) than hand crafted ones.  So, in theory, the model drove both the specification document and the specification (in RDL).

Paolo

[Dorian Workman]

Yes I gathered from Geert's response that my term Report might be ambiguous.

When the user clicks a certain button, we need the system to pull together various pieces of information and submit them to an external system. We need our system to keep a permanent record of this submission, including what info was submitted, when, and by which system user, and we need the user to be able to pull this back up at any point in the future.

So I think this is a little different to what Geert is describing, and I do think I need to model this in my domain model.

So I'm thinking I'd like a Class for this "Report" with attributes, and I need to indicate for each attribute its information source (being an attribute on another class).

Do you agree this is the right approach?  And if so, should I use a constraint on each Report class' attribute to specify its source class and attribute?

Thanks.

[Paolo F Cantoni]

Yes I gathered from Geert's response that my term Report might be ambiguous.
[size=18]...[/size]

Unfortunately "Report" is one of those magic words (like "Plan") whose definition wavers like a flag in a breeze.

From your "clarification" I'm a bit more confused about what your trying to model (but then I will affirm that I'm a bit of a pedant).

When a user/client uses the term "report", the first problem I have is:
Do they mean:

• the conceptual specification of the report?
  
• the manifestation of that specification in some Report Definition Language for a particular technology?
  
• the execution of that manifestation as a specific execution of the Report Definition with a set of input parameters against a specified datastore in a certain state?
  
• the instantiation of that execution as a snapshot into a datastore or a piece of paper - persisted in some way?

Complicated isn't it?

How about we start with as clear a definition of "Report" (not how it's used, but what it IS) in your domain -  and then we can help.

For example, the simplest definition I can come up with is:

A tabular output where the columns are defined in terms of values from a defined datasource (including calculations), and the rows are specified by a filtered view of one or more datasources.

HTH,
Paolo

[Geert Bellekens]

Dorian,

It looks like indeed you could have several different classes representing the different aspects of a "Report".

You'll have the ReportRequest logical entity which is used to manage when and by whom the reports are requested. I'm guessing you will have attributes like "date taken" and an association to the user who requested the report.

Then you'll have the DTO classes who represent the grouping of data in the report.

Then at last you could have the report specification itself, which we consider as an external specification. This means that we do not manage the report itself, but only include it in our model for traceability reasons.

Geert

[son-of-sargasso]

Hang on, don't want to sound like a broken record ... but what's the use case?

Reqt3014: "the system must produce a daily report, on demand or sooner, of all zebras crossing the giraffes path and requiring more than 35 litres of unleaded fuel together with a giraphcal summary of all eskimos in the region."

I hope your case is better.

[Dorian Workman]

Hang on, don't want to sound like a broken record ... but what's the use case?

I think I clarified that in a post above:

"When the user clicks a certain button, we need the system to pull together various pieces of information and submit them to an external system. We need our system to keep a permanent record of this submission, including what info was submitted, when, and by which system user, and we need the user to be able to pull this back up at any point in the future."

[Dorian Workman]

Dorian,

It looks like indeed you could have several different classes representing the different aspects of a "Report".

You'll have the ReportRequest logical entity which is used to manage when and by whom the reports are requested. I'm guessing you will have attributes like "date taken" and an association to the user who requested the report.

Then you'll have the DTO classes who represent the grouping of data in the report.

Then at last you could have the report specification itself, which we consider as an external specification. This means that we do not manage the report itself, but only include it in our model for traceability reasons.

Geert

Thanks Geert this is what I suspected.  Appreciate your help!