Chapter 2

Overview of OCTOPUS Method

1
OCTOPUS Method
● OCTOPUS method merges object-oriented methods and real-time systems.

● Specifically designed for developing software in embedded real-time systems.

● Adoption of object-oriented technology offers benefits such as extendibility,

reuse, and robustness.

2
WHY OCTOPUS METHOD?
1) Combines object-oriented methods with real-time systems, allowing for a
systematic development approach.
2) Leverages the advantages of object-oriented programming, such as
modularity, reusability, and ease of maintenance, in the context of real-time
applications.
3) Recognizes concurrency as an inherent feature in the domain of embedded
real-time systems.
4) Provides a structured development process, dividing it into system and
subsystem levels.

3
 Applications of Octopus Method
Projects In Telecommunication - WHY?????????????

1) Real-Time Emphasis: The OCTOPUS method is specifically designed for embedded real-time systems,
aligning well with the time-sensitive nature of telecommunications applications where rapid data processing
and response times are crucial.
2) Concurrency Management: Telecommunication systems often involve simultaneous processes such as
handling multiple calls or managing data streams. The OCTOPUS method's explicit treatment of
concurrency provides a structured approach to manage and control concurrent activities efficiently.
3) Isolation of Application from Hardware: The method introduces the concept of a hardware wrapper,
which isolates application subsystems from the hardware. This isolation enhances flexibility, allowing the
software to adapt to different hardware configurations common in telecommunications infrastructure.

4
Development Process Structure

- System Phase
- System Requirements Phase
- System Architecture Phase

- SubSystem Phase
- SubSystem Analysis Phase
- SubSystem Design Phase
- SubSystem Implementation Phase

5
 OCTOPUS METHOD STRUCTURE

- System Phase
- System Requirements Phase
- System Architecture Phase

- SubSystem Phase
- SubSystem Analysis Phase
- SubSystem Design Phase
- SubSystem Implementation
Phase

6
System Phases
1) System Requirements Phase

Objective: The primary goal of the System Requirements Specification phase

is to define and document the functional and non-functional requirements of
the embedded real-time system.

This phase sets the foundation for the entire development process by
outlining what the system is expected to achieve and the constraints it must
adhere to.

7
 UseCase Diagram:
System Phases
Purpose: Use case diagrams focus on the
1) System Requirements Phase functional requirements of the system by identifying
and illustrating different use cases and their
Key Activities:
relationships.
1) UseCase Diagrams: Usecase Representation: Actors (which can be users or
diagrams may be employed to visually external systems) and use cases (representing
depict the relationships and specific functionalities or interactions) are depicted,
interactions between different use along with relationships between them.
cases. These diagrams help in Elements:
understanding the system from a Actors: Entities that interact with the system.
high-level perspective. Use Cases: Specific functionalities or interactions
that the system provides.
Associations: Lines connecting actors to use
cases, indicating the interactions between them. 8
 Purpose: A context diagram provides a high-level
System Phases view of the system and its interactions with external
entities or systems.
1) System Requirements Phase Representation: It typically consists of a central
system surrounded by external entities, representing
Key Activities: the environment with which the system interacts.
2) Context Diagrams: Elements:
System: The main focus, often represented as a
The context diagram helps circle or box in the center.
stakeholders understand the overall External Entities: Entities outside the system with
scope of the system and its external which it interacts. These could be users, other
relationships. systems, or hardware devices.
Interactions: Arrows or lines depict the flow of
information or data between the system and external
entities.
9
Example of a System Context Diagram
10
System Phases
2) System Architecture Phase
Objective: The System Architecture phase aims to structure the overall development
process by defining the high-level architecture of the embedded real-time system. This
involves decomposing the system into subsystems and specifying the interfaces
between these subsystems.
Key Activities:
1) Subsystem Decomposition: The large system is broken down into smaller, more
manageable subsystems. These subsystems represent functional units of the system,
each with its own specific responsibilities.
2) Subsystem Interfaces: The interfaces between subsystems are clearly defined. This
involves specifying how subsystems will communicate and interact with each other.
3) Hardware Wrapper Subsystem: The concept of a hardware wrapper subsystem is
introduced. This subsystem serves as a protective layer, isolating the application
software from the actual hardware and the external world.
11
2) System Architecture Phase
● Breaking down the system into subsystems can potentially shorten the time
required for software project completion as subsystems can be concurrently
developed.
● This approach also encourages reuse at a more impactful level compared to
individual classes.
● A thoroughly designed subsystem has the potential for reuse in other
systems.

