Chapter 5

System Analysis
1
System Analysis

Definition

● System Analysis is a problem-centric phase in system development that

examines requirements, validates specifications, and builds a descriptive
model of the system and its environment.
● The analysis focuses on understanding the problem, using declarative
notations, and employing a computation model to establish the system's
structure, functionality, and dynamics.

2
System Analysis Approaches
1) Problem-Centric Approach:
● In a cruise control system for a car, the analysis phase would focus on issues like
maintaining a constant speed, adapting to changes in road conditions, and optimizing
fuel efficiency. Identifying and addressing these problems ensures a reliable and
efficient cruise control functionality.
2) Model Development:
● During the analysis phase of the cruise control system, a model might be developed to
represent the relationships between components like vehicle speed, throttle control,
and sensor inputs. This model helps visualize how the system should operate in
different driving conditions, ensuring a smooth and responsive cruise control
experience.
3) Object Model and Viewpoints:
● For the cruise control system, the Object Model could include structural views (objects
like SpeedSensor, ThrottleController), functional views (methods for adjusting speed),
and dynamic views (how the system responds to changes in speed or user input).
These viewpoints guide the development team in capturing the complexities of a
real-time system like cruise control. 3
System Analysis

Focus on Problem Understanding

● The analysis phase is centered on understanding and addressing the problems

that need to be solved within a system.
● Inspection of requirements specification and the application domain is crucial
to building a model that represents the system and its environment.

4
System Analysis

Clarification and Validation of Requirements:

● During the analysis phase, there is an emphasis on clarifying and validating the
requirements specified for the system.
● The goal is to document a comprehensive understanding of the problem, using
terms from the problem domain rather than those of the solution.

5
System Analysis

OCTOPUS Modeling Structure:

● OCTOPUS adopts the same high-level structure as Object Modeling Technique

(OMT).
● The system is modeled from three different viewpoints: structural, functional,
and dynamic, each utilizing appropriate notations.
● The structure model, also known as the object model, is central to the analysis
and defines the terms for other models.

6
System Analysis

Object Model and System Structure:

● The object model reveals the structure of the problem, depicting objects in the
domain and their relationships.
● Class descriptions and class diagrams describe classes and their relations,
including the boundary between the subsystem and its environments.
● This model is fundamental to the analysis process, serving as the basis for
other models such as functional and dynamic models, which will be detailed
further in the subsequent chapter.

7
Object Modeling Technique (OMT)
● Object modeling in software engineering is the process of constructing
abstract representations, known as models, to depict real-world entities
through the use of objects.
● Objects, which encapsulate both data and behavior, are instantiated based on
classes that function as templates or blueprints.
● This methodology is an integral part of object-oriented analysis and design,
providing a systematic approach to organizing, abstracting, and visualizing
complex systems in software development.

8
Object Modeling Technique (OMT)
● Purpose of OMT:
1) Abstraction:
● Models provide a simplified and abstract representation of complex
systems, helping developers focus on essential aspects while ignoring
unnecessary details. This abstraction aids in understanding and managing
system complexity.
2) Communication:
● Models serve as a visual and conceptual communication tool between
different stakeholders involved in the software development process. They
help bridge the gap between technical and non-technical team members,
ensuring a common understanding of the system.
3) Visualization:
● Modeling allows developers to create visual representations of software
systems, making it easier to grasp the structure, relationships, and
interactions among various components. Visual models enhance
comprehension and facilitate discussions about design decisions. 9
Object Modeling Technique (OMT)

● Purpose of OMT:
5) Analysis:
● Models support analysis by providing a basis for evaluating the
feasibility, efficiency, and effectiveness of different design alternatives.
Through analysis, developers can identify potential issues early in the
development process, leading to better-informed decisions.
6) Design Guidance:
● Models act as a guide during the design phase, helping developers
make informed decisions about system architecture, component
interactions, and overall system behavior. They serve as a blueprint for
translating high-level requirements into concrete implementations.
10
Object Model

● Object Model assists OMT by visualizing and designing of any

