Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

Name: FIZA SAIF

Roll No: SE-080

Batch: 2019

Year: 2021 Second Year

Department: Software
Engineering

SDA
Course:

ASSIGNMENT NO 01:
Q1. What are fault trees? Create a fault tree for any scenario of your choice
and explain in detail the fault tree. Analyse the fault tree and explain how you
would modify your system to accommodate these faults.

ANSWER:

FAULT TREES: Fault tree is a graphic construct that helps identify all sequential
parallel sequences of contributing faults that will result in occurrence of
undesired state, which is listed at the top of the tree (the "top event"). The
contributing
faults might be hardware failure, human errors, software errors, or any other
pertinent events that can lead to the undesired state.

FAULT TREE ANALYSIS: Fault tree analysisis an expository strategy


that specifies a state of the system that negatively impacts safety or
reliability, and then analyzes the system's context and operations to find all
the ways that the undesired state could occur.

SCENARIO:
Consider a scenario for an automatic teller machine (ATM). Include faults dealing
with hardware component failure, communications failure, software failure,
running out of supplies, user errors, and security attacks.
CREATING FAULT TREE FOR ATM:
For an evalution of fault tree, a tree graph chart has been utilized. Fault tree
investigate can offer assistance to recognize the reasons of the breakdown or check
a gadget 's toughness by deliberately going over a chronology of exercises.

Figure 1: Fault Tree for an automatic teller machine


MODIFICATION OF ATM TO ACCOMODATE THE FAULTS:
The automatic teller machine design can be altered as takes after to suit the flaws:
1) The ATM's hardware-related faults require a steady control supply and can be
reproduced from the ATM after the life of the equipment.
2) The problem of communication can be overcome by taking a good network
connection and arranging the router technically.
3) Software failure is a genuine issue in ATMs, bugs are solved by installing free
software and securing hardware devices.
4) Continuous supply of cash and electricity can solve the problem of running of
ATM supplies.
5) User errors can be resolved by giving information about using ATM or by giving
user manual.
6) Several measures are possible to protect the ATM from security attacks such as:
• Use authentication and encryption in device.
• Try to use anti-skimming card as it prevent skimming devices from being
attached to ATMs.
• Install an intrusion detection system.
• Using CCTV camera in ATM room is a good option.
• Biometric methods should be used for authentication etc.
Q2. Explain pipe-and-filter architecture
OVERVIEW:
The pipe and filter architectural pattern provide a structure for systems that process
a stream of data. Data arrives at a filter’s input ports, is transformed, and then is
passed via its output ports through a pipe to the next filter. This architecture
decomposes the entire system into components of data source, filters, and pipes.
The connections between components are data streams. The particular property
attribute of the pipe and filter architecture is its concurrent and incremented
execution.
ELEMENTS:
There are two elements in pipe and filter architecture:
1) Filters
2) Pipes
1) FILTERS:
Each filter transform data stream and pass as a input for next filter . A filter does not
need to wait for complete data file. As soon as the data arrives through the
connected pipe, the filter can start working right away. Filters can execute
concurrently with each other. Important characteristics include processing rates,
input/output data formats, and the transformation executed by the filter.
2) PIPES:
Each pipe is a channel that allows the flow of data between or among different
filters. A pipe moves a data stream from one filter to another. A pipe can carry binary
or character streams. A pipe is placed between two filters; these filters can run in
separate threads of the same process. Important characteristics include buffer size,
protocol of interaction, transmission speed, and format of the data that passes
through a pipe.
STRUCTURE:
Simple representation:

Formal representation:

Applicable Domains of Pipe and Filter Architecture:


