Go to www.designprowess.com/PI.
Generally organized in support of Common Profile.
Click on Reference View
Click on “Business Objects & Conceptual Architecture”
Business Objects make up the conceptual architecture. They are, of course, things that the business/mission know as things. If the business/mission knows about FOOs, the FOO is a business object and part of the Conceptual architecture.
From this point the business objects are transformed, ultimately into implementable classes.
A smidge of context. The thing you are looking at is a prototype for a UML Profile for Interoperability. More specifically, the Director of Nat. Intel sponsored interoperability. Two-three examples: Puget Sound Maritime (make sure ships entering W. Coast water are safe), E Coast of the same, what can only be described as “SWAT Team raid planning”, plus some disaster stuff (e.g., flooding in S.F. Bay area
One of the issues is context, and more specifically things like when some folk call a thing a “Phoo” others might call it a “Barr” And this all gets back to the fundamental thing that folk running the business (or mission) have their own language and, ultimately, we have to declare victory with everyone’d labeling proclivities. Hence, Foo-Bar is for-real.
So that’s a smidge of why Business Objects and why they have to trace to 1..* downstream thingies…
A quick scan of the spreadsheet suggests to me one of two things:
1. What I sent you is a new use case, or 2. What I sent you could be considered to encompass many of the use cases in the spreadsheet.
If you want the PI UML Profile prototype to be added to your spreadsheet as a use case I can do so. If you want to explore why I noted that the PI UML Profile might be considered as encompassing many, perhaps all, of your use cases I can expand on that, too.
The overarching need driving the creation of the model I sent you was to establish a basis for interoperability across and up-and-down governmental entities. As such, it picks up where NIEM-UML leaves off with the first problem being one of establishing business context and semantics. Therefore, a Business Object Model and an Ontology view point(plus a whole bunch more).
The reason driving the conceptual model being just a view with connections to lots of other things, including an ontology view, has to do with how to apply a common model to multiple kinds-of problems. To date, the model you looked at has been applied to Maritime ( East Coast and West Coast); planning SWAT team raids across government agencies (like county, city, state, and various national law enforcement entities all trying to “swat” the same guy/gal); and a couple other things.
So technically, it is not dissimilar to what a lot of organizations already do: create a resusable model that has stuff already built in that can be added-to, specialized, removed, … whatever. I, personally, built such a model a couple of times: once for usage in enabling state Medicare/Medicaid systems to name just one.
But, as you know, one person’s boot is another person’s trunk, in the simplest of cases, with more complex examples being exemplified by MES systems: when is a flat, round, metallic thingy with a hole in the center a washer versus it being a shim. Or a weld joint. Or even a counter weight (for-real examples, by the way). This results in a complexity for business objects that necessitates the declaration of a Business Object as being a set of characteristics. Hence, the association to a group technology derived ontology model.
So on and so on and so on.
I can send you more stuff, if you wish, above and beyond the model web site I gave you access too. For example, there’s an Interoperability “”white paper”” that goes into some of the drivers in much more detail.
One final point you might be asking yourself: why and I doing this? The reason I am involved is because of a contract between the DNI and the OMG.