software systems using objects that are implemented in the system
● Object Model define system with objects and classes.
● Static representation of objects and relationships.
● Helps in:
○ User Interface
○ Architecture, and such software engineering components
● Object orientation helps cope with the complexity of the system
● Object Model is represented with object diagrams
11
Object Model

● Four Mandatory elements of Object Model:

1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy (Inheritance)

12
Object Model

● Object Diagram can be described as a “Snapshot” of a running

system at a certain time interval/ instance.

13
14
15
Cardinality

16
17
18
Object Model and Class Diagram in System Analysis
● Importance:
● Conceptual Abstraction and System Understanding:
They play a crucial role in providing a high-level conceptual
abstraction during the analysis phase, aiding in the understanding
of the system without delving into implementation details.
● Requirements Exploration and Representation:
The models serve as a powerful tool for exploring and
representing system requirements, helping analysts identify key
entities, attributes, and interactions in a structured manner.
19
● Importance:
● Effective Communication Through Visual Language:
They act as a visual language that facilitates effective
communication between diverse stakeholders, bridging the gap
between technical and non-technical individuals involved in the
software development process.
● Flexible Iterative Refinement of System Specifications:
They offer flexibility during the analysis phase, allowing for
iterative refinement of system specifications as requirements
evolve or become more refined. Their adaptability supports
changes in the understanding of the system. 20
Dividing Class Diagram for System Analysis

- Hierarchy, Generalization and Aggregation

- Hierarchy:
- Hierarchy means organizing things in a system based on their
importance and complexity..
- Aggregation:
- Aggregation is a relationship between entities where one entity
(the whole) is composed of or has parts, and the parts can exist
independently of the whole.

21
Dividing Class Diagram for System Analysis

- Generalization
- Generalization is a relationship between entities where one
entity represents common characteristics of one or more other
entities .

22
Dividing Class Diagram for System Analysis

- Generalization establishes a hierarchy of classes based on their

commonalities, while aggregation facilitates the organization of
classes into meaningful parts and wholes, adding depth to the
hierarchy.
- Together, they enhance the conceptual clarity, maintainability,
and scalability of class diagrams in representing complex
systems.

23
Dividing Class Diagram for System Analysis

Fig.: Composition of Test as Local Hierarchy

24
25
Local Hierarchy

- A local hierarchy, in the context of software development and

modeling, refers to a specific and limited structure of
relationships among classes or objects within a well-defined
scope or subsystem of a larger system.
- It is a subset of the overall system hierarchy, focusing on a
particular aspect or functionality.

26
Dividing Class Diagram for System Analysis
Local Hierarchies with Generalization and Aggregation:

● Generalization and aggregation in class diagrams create local

hierarchies, where classes are organized based on commonalities or
part-whole relationships.
● If there is no relationship to the lower levels in the hierarchy, the
superclass or composite object can represent the entire group of
related classes.

27
Subsystem Boundary

Fig. : Two subsystems with their respective boundaries 28

Subsystem Boundary
● Abstract environment classes refer to a concept in software design where
certain classes exist outside the boundaries of specific subsystems within a
larger application.
● In a software system divided into different subsystems, associations may cross
the boundaries connecting these subsystems.
● Objects or classes residing outside the boundary of any particular subsystem are
termed abstract environment classes.
● These classes play a crucial role in communicating with the subsystems, yet they
are not explicitly defined within any specific module.
● Some of these objects may belong to other subsystems, while others may not be
associated with any particular subsystem.

29
Checking the Object Model

● Object Model Development is Iterative

○ Creating an object model is a step-by-step process that involves refining
and improving the representation of concepts over time.
● Cross-Checking with Requirements:
○ Validate the object model by comparing it against the requirements
specification to ensure accuracy and completeness.
● Inspecting Concept Representations:
○ Examine how concepts and their qualifications are depicted in the object
model.

30
Checking the Object Model

● Use Cases as a Systematic Check:

○ Go through each use case systematically to ensure that
the objects in the object model collaborate effectively in
performing the specified tasks.