• The system can be broken into a series of processing steps over data streams,
and at each step filters consume and move data incrementally.
• The data format on the data streams is simple, stable, and adaptable if necessary.
• Significant work can be pipelined to gain increased performance.
• Producer or consumer-related problems are being addressed.
Benefits:
• Concurrency: It provides high overall throughput for excessive data processing.
• Reusability: Encapsulation of filters makes it easy to plug and play, and to
substitute.
• Modifiability: It features low coupling between filters, less impact from adding new
filters, and modifying the implementation of any existing filters if the I/O interfaces
are unchanged.
• Simplicity: It offers clear division between any two filters connected by a pipe.
• Flexibility: It supports both sequential and parallel execution.
Limitations:
• It is not suitable for dynamic interactions.
• A low common denominator is required for data transmission in the ASCII formats
since filters may need to handle data streams in different formats, such as record
type or XML type rather than character type.
• Overhead of data transformation among filters such as parsing is repeated in two
consecutive filters.
• It can be difficult to configure a pipe and filter system dynamically.
Q3. Describe four views of software architecture.
VIEW:
A view of a system is a representation of the system from the perspective of a
viewpoint. This viewpoint on a system involves a perspective focusing on specific
concerns regarding the system, which suppresses details to provide a simplified
model
having only those elements related to the concerns of the viewpoint. The views are
used to describe the system from the viewpoint of different stakeholders, such as
end-users, developers, system engineers, and project managers.
4+1 view model:
4+1 is a view model used for "describing the architecture of software-intensive
systems, based on the use of multiple, concurrent views".
The four views of the model are logical, development, process, and physical view. In
addition, selected use cases or scenarios are used to illustrate the architecture
serving as the 'plus one' view. Hence, the model contains 4+1 views
REPRESENTATION:

Why 4+1 view?


Using several concurrent views or perspectives, with different notations each one
addressing one specific set for concerns. “4+1” view model presented to address
large and challenging architectures.
Why is it called the 4 + 1 instead of just 5?
Well, this is because of the special significance the use case view has. When all
other views are finished, it is effectively redundant. However, all other views would
not be possible without it. It details the high levels requirements of the system. The
other views detail how those requirements are realized.
VIEWS OF 4+1 VIEW MODEL:
There are 4 views of 4+1 view model:
1) logical view
2) Process view
3)Development view
4) Physical view
1) LOGICAL VIEW:
The logical view is concerned with the functionality that the system provides to end-
users. UML diagrams are used to represent the logical view, and include class
diagrams, and state diagrams.This contains information about the various parts of
the system. In UML, the logical view is modelled using Class, Object, State machine
and Interaction diagrams (e.g. Sequence diagrams). Its relevance is really to
developers.
2) PROCESS VIEW:
The process view deals with the dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on the run time behavior of the
system. The process view addresses concurrency, distribution, integrator,
performance, and scalability, etc. UML diagrams to represent process view include
the sequence diagram, communication diagram, activity diagram.This describes the
concurrent processes within the system. It encompasses some non-functional
requirements such as performance and availability. In UML, Activity diagrams -
which can be used to model concurrent behavior - are used to model the process
view.
3) DEVELOPMENT VIEW:
The development view illustrates a system from a programmer's perspective and is
concerned with software management. This view is also known as the
implementation view. It uses the UML Component diagram to describe system
components. UML Diagrams used to represent the development view include the
Package diagram.The development view focusses on software modules and
subsystems. In UML, Package and Component diagrams are used to model the
development view.

4) PHYSICAL VIEW:
The physical view depicts the system from a system engineer's point of view. It is
concerned with the topology of software components on the physical layer as well as
the physical connections between these components. This view is also known as the
deployment view. UML diagrams used to represent the physical view include the
deployment diagram.The physical view describes the physical deployment of the
system. For example, how many nodes are used and what is deployed on what
node. Thus, the physical view concerns some non-functional requirements such as
scalability and availability. In UML,Deployment diagrams are used to model the
physical view.
5) USE CASE VIEW / SCENARIOS:
Use case view uses a small set of use cases or scenerios for description of an
architecture. The scenarios describe interactions between objects and between
processes. Use case view are used to identify architectural elements for validation of
the architecture design. They also serve as a starting point for tests of an
architecture prototype. This view is also known as the use case view.
This view describes the functionality of the system from the perspective from outside
world. It contains diagrams describing what the system is supposed to do from a
black box perspective. This view typically contains Use Case diagrams. All other
views use this view to guide them.
IMPORTANCE OF 4+1 VIEW MODEL:
1) 4+1 view model makes modelling easier to do because it makes it easier to
organize.
2) The 4 + 1 approach also provides a way for architects to be able to prioritize
modelling concerns.
3) The 4 + 1 approach makes it possible for stakeholders to get the parts of the
model that are relevant to them.

You might also like