12
2) System Architecture Phase

● Challenges:
● Breaking down a system into subsystems comes with inherent challenges.
● It requires defining clear interfaces between these subsystems.
● Consequently, relying on subsystems with high interdependence may not be a
justifiable approach.
● Developing a substantial software system should occur incrementally.
● These increments are implemented based on their relative importance.
● The primary increment, representing the core functionality, is prioritized for
initial implementation.

13
2) System Architecture Phase
● Additional increments can be integrated with those implemented earlier,

gradually culminating in a fully functional system.

● Software for embedded systems commonly operates on non-standard or

semi-standard hardware.

● The software design should not be dictated by the hardware's structure.

14
2) System Architecture Phase

● OCTOPUS employs a software layer called the hardware wrapper to encapsulate

the underlying hardware.
● Within the hardware wrapper, various objects are present to manage
ASICs(Application-specific integrated circuit) and diverse chips and peripherals.
15
2) System Architecture Phase
● These objects have the capability to send outputs to these devices and

receive inputs from them.

● This interaction is facilitated through either polling or interrupts.

● The hardware wrapper encompasses interrupt service routines.

● Additionally, other objects within the hardware wrapper offer services to the

application subsystems.

16
3.1) SubSystem Analysis Phase
Emphasis/ Steps of SubSystem Analysis Phase:

1) Object Oriented Analysis

2) Model by Model Description

3) Functional and Dynamic Model Description

4) Complexity Management

5) Significance Table

17
3.1) SubSystem Analysis Phase
Object Oriented Analysis:

● The subsystem is seen as a composition of objects in all object-oriented

analysis models.
Consider an automatic traffic control system. In this system, objects could
include vehicles, traffic signals, and pedestrian crossings. Each object
(vehicle, traffic signal) encapsulates specific properties and behaviors,
contributing to the overall functionality of the traffic control subsystem.

18
3.1) SubSystem Analysis Phase
Object Oriented Analysis:

● Analysis objects are specified solely through their classes, with no

differentiation between a class and an object of that class.
● Analysis objects represent the concepts of the problem domain.
● These objects mirror real-world entities and their relationships, helping to
model and solve problems effectively.

19
3.1) SubSystem Analysis Phase
Model-by-Model Description:

● The analysis phase is broken down model by model.

● The object model defines the static structure of the application, detailing
objects, relationships, and relevant attributes.
● Consider the development of a real-time medical monitoring system. In the
analysis phase breakdown, one model might focus on patient data, another
on sensor integration, and a third on alarm and notification systems. Each
model contributes to a comprehensive understanding of the system's
requirements and structure.

20
3.1) SubSystem Analysis Phase
Model-by-Model Description:
● The class diagram notation is standard for expressing the object model
graphically.
● The class diagram depicts the boundary between the subsystem and its
environment.
● It visually represents classes, objects, relationships, and attributes, providing
a clear and standardized way to communicate the system's structure.
● Consider an aviation control system. The class diagram could depict classes
like "Aircraft," "AirTrafficController," and "Runway." The diagram visually
communicates how these classes relate to each other, illustrating the static
structure of the aviation control subsystem.

21
 3.1) SubSystem Analysis Phase
Model-by-Model Description:

● The class diagram, within the

