[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: UBL / e-procurement-review
As you are aware, the UBL Library Content team is now working to finalise its data models for release to your review team. The diagrams you refer to were draft and have since been modifed, so the ones you will receive as UBL 0p80 will be different. However, I though it might be useful to fill you in on the use of 'packages' within our UML model. These logical groupings are entirely documentary in nature. that is, they are not manifested in the document schemas produced by UBL. They are provided to aid analysts looking at the library by providing a high level view. this is similar to your (a) to (f) views. We are not bound to these, nor do they provide any barriers to integration into the whole model. They are lines around a group of objects. The idea of using packages emerged from the use of diagrammatic notations (such as UML) to describe our model. We did use these in an earlier version but this was not followed through in the last release (0p70). We find them useful to focus smaller areas of the diagram into a scale that they fit onto A4 pages and can be easily comprehended by the reader. We welcome your comments as to their value in your analysis. Tim Benson wrote: >One of the first tasks of the UBL e-Gov review may be to develop the >consensus about the Packages used in UBL. Packages specify the natural >internal boundaries that allow us to break down the task into meaningful >chunks. Given consensus about these boundaries, we will be able to move >forward quite quickly. Time spent on this early on, to clarify assumptions >about these boundaries, is likely to save time later on. > >On Friday Tim McGrath (TM) sent out the latest UBL model including separate >diagrams for the following packages (in alphabetical order): > >1. Hazardous Item >2. Item >3. Party >4. Payment (this actually contains the Party diagram) >5. Procurement > >In addition the conceptual model has 3 additional packages (not named) which >cover: >6. Address of party >7. Delivery and shipping >8. Taxation > >Before making any further comments and suggestions, I would be very >interested to understand the history of the UBL packages. Were they there >at the beginning, or have they been added at a relatively late date? How >important is it for the UBL community that the existing package boundaries >be kept unchanged as corner stones of the whole project, or are they simply >there for convenience? How much debate has gone into the specification of >the package boundaries? What practical consequences would follow from >moving a class from one package into another, or merging two packages? > >Our own work for OGC in UK (the OGC model) also uses a similar number of >packages with broadly similar composition, in this case: >Six packages are generic - >(a) Data types - this contains all of the data types used in the model (at >the level of format and string length) >(b) Document - contains general information about each document, including >document identification and meta-data >(c) Financial - contains financial information, including document prices, >charges, discounts, taxation and rates of exchange, applicable at both >document and line levels >(d) Item - contains information about goods or services procured >(e) Line - contains the structure of each line on a document >(f) Party - contains information about each party (person or organisation). > >The next 2 packages relate to different contexts (flavours) - >(g) Tutti-Frutti (all fruits) - contains messages that meet the more complex >general requirements to meet best buying practice for the public sector, >including international transactions >(h) Vanilla - the simplest messages that meet the requirements for automated >processing of most straightforward transactions. > >There is no right or wrong way to package up any model, but there are some >well established principles such as: > >- Decomposition into packages which can be pursued separately >- Composability so that the packages can be used independently >- Understandability so that a human reader can understand each package >without reference to others >- Continuity so a change in one package only affects that package >- The number of links between packages should be as small as possible. > >These principles could provide some criteria for looking at the packages, >preferably one at a time. I would suggest starting with Party and Item. > > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]