31
Checking the Object Model

● Identifying Potential Problems:

○ Look out for potential issues during the use case analysis,
such as:
○ Difficulties in handling certain use cases, indicating possible
missing objects or incorrectly named abstractions.
○ Lack of relationships among participating objects, suggesting
missing associations.
○ Objects not knowing how to respond, indicating a need for
attributes or associations.

32
 USE CASE DESCRIPTION

Title: Cruise Control Operation

Actors:
Primary Actor: Driver
Secondary Actors: Speed Sensor, Brake System, Accelerator Pedal, Engine
Controller
Description:
The driver initiates the cruise control system to maintain a constant speed.
The driver interacts with the Cruise Control System.
The Cruise Control System activates the Cruise Control, initializing the desired
speed and setting the system as active.
The driver adjusts the speed while the cruise control system is active.
The driver interacts with the Cruise Control System to adjust the speed.
The Cruise Control System communicates with the Cruise Control, which
modifies the desired speed.
The driver deactivates the cruise control system.
…………………………………………………………………………………………….and so on………… 33
Checking the Object Model

● Validating Object Interactions/ Relationships:

○ Use case descriptions serve as a systematic check for the
collaboration and interactions among objects during specific
scenarios.
○ During the validation process, developers can identify any
inconsistencies or missing relationships between objects that may
hinder the smooth execution of use cases.
○ This validation helps in maintaining the object model by ensuring
that the relationships and interactions among objects align with the
intended functionality, reducing the likelihood of runtime errors or
unexpected behavior.

34
Checking the Object Model

● Detecting Functionality Gaps:

○ Use cases provide a comprehensive view of the system's
expected behavior from a user or external entity perspective.
○ By reviewing use case descriptions, developers can identify
potential functionality gaps or missing features in the object
model.
○ This proactive approach helps in maintaining the object
model by addressing any shortcomings in functionality early
in the development process, leading to a more complete and
effective system.
35
Functional Model in Object Modeling

● The primary purpose of a functional model is to describe the

functional interface of a subsystem.
● Services may involve intricate interactions between users and
service providers.
● The functional interface comprises named services offered by
the subsystem to other subsystems and external agents.
● Operational sheets are one of the methods assisting in the
subsystem functional representations.
36
Functional Model in Object Modeling

● Operation sheets make it possible to capture complex

functionality in a short form.
● To contain the complexity in larger projects/ systems, the
policies that Operation Sheets should follow are:
1. Completeness of description in terms of preconditions
2. Level of detail in terms of exceptional values
3. Precision
4. Level of formality

37
Functional Model in Object Modeling

1) Completeness of description in terms of Preconditions:

● The first policy involves determining the extent to which the
description covers the preconditions of the system.
● Strong preconditions simplify operation sheets by excluding
error cases, making them more readable.
● However, complete specification may require additional sheets
for exceptions.

38
Functional Model in Object Modeling

2) Level of detail in terms of exceptional values:

● Projects must decide the level of detail in describing exceptional
values.
● This ranges from considering all situations outside preconditions
as resulting in unpredictable behavior to providing detailed
responses for every error case.

39
Functional Model in Object Modeling

3) Precision:
● In the context of operation sheets, precision refers to the level of
detail provided for operations. While many operations involve
straightforward information retrieval, some require nontrivial
computations.
● Operation sheets must decide how to handle operations that
involve calculations. One approach is to explicitly state that the
computed values are correct, ensuring clarity about the
expected outcomes.
40
Functional Model in Object Modeling

3) Precision:
● Alternatively, the operation sheet may directly express the
results of the computations rather than specifying their
correctness. This approach simplifies the sheet and focuses on
conveying the intended outcomes.

41
Functional Model in Object Modeling

4) Level of Formality:
● Operation sheets can attain a level of formality by incorporating
naming conventions and utilizing predicate logic to express
conditions.
● Naming conventions help standardize the language used in the
sheets, while predicate logic adds a formal structure to the
conditions governing operations.

