OOPSLA Design Fest, 

Eric Hughes, recorder

Thursday, November 4, 1999

Disclaimer: none of the participants ever agreed on a single design.

For notetaking, I numbered the elements (E1-E6), assumptions (A1-A2),
requirements (R1-R9), desiderata (D1-D2), non-requirements (N1-N5),
and use-cases (U1-U7). Also, I couldn't possibly follow the
parallel conversations when the group fragmented into subgroups, but
tried to record that fact and note when the full group re-convened.

Event Logging Facility 1a (C102)

Members: William Volz, Vincent Jorrand, Lisa Ramsey, James Fagerlie,
Nicolas Gosselin, Albert Choy (moderator), Eric Hughes (recorder).

Got results of an Analysis Fest Team: Razavi et al.

Deliverable: two posters for panel tomorrow

Began with about ~30 minutes of reading of problem description and
analysis results.

Comment that the analysis separates data management (DM) from Event
Logging Facility (ELF).

Question of whether new kinds of events can be added in flight versus
by programmers.

In emergency situations, may want to add new types of events in
flight, but we may not be able to do this.

Position that ELF shouldn't know about event types at all.

Discussion of pieces (components, ideas) of the system:

Policies (below kinds may have similarities) 
Entry: whether to log an event 
Retention: how long to keep a logged event 
Event Signalling mechanism: a way for event to be signalled 
Policy Change Agent Logger

Question of whether retention policy (and data management in general)
should be part of our problem.

Discussion of whether signalling mechanism is part of ELF.

Realization that R5: events must be strongly typed, so ELF must know
about them.

Question of whether data transport is part of DM, and statement that
DM is read/write.

Discussion of how entry policy is rather generic (like debug levels)
but retention policy is domain-specific.

Third paragraph of analysis fest: data manager knows something about
the types it can store, and interface for changing retention policy
(which is implemented by DM).

Note that A2: don't have to do detail design of DM.

Thus, decision that we don't have to design retention policy object.

Discussion of Events

Question of whether adding an event type means recompiling.

Nomination of SpacecraftEvent and GroundEvent subclasses.

Position that EventIF should be all that the DM and logger need to
know.

Question of whether EventIF should have methods relevant to retention
policy and/or logger.

Question of whether we need an EventFactory.

ELF will essentially be factory for events.

ELF will have member for Entry Policy object.

Request from team for more paper, or better, whiteboards, next time.

Question of E3: filter on severity, frequency of occurrence - so
EntryPolicy is an interface and there may be many implementations.

Question of whether ELF::signal() should take an Event object.

Don't want to spend the time creating an Event object if it
won't be logged.

But do want to keep it simple (KISS principle).

Position that Event creation happens before handing to ELF.

Question by moderator of whether sensor has the full information needed to create an event.

Mention of R7: run-time efficiency.

Separtition of responsibility: ELF does the logging and EventFactory
decides whether to create object.

Decision for now to send event data to ELF rather than Event objects.

Question of who will create EntryPolicy objects (ELF or its clients).

Question of whether ground could send events to spacecraft ELF.

Analysis Fest rep says that they had a big argument over who's
responsible for retention policy.

Here, Daniel Dvorak (domain expert) answered questions - with other
ELF design groups present.

Desirable to not create event object if don't need it, so that
application developers won't worry about using ELF in their code.

Question of whether full event information is available before event
is sent to ELF (in whatever form).

Difference between event Type and ID: class hierarchy (so that entry
policy can disable hierarchies of events) vs ? [Daniel didn't
answer this until the group fragmented].

Some events have very little data (id and timestamp).

[The group fragmented about here are remained fragmented while Daniel
answered questions from our group and the other group.]

Logging happening both on ground and spacecraft, with interesting
things happening at both places.

Eventually want to see all events on ground, given limited bandwidth and memory.

Retention policy: memory might fill up when spacecraft is out of touch.

Need to be able to choose policy from ground somehow.

Event types are created at design time, not run-time, unless uploading
new software version (rare).

Do need to say what interface will be between ELF and DM (and thus
transport) - all feed from ground to spacecraft will be through DM.

The other ELF group asked for the analysis data, we denied for
experimental reasons.

[Group reconvenes from 3 sub-groups of 2 each.]

More heated debate over when to create the Event object.

Suggestion by moderator to have a single Event prototype object for
the handing off of the data.

Entry Policy: 4 decision points: type, id, severity, frequency.

Offer to define GenericEntryPolicy as the only entry policy implementation.

Position that need to create more kinds of policy classes.

