Scott Nieman unable to attend ebXML in San Jose

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

I regret to inform everyone that I will NOT be able to attend the ebXML
meeting in San Jose next week.  I have been asked by my company to present
at several sales meetings regarding large opportunities for Norstan
Consulting.

I have been in contact with several people regarding this issue,
specifically in attempt to find someone that can lead the registry and
repository team in my absence.  I hope that we can find someone with an
understand of the complexity of the registry / repository effort, very
familiar with UML, and project management.  If you would like to volunteer
to lead the group next week, please respond to this email.  If you feel that
you would like to permanently become a vice/co-project lead (whatever the
current term is), I would welcome the thought.

Next week we have some critical steps:
1) finalization of the second draft of Part1: Domain
2) start of PartII: Requirements.  I have already started the use case
analysis for each package in the package diagram highlighted in Part1.  Each
use case will have an associated activity diagram that details the workflow
that realizes the use case.  Each activity within the activity diagram
should have an action assigned to it and an object flow state of what that
activity produces.  Each object flow state can be collected to create our
first object model that will likely start to define the metadata for the
registry and other state machines required for interaction with the registry
and repository.  That in a nutshell, with the prose to discuss the model,
will be the composition of Part2.  
3) Based on a prioritization of which packages should be worked on, subteams
should be formed to drill down into these packages.  I would suggest that
the Registry service and the query service be the top priorities.  Each
subteam should define the flow, if only by a flowchart on a napkin, of how
the use case should be realized.  This flowchart can easily be transformed
into an activity diagram.
4) The prioritization of these packages should be confirmed with the POC
team.  I strongly believe via the approach mentioned in 2) that we can begin
to develop prototype interfaces to components quickly if we go with the
assumption that the action on the activity diagram can be an operation on a
component interface (<<interface>> stereotype specifically).  A prototype
class diagram for several of these actions can be developed to define the
signature of the operation to begin to prototyping.  It will likely be
throwaway since Part3: Analysis will refine the object model into a class
diagram that reflects the system in more detail.  It will also include the
state machines and sequences diagrams that carry out the work defined by the
operation.  Part 4: Design will provide the component design only to the
point of finalizing the signature of each operation for the various
envisioned components (which of course can be transformed directly in XML
Schema, right?).

I will be monitoring the lists at night, so if there are some questions,  I
will try to answer as soon as possible.  

Sorry for the inconvience,

Scott
scott.nieman@norstanconsulting.com
952.352.5889