What is Process State Diagram?

In the systems where multiple processors or multitasking is involved, a process has to go through a number of states. In this article we shall discuss about these states. 

The kernel of the operating system may not recognize these states distinctly but still for the understanding of how the processes are executed they act as useful abstractions. 

These various states can be looked up in a process state diagram for a systematic view. This diagram shows the transitions of the process between various states with arrows. Processes can be stored both in the secondary or virtual memory and in the main memory as per the situation.

Process States

- The primary process states occur in all types of the systems. 

- Processes in these states are usually stored in the main memory. 

Basically there are 5 major states of any process as discussed below:

Ø  Created: 

- It is also known as the ‘new’ state. 

- A process occupies this state up on it creation. 

- While waiting for being admitted to the next ready state this process lies in this state. 

- The admission scheduler will decide whether to admit the process to next state or to delay it on a short or long term. 

- However, this admission is approved in an automatic way in most of the desktop computers. 

- But in the systems with real time operating systems this is not true. 

- Here, the admission might be delayed by a certain amount of time.

- If too many states are admitted to the ready state in a real time operating system, condition of over contention and over saturation might occur disabling the system to meet its deadlines.

Ø  Ready or Waiting: 

- This state is taken up a process when it has been loaded in to the physical memory of the system and is waiting to be executed by the processor or precisely waiting to be context switched by the dispatcher. 

- At any instant of time there might be a number of processes waiting for their execution. 

- Here the processes have to wait in a queue called the run queue out of which only one process will be taken up by a processor. 

- Processes that are waiting for obtaining input from some event are not put in to this ready queue.

Ø  Running: 

- When a process is selected by the CPU for execution, its state is changed to running. 

- One of the processors executes the instructions of the process one by one. 

- Only one process can be run by the process at a time.

Ø Blocked: 

- When a process is blocked because of some event such as I/O operations is put in to the blocked state. 

- Another reason for a process being a blocked state can be its running out of the CPU time allocated to it.

Ø  Terminated: 

- Termination of a process may occur when either its execution is complete or it has been explicitly killed.

- This state is called the terminated or halted. 

- This process is called a zombie process if after coming in the terminated state it is not removed from the main memory. 

There are two additional states for supporting the virtual memory. In these states the process is usually stored in the secondary memory of the system:

Ø Swapped out or Waiting: 

- A process is said to be swapped out when it is removed from the primary memory and placed in the secondary memory. 

- This is done by the mid - term scheduler. 

- After this the state of this process changes to waiting.  

Ø  Swapped out and Blocked:

- In some cases, the processes that were in blocked state might be swapped out. 

- The same process might be again swapped in providing the conditions remain the same.

Flow oriented Modeling - Creating a Control Flow Diagram and The Control Specification

Flow models focus on the flow of data objects as they are transformed by processing functions. There are applications which are driven by events rather than data and produce information that is controlled and process information keeping in mind the time and performance. In such situations, control flow diagrams comes into picture along with data flow modeling.

There are some guidelines to select potential events for a control flow diagram:
- all sensors that are read by the software are listed.
- all interrupt conditions are listed.
- all switches actuated by operator are listed.
- all data conditions are listed.
- all control items are reviewed.
- all states that describe the behavior of a system are listed.
- all transitions between states are defined.
- all possible omissions should be kept in focus.

The Control Specification contains a state diagram which is sequential specification of behavior. It contains a program activation table which is a combinatorial specification of behavior. Control specification does not give any information about the inner working of the processes activated as a result of this behavior.

What is Software Architecture ? What are subsystems and interfaces?

Software architecture defines a set of decisions about the organization. It includes:
- how to select structural elements.
- how to select their interfaces.
- how to select the behavior.
- how to select the composition of these structural and behavioral elements into larger subsystems.
- architectural style that guides this organization.
A software architecture is a description of the sub-systems and components of a software system and the relationships between them.
Software architecture is layered structure of software components and the manner in which these components interact.
A software architecture is modeled using package diagram of UML. A package is a model element that can contain other elements.
A subsystem is a combination of package and class. The advantages of defining subsystem are:
- Development of smaller units is possible.
- Re-usability increases.
- Handling complexity is managed properly.
- Maintainability eases.
- Supports portability.

An interface is a set of operations.
- Allows the separation of the declaration of behavior from the realization of the behavior.
- Serves as a contract to help in the independent development of the components by the development team, and ensures that the components can work together.
- There are two styles of communication subsystems use: client-server and peer-to-peer communication.

Architectural Design - Representing the System in Context and Defining Archetypes

As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.

REPRESENTING THE SYSTEM IN CONTEXT

Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.

How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.

DEFINING ARCHETYPES

Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller

Overview of The Interaction Model - Use cases, Sequence diagrams, State diagrams, User interface prototype

The interaction model of web applications enables a conversation between an end user and application functionality, content, and behavior. Interaction model is made up of four elements:
- Use cases
- Sequence diagrams
- State diagrams
- User interface prototype

Some use cases describe the interactions between end user categories and the system. Other use cases refine the interactions, providing the analysis detail necessary to guide design and construction. Use cases provide a one-dimensional view of the interaction.

Sequence diagrams are a shorthand representation of the manner in which dynamic elements(user actions) collaborate with the structural elements(analysis classes) of the system. There is a need to ensure that traceability exists between the classes that have been defined and the use-cases that describe system interaction. Sequence diagrams can be created for each use-case once analysis classes are defined for the use case. Sequence diagrams present a second dimension that is more procedural in nature.

As the interaction occurs, state diagrams are another way to represent the dynamic behavior of the web application. State diagrams can be represented at different levels of abstraction. State diagrams provide a third dimension that is more behavioral and contains information about potential navigation pathways that is not provided by use cases or the sequence diagram.
Large complex web applications benefits from interaction model that encompasses the three representations : use cases, sequence diagrams and state diagrams.


User Interface Prototype : The layout of user interface, content it presents, interaction mechanisms, and overall aesthetic of user-web application connections have much to do with user satisfaction and the overall acceptance of the web application. User interface prototype is performed during the creation of analysis model.