object model, is utilized to depict
the boundary between the
subsystem and its environment. It
helps define what is encapsulated
within the subsystem and what
interacts with the external
environment.

Fig. Simplified Cruise Control Class Diagram 22

3.1) SubSystem Analysis Phase
Model-by-Model Description:
● The class diagram notation is standard for expressing the object model
graphically.
● The class diagram depicts the boundary between the subsystem and its
environment.
● It visually represents classes, objects, relationships, and attributes, providing
a clear and standardized way to communicate the system's structure.
● Consider an aviation control system. The class diagram could depict classes
like "Aircraft," "AirTrafficController," and "Runway." The diagram visually
communicates how these classes relate to each other, illustrating the static
structure of the aviation control subsystem.

23
3.1) SubSystem Analysis Phase
Functional Model:

● Describes the functional interface of the subsystem, consisting of named

services provided to other subsystems and external agents.
○ The functional model elucidates the functional interface of the subsystem, presenting a clear
picture of the services it offers to other subsystems and external agents. It focuses on what the
subsystem does in terms of provided functionalities.
○ In a home automation system, the functional model may describe services like "Temperature
Control," "Security Monitoring," and "Lighting Automation." These services represent the
functional interface that the subsystem offers to users, other devices, or external applications.

24
3.1) SubSystem Analysis Phase
Functional Model:

● Describes the functional interface of the subsystem, consisting of named

services provided to other subsystems and external agents.
● Operations are outlined in operation sheets but do not specify dynamics or
timing details.
○ The functional model outlines operations in operation sheets, detailing the specific activities or
functions that the subsystem can perform. These sheets act as documentation for
understanding the functionalities provided by the subsystem.

25
Fig:
Operation Sheet

26
3.1) SubSystem Analysis Phase
Dynamic Model:
● Describes the real-time, reactive aspects of subsystem operation.
● Explains conditions under which operations are performed, their duration,
order of interactions, and their impact on each other.
● Steps in dynamic modeling include analysis of events, states, further analysis
of events and states, and validations.
● In a smart grid system, the dynamic model may outline how the system
responds to fluctuations in energy demand. It would specify conditions
triggering adjustments in power distribution, the duration of these
adjustments, and how various subsystems interact to maintain a stable power
supply.

27
28
EVENT SHEET DETAILS:
3.1) SubSystem Analysis Phase
● Complexity Management:
● Large numbers of distinct events are managed by grouping them into
superevents.
○ In complex real-time systems, there may be a large number of distinct events that the system
needs to handle. Managing these events individually can lead to increased complexity in the
system design and maintenance.
● Superevents may have subevents and belong to higher-level superevents.
○ To address the challenge of managing numerous events, a strategy involves grouping them
into higher-level constructs known as superevents. Superevents serve as containers for
related events, simplifying the representation and handling of complex event scenarios.
● A unified event sheet is used to describe events, minimizing redundancy.

29
Fig.: Example of Grouping of Events
30
3.1) SubSystem Analysis Phase
● Statechart Modeling:

● Statecharts are built at different levels of detail to enhance understanding of

complex state-dependent behavior.
● Significance tables are created for events against elementary states,
specifying their importance.

31
3.1) SubSystem Analysis Phase
● Significance Table:
● The analyst builds a significance table, assigning values such as Critical,
Essential, Ignored, or Neutral to events based on their impact in different states

32
3.2) SubSystem Design Phase
Transition from Implicit to Explicit Concurrency Model:

● During the design phase, there is a deliberate shift from the implicit
concurrency model used in the analysis phase to an explicit concurrency
model.
● Objects are mapped to processes within a traditional operating system,
highlighting the move towards a more structured and controlled concurrency
approach.

33
 3.2) SubSystem Design Phase
Transition to Explicit Concurrency Model (Design Phase):

In the design phase, the implicit concurrency is made explicit. For the traffic signal control system, this
involves identifying concurrent activities such as monitoring traffic flow, adjusting signal timings, and
responding to sensor inputs.
Mapping Objects to Processes:

