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.