And now for something completely different

My wife's bluetooth headset uses a non-rechargable AAAA battery.  Right.  Where do you get AAAA batteries?

Answer: ask the web; it knows everything.  And it says "inside a 9-volt battery".

I slipped a letter opener under the bottom edge of a new 9-volt battery where the metal meets the cardboard and lifted up a corner.  Then, with a pair of pliars, I peeled off the cover.  Here's what I found:

The batteries are held together with a bit of blue shrink-wrap, which I sliced off:

Now they come apart like an accordian.  They're held together with spot-welded straps.

By gently pulling them apart, each battery came off with one or two bits of joining strip; gently pulling THAT off with a pair of pliers gave me 6 batteries and some scrap.

After lightly filing off the sharp corner left by pulling off the welded strap, I had 6 AAAA batteries for about $2.

:)

What Executes?

One problem executable design tools face when parsing and executing a design is "what do I execute"?

During the creative process, you tend to work with diagrams rather than class or object definitions. If you're fairly messy, as I am, you may end up with an underlying model containing lots of objects, classes, and relations which don't show up on any diagram, but which the tool created as you were adding things to the model.  You may also end up with different objects with the same name on different diagrams--class diagram 1 contains a class called "Person", and diagram 2 contains a class called "Person" with some of the same attributes and methods as the first, but internally, the UML design tool has created two separate Person classes, not one.  How does the execution engine know which one to execute--or did the designer want both?

I want to use the "diagram" as the control.  If something shows up in an underlying model, but not in a diagram, it's ignored by the execution engine. Oh, I want it listed somewhere when the model is parsed for execution, but I don't want it showing up in my executing code.  I used the diagram to communicate with developers, not the hidden underlying model--so that's what expresses my intent as a designer.

What're the drawbacks of this approach?