42
Functional Model in Object Modeling

4) Level of Formality:
● Formal specifications offer advantages such as increased
precision, reduced ambiguity, and improved clarity in
understanding the intended behavior of operations.
● They provide a structured and systematic approach to
documenting system functionalities.

43
Functional Model in Object Modeling

4) Level of Formality:
● In practice, achieving correct and highly formal specifications for
real operations can lead to almost unreadable documentation.
● This highlights the importance of pragmatism and the need for
analysts to strike a balance that ensures the precision of
formalism without sacrificing clarity and accessibility.

44
Specification: CruiseControl Conditions:
Conditions:
- If the current speed is significantly
- IF currentSpeed < desiredSpeed - 5 below the desired speed (more than 5
THEN throttlePosition = throttlePosition + mph), slightly increase throttle position to
0.1 accelerate.
- IF currentSpeed > desiredSpeed + 5 - If the current speed is significantly
THEN throttlePosition = throttlePosition - above the desired speed (more than 5
0.1 mph), slightly decrease throttle position to
- IF |currentSpeed - desiredSpeed| <= 5 decelerate.
THEN throttlePosition = throttlePosition - If the current speed is within a
tolerance of 5 mph from the desired
speed, maintain the current throttle
position to keep the vehicle at the desired
speed.

45
Dynamic Model in Object Modeling

● The dynamic model describes the operation of a subsystem

across its application boundary and addresses the real-time,
reactive aspects.
● It explains under what conditions the operations are performed
and how long they are allowed to take.
● It captures the order of interactions between the subsystem and
its environment needed to perform an operation, and shows
what operations are possible in different states and how
different operations affect each other.
46
Dynamic Model in Object Modeling

In OCTOPUS, the dynamic model consists of the following

phases, in each phase, a number of related components are
produced :
● Analysis of events : Event list, grouping of events and event
sheets
● Analysis of states : Concurrent statecharts and actions table
● Further analysis of events and states : Significance table and
compound events
● Validation of the dynamic model : Scenarios for the complex
operations. 47
Functional Model Dynamic Model
● Describes what the system ● Describes how the system
should do. behaves in real-time.
● Outlines system functionality. ● Captures real-time interactions.
● Specifies inputs and outputs. ● Describes when actions are
performed.
● Defines expected outcomes. ● Explains how operations
influence behavior.
● Example in Cruise Control: ● Example:
Set speed, activate/deactivate. Throttle adjustment, state
transitions.
48
Dynamic Model

1) Analysis of Events:
● A real-time system simultaneously responds to random occurances of
events and gives the desired responses within the required time limits.
● Events that enter the subsystem are input events; events that leave it are
output events. In the dynamic model, the focus is on the input events
because they cause the activation, suspension, termination or abortion of
operations in the subsystem.
● The output events are specified in the operation sheets of the functional
model.

49
Dynamic Model

1) Analysis of Events:
● When you press a special key on your phone, the application
system doesn't just care about the physical button press. It's more
interested in what you want to do with it—like clearing the display
or searching for a name. They call this intention a "logical event,"
focusing on the meaning behind your action in the current state of
the system.

50
Dynamic Model

1) Analysis of Events:
● In general, real-time systems have two different types of events,
Periodic and Sporadic.
● Periodic events occur at a predetermined frequency, which may or
maynot be accurate.
● For example, requesting a memory check once every 10 seconds
is a periodic event, although the intervals between successive
occurrences need not be equal.

51
Dynamic Model

1) Analysis of Events:
● Periodic events can be used to monitor the environment
and to signal when a particular condition arises.
● They are normally implemented using a clock or a timer.
● A periodic event may occur at specific times, such as the
request to generate a statistic report at 08:15 a.m. or
09:35 p.m.

52
Dynamic Model

1) Analysis of Events:
● Sporadic events occur randomly in response to a particular
condition arising in the system or in the environment.
● Sporadic events are often handled using interrupts.
● The system has to respond within a particular time frame,
called the response time.
● Sporadic events are often approximately by periodic ones in
order to estimate the processor load, and hence, to assess
the temporal behaviour of a system.