Objects, representing elements like traffic lights, sensors, and control logic, are mapped to processes
within a traditional operating system.
Each object or a group of related objects is associated with a separate process. For instance, a
process could be responsible for managing the state and timing of a specific traffic light.

The mapping of objects to processes highlights a move towards a more structured and controlled
concurrency approach.
Processes can be independently scheduled, and interactions between them are well-defined. This
explicit concurrency model provides a clear understanding of how different components operate
concurrently, improving the system's predictability and responsiveness.
34
 1. Implicit Concurrency:
● Concurrency is not directly managed or visible in the system. The system may execute multiple tasks in parallel,
but the concurrency is hidden behind the scenes, typically handled by the operating system or the runtime
environment.
● In a microcontroller-based system, multiple tasks (e.g., reading sensors, controlling actuators) may run concurrently,
but the developer doesn't explicitly define or control how tasks are scheduled or executed.
● The system handles it internally without the programmer’s intervention.
● Characteristics:
○ Concurrency is not well defined by Developers
○ Tasks are implicitly parallel (handled by the OS or runtime).
○ Less control over timing and scheduling.
○ Potentially less predictable due to implicit management.

2. Explicit Concurrency:
● Concurrency is clearly defined and managed within the system. The developer explicitly specifies how tasks should
run concurrently and may control scheduling, synchronization, and communication between tasks or processes.
● Conversion of Implicitly implied sensors and actuators of a Smart Home System:
○ Separate processes for handling temperature sensors, light sensors, and control logic are explicitly created.
Each process runs independently, and the developer manages how they communicate and synchronize.
● Characteristics:
○ Concurrency is visible and controlled by the developer.
○ Tasks run in explicitly defined processes or threads.
○ More control over execution, scheduling, and synchronization.
○ Improved predictability due to clear management of task execution.
Major Steps in the Design Phase
1) Designing Object Interaction Threads and discussing the initiation of Event
Threads
a) Design Object Interaction Threads
b) Based on the analysis models, design object interaction threads.
c) Combine and expand these threads until they evolve into event threads.
d) Simultaneously, record details in class outlines.
2) Communication Mechanism
3) Verification and Balancing

35
Major Steps in the Design Phase
Object Interaction Threads:
Sensor Data Collection Thread:
One thread involves sensors collecting data, like temperature, humidity, and wind
speed. Sensors include devices like thermometers and anemometers.
Data Processing Thread:
Another thread focuses on processing the collected data. Algorithms analyze the
information to detect weather patterns and trends.

36
Major Steps in the Design Phase
Combine and Expand Threads:
Weather Analysis Thread:
Recognizing that data collection and processing are closely related, we combine them
into a comprehensive "Weather Analysis" thread.
Designing object interaction threads helps break down the system's functionality into
manageable components, such as data collection and processing. This provides a
structured approach to understanding how different parts of the system work together.
Combining and expanding object interaction threads allows for the identification of key
events within the system. In the example, the "Storm Alert" event is recognized as a
significant occurrence that demands a specific response.

37
Major Steps in the Design Phase
Communication Mechanism:

● Evaluate each interaction between objects and events.

● Decide on the communication mechanism; asynchronous interactions
become interprocess messages, and synchronous interactions become
member function calls.
● Group objects and outline processes are associated with these object groups.

38
Major Steps in the Design Phase
Verification and Balancing:

● Verify the designed event threads by removing inconsistencies.

● Balance design decisions.
● Determine how to synchronize access to shared objects.

39
Role of Analysis Method in Design Phase
Events initiate threads,

objects are instances derived from class diagrams,

operation sheets define object responsibilities, and

statecharts behave like other objects within event threads.

Tools like CASE (Computer-Aided Software Engineering) tools designed to assist

in various phases of the software development life cycle.

40
SUBSYSTEM GRAPH

41