A system is a combination of interacting elements that performs a
function not possible with any of the individual elements. The elements can
include hardware, software, bioware, facilities, policies and processes. A
system accepts inputs, over which it has no direct control, and transforms them
into outputs. A system should have a well-defined boundary. Fitting this single
definition are many types of systems, some have states and some do not.
Systems can be categorized as memoryless or dynamic. In a memoryless
system, the outputs depend
only on the present values of its inputs. Whereas, in a dynamic system
the outputs depend on the present and past values of its inputs. For dynamic
systems, we must define the concept of a state.
The state of a system makes
the system’s history irrelevant. The state of the system contains all of the
information needed to calculate responses to present and future inputs without
reference to the past history of inputs and outputs. The state of the system,
the present inputs and the sequence of future inputs allow computation of all
future states (and outputs). For example, the present balance of your checking
account can be the state of that system. This state could have gotten to its
present value in many ways, but when you write a check, that history is
irrelevant. But of course, your model depends on how you define your system.
Credit agencies would want to know how many times you had a negative balance
and the bank would want to know your daily balance in order to calculate your
interest.
Some dynamic systems are modeled best with state equations while
others are modeled best with state machines. State-equation systems are
modeled with equations. For example, a baseball’s movement can be modeled with
state equations for position, linear velocity and angular velocity all as
functions of time. State-machine systems focus less on physical variables and
more on logical attributes. Therefore, these systems have memory and are
modeled with finite state machines. Most computer systems are modeled with
finite state machines.
At each instant of time, a dynamic system is in a specific state.
State-equation systems can have one or many state variables: at any time, the
system’s state is defined as the unique values for each of the state variables.
State-machine systems can be modeled with one or many concurrent state
machines: at any time, each of the concurrent state machines must be in one and
only one state. A state is a unique snapshot that (1) is specified by
values for a set of variables, (2) characterizes the system for a period of
time and (3) is different from other states. Each state is different from other
states in either the inputs it responds to, the outputs it produces or the
transitions it takes. A transition is a response to an input that may cause a
change of state.
Some systems require both state machine diagrams and state equations. The
UML models state-machine systems with state machine diagrams. It does not have
a specific diagram for modeling state-equation systems. Instead, the state
equations are put into the use case package. In SysML, state equations are
modeled in parametric diagrams. State machines can be organized in hierarchies
made up of states, superstates, substates, concurrent states, and history
states. A system could be composed of several superstates each of which is made
up of several states. In this context, a mode would be a superstate, although
Mil STD 490 treated modes in the opposite fashion saying that states were
composed of modes.
Comment: The major
contribution of this effort is creating one simple statement that encompasses
both Linear Systems Theory and Finite State Machines. I have omitted the
concepts of observability, minimality, the need for exact models, open versus
closed systems, systems that cannot be modeled this way, the hierarchal nature
of the state machine tree, etc. However, I did not ignore these concepts. I
kept them in mind when composing the definitions.
Object-oriented and
Unified Modeling Language (UML)
A use case is an abstraction of a required function of a system. A use case produces an observable result of value to the user. A typical system will have many use cases each of which satisfies a goal of a particular user. Each use case is described by a sequence of interactions between one or more actors and the system. This sequence of interactions is described in a use case description and the relationships between the system and its actors are portrayed in a use-case diagram.
A use case description is written in a natural language. It is written as a sequence of numbered steps with a main success scenario and alternate flows. It contains the name of the use case, a brief description and the sequence of steps: it may also contain its level, the scope, the primary and supporting actors, preconditions, postconditions, the trigger, the priority, the frequency of use and the owner/author. The steps should be written in clear, concise, present tense, active voice.
Actors reflect roles of things outside the system that interact with the system. Primary actors initiate the functions described by use cases. Supporting (or secondary) actors are used by the system. They are not a part of the system, and thus cannot be designed or easily altered. They often represent external systems or commercial off the shelf (CotS) components.