53
Dynamic Model

1) Analysis of Events:
● The analysis of events has the following steps as below :
1. Identify and describe the logical input events
2. Find the commonalities between the events and group
them
3. Fill the event sheets

54
Dynamic Model

1) Analysis of Events:
1. Identify and describe the logical input events

55
Dynamic Model

1) Analysis of Events:
1. Identify and describe the logical input events
● Dynamic modeling begins by identifying and
understanding events.
● This is achieved by examining the class diagram, especially
focusing on associations crossing the application
boundary.
56
Dynamic Model

1) Analysis of Events:
1. Identify and describe the logical input events
● Events are recognized based on associations:
○ If an association suggests autonomous interactions
from the environment to the subsystem, indicating
changes in the system, those interactions are
considered events.
57
Dynamic Model

1) Analysis of Events:
1. Identify and describe the logical input events
● Events are recognized based on associations:
○ Inheritance of a class from another subsystem does not
typically indicate an event.
○ The above cases also apply if the association between
objects is an aggregation.

58
Dynamic Model

Step 2 : Find the commonalities between the events and group them
● Grouping of events helps to manage the complexity resulting from
the possible large number of different events. It is done bottom-up:
examine the events in the event list, and identify the commonalities
between them.
● Search the commonalities in relation to the source of events, data
contents, the expected response and time requirements. The more
things you find in common, the more beneficial it becomes to group
them.

59
Dynamic Model

60
Dynamic Model

EVENTS SUBEVENTS
Cruise Control System Events Start Cruise Control System
Stop Cruise Control System

Cruise Control Events Activate Cruise Control

Deactivate Cruise Control
Set Desired Speed
Adjust Speed

Vehicle Events Accelerate

Brake
61
Dynamic Model

EVENTS SUBEVENTS
Brake System Events Apply Brake
Release Brake

Accelerator Pedal Events Press Accelerator

Release Accelerator

Engine Controller Events Increase Throttle

Decrease Throttle

62
SUBEVENTS WITH RELATIONS

SUBEVENTS DESCRIPTIONS
1) Adjust Throttle 1) Subevent of "Increase Throttle" and
"Decrease Throttle", responsible for
Position
adjusting the throttle position.
2) Check Speed 2) Subevent of "Adjust Speed", ensuring
the vehicle's speed matches the desired
speed.
3) Monitor Brake 3) Subevent of "Apply Brake" and "Release
Brake", monitoring the status of the
System
brake system.
4) Update Speed 4) Subevent of "Read Speed", updating the
current speed of the vehicle.
63
Dynamic Model

Step 3 : Fill the event sheets

● An event sheet such as the one below is used to capture essential
information about the event.

64
Dynamic Model

● Event Sheet Purpose: An event sheet is a structured document used

to capture essential information about an event within a system. It
provides details necessary for system design and analysis.
● Associations Field: This field links the event with classes, objects, or
operations within the system's object model. It facilitates
understanding of which components are involved in handling the
event. For example, in a banking system, an event like "Withdrawal"
would be associated with the "Account" class and relevant
"Transaction" operations.
65
Dynamic Model

● Response Field: It outlines the end-to-end subsystem response

triggered by the event. This helps in understanding system
behavior following the occurrence of the event.
● Source Field: Explicitly states the source of the event. Events
from hardware wrappers typically have a single source, while
events from subsystems may have multiple sources. For
instance, a sensor malfunction event may originate from various
sensors within a system.
66
Dynamic Model

● Contents Field: Describes the data attributes carried with the

event. For instance, in a "Command" event, the contents would
include specific attributes indicating the nature of the command
(e.g., "Get Test Report," "Enable Tracing"). This field helps in
understanding the payload associated with each event.
○ You can write the attributes directly to the contents field
instead of writing an event.

67
Dynamic Model

● Time Requirement Fields:

● Response Time: Specifies the maximum interval within which
the system must respond to the event. Optionally, it may include
a minimum response time. This information is crucial, especially
in real-time systems, to ensure timely system behavior.
● Rate: Indicates the frequency of occurrence of the event, aiding
in estimating the system load. For example, an event like "User
Login" may occur frequently during peak hours in a web
application.
68
Dynamic Model

● Grouping and Building Event Sheets: The hierarchical

approach of top down view in event sheets ensures consistency
and efficiency. If subevents contain information identical to their
superevents, separate event sheets may not be necessary.
However, if there are additions or differences, event sheets for
each event are filled accordingly. This minimizes redundancy
and streamlines documentation.

69
Dynamic Model

● Cross-Referencing in Event Sheets: Event sheets refer to fields

in superevent sheets if applicable. Conversely, they reference
fields in subevent sheets when the information cannot be
collectively specified. This cross-referencing ensures coherence
and completeness in event documentation. For instance, in a
cruise control system, the event sheet for "Operation Command"
may reference fields in the "Command" event sheet, and vice
versa, to capture relevant information effectively.
70
Dynamic Model
● Cross-Referencing in Event Sheets

71
Event Sheet
Event: Brake Applied
Response: -
1) The system initiates the deceleration process by engaging braking
mechanisms and adjusting vehicle speed
2) If cruise control is active, it may be disengaged ( Depends on
driver input)
Association: BrakeSystem
Source: Brake Pedal
Contents:
- Brake Force: [numeric]
- Brake Pedal Position: [numeric]
Response Time: Max 100 ms, Min 50 ms
Rate: Variable (Depends on driver input) 72
2) Analysis Of States

● A "STATE" refers to a particular condition or mode that a

system can be in at any given time.
● States capture the behavior and characteristics of a system at
different points in time, reflecting its current operating mode
or status.
● The transitions between states represent the changes in the
system's behavior or configuration triggered by events or
conditions.
73
2) Analysis Of States

● States can also be hierarchical, meaning that they can contain

substates within them,
○ Allowing for the modeling of more complex behavior and
system structures.
● States can be demonstrated with the help of StateCharts.
● The analysis of states has two steps that are elaborated on
below :
1. Identifying and building the statecharts.
2. Filling the actions table.

74
Statecharts

● A visual tool used to represent the behavior of a system.

● It shows different states the system can be in, transitions between
those states, and events that trigger those transitions.
● It helps to understand how a system behaves over time, making it
easier to design and analyze complex systems.
STATECHART COMPOSITIONS:

Statechart Elementary States Associations

75
Statechart

● Statechart: This column specifies the name or category of the

states being modeled. It serves as a high-level overview of
the different components or subsystems within the system.
● Elementary States: This column lists the individual states
within each category of the statechart. Each elementary state
represents a specific condition or mode that the system can
be in at any given time.

76
Statechart

● Associations: This column specifies the events or actions

associated with each elementary state. An event is something
that happens in the system, such as a user input or an
external stimulus. Associations define how the system
responds to these events when it is in a particular state if its
on an action state.

77
2) Analysis Of States

Statechart Elementary States Associations

Cruise Control (S1.1) inactive Throttle Controller,
System Events (S1.2) active Accelerator, Brake
(S1.2.1) maintain Controller
(S1.2.2) accelerate
(S1.3) suspended

78
2.2 Filling the actions table.

79
Elementary Event Action/ Activity
States
(S1.1) inactive Start (1) Initialize cruise control system.
(S1.2) active Activate (2) System becomes operational.
(3) Verify vehicle speed.
(S1.2.1) maintain Set Desired Speed (4) Set desired speed.
(5) Monitor current speed.
(S1.2.2) accelerate Accelerate (6) Increase throttle position.
(7) Monitor vehicle acceleration.
(8) Adjust throttle as needed.
(S1.3) suspended Stop (9) Suspend cruise control system.
(10) Reset system parameters. 80
3) Further Analysis of Events and States

To further specify and understand dynamic behaviour, an

enhanced analysis of the events and states is done. This analysis
includes two steps which are discussed below :
1. Event significance analysis
2. Event laxity analysis

