This will be the first in an ongoing series of posts in which I use UML to model and explore the structure of a story. This series started with a simple question: What constitutes a science fiction story? There are many answers to this question, including one very pragmatic definition: Science fiction is any story that a science fiction editor buys.
But I wanted a definition that would guide me in writing science fiction. In particular, I wanted guidance to avoid writing hackneyed stories, especially stories that editors hate: stories which are really non-SF stories dressed up in science fiction trappings. The classic bad example of these is stories which are western stories or pirate stories or gothic horror, but set in space or the future. And yes, that describes a few science fiction classics; but it also describes a lot of dreck.
So my working definition became: A science fiction story is a story where at least one element of the story could not exist or happen outside of a science fiction setting. The element might be a character or an event. It might be a setting, but probably shouldn’t, because that takes us back to Space Westerns. It might even be a motivation: if a character’s goal is to avoid being cloned, that goal makes little sense outside of a setting where cloning exists. (Of course, cloning could be a metaphor for loss of individuality; but metaphor and theme are in some ways “above” the layer of story elements.)
I like that definition. It’s practical. If I can’t identify the elements that can only exist in science fiction, then I should rewrite the story as straight fiction (or as a western, or a pirate story, or…). But to apply that definition, I realized that I need a good, fairly exhaustive model of the elements in a story. I could then use that to analyze my ideas and look for the SF elements.
And being that I’m The UML Guy, I built that model as UML diagrams.
This is an ongoing work in progress, so it has lots of holes. And though it is influenced by my readings on the theory and construction of stories, it reflects my own idiosyncratic views of story construction as well. And since I’ve only published a couple of stories and won some small awards so far, there may be really largeholes in my model. But I’m finding it useful, so I’m sharing it with you here.
Special thanks to Curtis Gray for asking me to share it. Otherwise, I wouldn’t be elaborating it this thoroughly.
Just Enough UML to Follow Along
I want to start by introducing just enough UML to help you follow along with the model.
The stick figure (an “actor”) represents someone or something that takes an active part in the model. It might be a person, an animal, a monster, a computer, a demon, a god, a ghost, etc. The important thing is that it acts (hence the name).
The rectangle (a “class”) represents a thing within the model that is used by or affects actors.
The arrow with a plain head (an “association”) means “has” or “uses”. The “0..*” means “0 or more”. So this diagram can be read as: “A Character has 0 or more Motivations.”
The arrow with the triangle head (a “generalization”) means a specific and a general case relation. So this diagram can be read as “A Book is a specific kind of a Publication.”
This “activity diagram” shows a set of steps in a process.
The black dot shows where the process starts. The “target” (black dot in a circle) shows where it ends.
The rounded rectangles (activities) show steps in the process. If the rounded rectangle has a link symbol (like Pick Up Food in this example), it is a complex step made up of sub-steps. You can show the sub-steps (as in this example) or hide them for a simpler diagram.
The arrows (“transitions”) take you from step to step.
And that’s all the UML you’ll need to know for now. I’ll introduce more as needed.
Of course, if you’d like to know more about UML, I’m happy to teach you through the world’s first UML comic strip.