Position that we are prematurely doing detailed design without whole system picture.

Walk-through of U3: Application Signals an Event

More heated debate over whether to optimize or just work with Event objects.

[I'll call the first solution U3-1 and the second U3-2.]

U3-1: pass Event objects and use Event Factory. Entry Policy and Logging Policy handled by ELF.

On question, logging policy changed to retention policy and moved to DM.

Question of whether Event class will have type attribute, leading to
question of whether there is 1:1 relationship between event types and
classes.

Actually hierarchy of Factories for Event types, as per design pattern.

U3-2: do away with Factory.

ELF calls factory/constructor with event data to create.

Language dependency on how to represent event data parameters.

Claim that domain expert said that event types and classes don't have
to match.

Example: type is power problem and ID is over-voltage on a given circuit.

Question of whether same {type,ID} implies same number of parameters.

Reflection being used? "Dark side coding".

Reminder that there is limited bandwidth between spacecraft and ground.

Consensus that ID is not instance ID.

R5: strongly typed events. Encapsulating object (typed) that holds the
parameters.

Just contents have to be strongly typed.

ShouldLog() (now shouldEnter()) doesn't imply that event will be
transmitted? Some disagreement.

Back to U3-1 vs U3-2.

Mention of D1: include source with each logged event.

Event Policy:

[I'll use (t,i,s) to represent type, ID, severity and (t,i,s,f) to
include frequency.]

Create policy object with (t,i,s,f). First three values define a
policy, frequency treated differently. FOO = frequency of occurrence.

Event policy manager has collection of these policies.

addPolicy() method on manager - if (t, i, s) match existing policy
then replace else add new.

More difficult discussion of memory efficiency of policy design.

[Fragmentation into 3 sub-groups of 2 each with parallel discussion.]

Counter-proposal to define a rule engine for this.

Expected matching on equality of type, possibly subrange on id,
definitely subrange on severity, temporal matching and frequency
calculation on FOO.

Discussion of use of associative array versus use of object semantics.

Proposal for Relationship object to combine (t,i,s).

Proposal to do associative list, nesting list of ID within list of type, etc.

Mention that severity is first thing to be checked.

Example:

Event type 1 - want to see all of these

Event type 2 - want to see all but warning

Need for ALL (wildcard) so you can match ALL Ids, ALL frequencies,
etc.

Question of whether this example is included in the requirements, and
whether it is reasonable.

Documentation to produce: class diagram

Event hierarchy with programmer extensibility.

Debate on whether type attribute of Event is required  deferred.

ELF has entry policy.

DM has retention policy.

Discussion of some sort of script for specifying new policy from the
ground.

[About here, the domain expert came back by.]

Question of policy behavior when adding a policy that is already
there.

Domain expert: operators are likely to control localized aspect of the
entry policy (might be type).

Example policy: log only severity yellow and red.

Domain expert: balance flexibility with simplicity of operational
control.

Domain expert: intended event type and class to be the same thing.

Want event class hierarchy matching types for collaboration with and
simplification of entry policy.

In the interest of time, decision to send event object to policy.

During writeup, discussion of whether ELF needs interface to update
retention policy.

Decision that retention policy goes direct to DM.

Retrospective.

Understanding the problem fast, with feedback from domain expert.

Discussion of whether problem was moderate or hard.

4 hours was not enough time, or with RAD maybe it was.

Debate over quality of GUI building tutorial.

Definition of interfaces very fuzzy, which led to confusion over what
the application was.

5 designers was too many, or maybe not.

Missing schedule school of thought: maybe we needed a strict schedule
to follow.

Good that we argued so we had intelligent discussions.

Don't want more than 6 people on a team.

Lots of inconsistent level of discussions was inefficient.

We didn't do a bad job, since we separated issues of signal/create vs
policy, or maybe that was obvious.

Different backgrounds so was understandable.

Ambiguity of problem statement.

Other teams had sticky paper!

[Recorder's comments:

I learned alot from participating as recorder, and now better
understand the DoD acquisitions I participate in. I'm sorry I couldn't
capture all your drawings and the details of all the discussions, but
tried to get the essence. As I skim through the problem statement
today, I think there was alot to keep track of (and I suspect that the
analysis data didn't help for that reason). For example, event
identifier is pretty well defined but hard to remember because it's
counter-intuitive. Maybe if we had assigned sub-teams with
responsibility for parts of the problem statement somehow, that would
have helped. I spent some time looking at the ELF solutions and though
ours was about average in terms of how far we got. ]