81
3) Further Analysis of Events and States

1. Event significance analysis

● How significant of important an event depends on the valid
combination of the elementary states all concurrent
statecharts are in.
● It is important to know the event significance because it
influences the object interaction threads and also the process
priorities in the design phase.

82
3) Further Analysis of Events and States
1. Event significance analysis
● The different significance values that help signify the events
importances are:
1) Critical (c):
○ This means the event is extremely important, and the system
must always respond to it in certain states. Failure to respond
is not allowed, especially in critical situations.
2) Essential (e):
○ This means the event is important, and the system should
usually respond to it in certain states. However, occasional
failures to respond may be acceptable.

83
3) Further Analysis of Events and States

3) Ignored (0):
This means the event can be ignored in certain states. It's not
necessary for the system to respond to it.

4) Neutral (1):
This means the significance of the event depends on other
factors. It's neither critical nor essential nor can it be ignored
based solely on the current state.

84
Significance Table

THROTTLE ACCELERATE BRAKE

STATES

S 1.1 inactive 0 0 0
S 1.2 active 1 1 1
STATES

S 1.2.1 maintain 1 1 1
S 1.2.2 accelerate e/c c/e 1

S 1.2.3 brake 1 1 c/e

S 1.3 suspend 0 0 0
85
Event Laxity Analysis

Elementary States:
Cruise.active: Cruise control system is engaged.

Cruise. inactive: Cruise control system is disengaged.

Brake.pressed: Brake pedal is pressed.

Compound States:
Cruise.inactive and Brake.pressed Compound state where cruise control is
disengaged when brake pedal is pressed.

86
Event Laxity Analysis

Figure: Separate Event v/s Compound Event

87
Event Laxity Analysis

● Replacing some events with compound ones has the

advantage of reducing the number of events with which
the system has to deal and eventually reducing the
number of control lines in the actual hardware.
● Combining the events is not without disadvantages; for
example, the meaning of a compound event cannot be
determined unless the state in which it occurs is known.

88
Event Laxity Analysis

● The significance table helps you to verify whether

combining certain events into a compound one is
possible or not.

89
Event Laxity Analysis
● Verify if two events can be combined:
1. If you find that both of them have either essential or critical
significance in the same state, and E1 causes a transition to a new
state which differs from the one caused by E2, then E1 and E2
cannot be combined.
2. If you find that one of them is essential or critical and the other is
neutral in the same state, and you find the opposite in another
concurrent state, then E1 and E2 cannot be combined.
3. In other cases, they can be combined. 90
Event Laxity Analysis

● Based on the significance table previously :

○ Explain the idea of Event Laxity and Compound Events,
on which events can be combined and hence called as
compound events.

91
Classwork
A B C D
STATES

S1 0 0 0 0
S2 1 1 1 1
S3 e/c c/e 1 1
S4 1 e/c c/e 1
S5 e/c c/e c/e 1
S6 0 0 0 0

92
Classwork A B C D
STATES

S1 0 0 0 0
Compound Events:
S2 1 1 1 1
1) AD
S3 e/c c/e 1 1
2) BD
3) CD S4 1 e/c c/e 1
S5 e/c c/e c/e 1
S6 0 0 0 0

93
Analysis of the Hardware Wrapper

94
Analysis of the Hardware Wrapper

Hardware Wrapper:
● As its name suggest, it can also act on a main scale as an interface
between the application subsystem and the underlying hardware
components.
● The hardware wrapper is notated and guided similarly to an
application subsystem but with a different perspective, focusing on
the hardware interactions.
● While Octopus isolates it, it has no ability to ignore it.

95
Analysis of the Hardware Wrapper

Abstract Environment Classes

● Abstract environment classes are identified by examining the
environment of each application subsystem.
● These classes can also represent hardware components, either
internal or external to the system, that provide services to the
application subsystem.
● Abstract environment classes refer to a concept in software design
where certain classes exist outside the boundaries of specific
subsystems within a larger application.

96