0% found this document useful (0 votes)
14 views32 pages

Module-4 - C) Application Architectures

The document outlines various application architectures including data-processing, transaction-processing, event-processing, and language-processing systems. Each system type is described with its specific functions, components, and examples, illustrating how they handle data and user interactions. Key features such as batch processing, transaction management, event handling, and language translation are highlighted to demonstrate their operational frameworks.

Uploaded by

Veena sk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views32 pages

Module-4 - C) Application Architectures

The document outlines various application architectures including data-processing, transaction-processing, event-processing, and language-processing systems. Each system type is described with its specific functions, components, and examples, illustrating how they handle data and user interactions. Key features such as batch processing, transaction management, event handling, and language translation are highlighted to demonstrate their operational frameworks.

Uploaded by

Veena sk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 32

c) Application architectures

• Data-processing systems
• Transaction-processing systems
• Event-processing systems
• Language-processing systems
Data-processing systems
• Businesses use data-processing systems to handle tasks like payroll,
invoicing, accounting, and insurance renewals.
• These systems process large amounts of data, often much larger than
the systems themselves.
• They typically operate as batch-processing systems, inputting and
outputting data in batches from files or databases rather than
interacting with users in real-time.
• The systems analyze input records, perform actions based on
specified criteria, update databases with results, and format data for
output, such as printing.
• The architecture of batch-processing systems consists of three main
components:
1.Input Component: Collects data from one or more sources.
2.Processing Component: Performs computations on the collected inputs.
3.Output Component: Produces outputs, such as updating databases or
generating printouts.
• For example, in a telephone billing system, customer records and meter
readings (inputs) are processed to calculate costs, and the resulting bills
(outputs) are printed for customers.as shown in fig below
• Data-flow diagrams are a way of representing function-oriented
systems where each round-edged rectangle in the data flow represents
a function that implements some data transformation, and each arrow
represents a data item that is processed by the function.
• Files or data stores are represented as rectangles.
• The advantage of data-flow diagrams is that they show end-to-end
processing
• The figure shows the design of a salary payment system.
• In this system, information about employees in the organisation is read
into the system,
• monthly salary and deductions are computed,
• and payments are made.
• You can see how this system follows the basic input-process output
structure:
1. The functions on the left of the diagram Read employee record, Read
monthly pay data and Validate employee data input the data for each employee
and check that data.
3. The Compute salary function works out the total gross salary for each employee
and the various deductions that are made from that salary. The net monthly salary is
then computed.
4. The output functions write a series of files that hold details of the deductions
made and the salary to be paid. These files are processed by other programs once
details for all employees have been computed. A payslip for the employee,
recording the net pay and the deductions made, is printed by the system.
Transaction-processing systems

• Transaction-processing systems are designed to process user requests


for information from a database or requests to update the database
• a database transaction is sequence of operations that is treated as a
single unit
• All of the operations in a transaction have to be completed before the
database changes are made permanent
• This means that failure of operations within the transaction do not lead
to inconsistencies in the database.
• An example of a transaction is a customer request to withdraw money from a bank
account using an ATM.
• Figure 13.3 illustrates the high-level architectural structure of these
applications.
• First a user makes a request to the system through an I/O processing
component.
• The request is processed by some application-specific logic. A
transaction is created and passed to a transaction manager, which is
usually embedded in the database management system.
• After the transaction manager has ensured that the transaction is
properly completed, it signals to the application that processing has
finished.
• This involves getting details of the customer’s account, checking the
balance, modifying the balance by the amount withdrawn and sending
commands to the ATM to deliver the cash.
• Until all of these steps have been completed, the transaction is
incomplete and the customer accounts database is not changed.
• Figure 13.4 shows The software architecture of an ATM
• Figure 13.5 below shows another view of the architecture of a
customer accounting system that handles personal account transactions
from ATMs and counter terminals in a bank.
• The teleprocessing monitor handles the input and serialises
transactions, which it converts to database queries.
• The query processing takes place in the database management system.
• Results are passed back to the teleprocessing monitor, which keeps
track of terminals making the request.
• This system then organises the data into a form that can be handled by
the terminal software and returns the results of the transaction to it.
• Figure 13.6 is a very general model of an information system.
• where the top layer supports the user interface and the bottom layer
the system database.
• The user communications layer handles all input and output from the
user interface.
• and the information retrieval layer includes application-specific logic
for accessing and updating the database.
❖ Event-processing systems

• Event-processing systems respond to events in the system’s


environment or user interface.
• the key characteristic of event-processing systems is that the timing of
events is unpredictable and the system must be able to cope with these
events when they occur.
• We all use such event-based systems like this on our own computers—
word processors, presentation systems and games are all driven by
events from the user interface.
• The system processes screen events as commands, updates an
internal data structure, and redisplays the updated content on the
screen.
• Objects in the system operate concurrently and autonomously,
ensuring responsive interaction.
• Real-time systems, by contrast, respond to external events (e.g.,
sensors), but editing systems focus primarily on user actions
for document manipulation.

• The responsibilities of the architectural components shown in Figure 13.10


are:
1. Screen This object monitors the screen
memory segment and detects events that occur.
These events are then passed to the event-
processing object along with their screen
coordinates.
2. Event This object is triggered by an event
arriving from Screen. It uses knowledge of what
is displayed to interpret this event and to
translate this into the appropriate editing
command. This command is then passed to the
object responsible for command interpretation.
For very common events, such as mouse clicks
or key presses, the event object can
communicate directly with the data structure.
This allows faster updates of that structure.
3. Command This object processes
a command from the event object
and calls the appropriate method in
the Editor data object to execute
the command.
4. Editor data When the
appropriate command method in
Editor data object is called, it
updates the data structure and
calls the Update method in Display ,
to display the modified data.
5. Ancillary data : It acts as as the data
structure itself, editors manage other data such
as styles and preferences .Some editor commands,
such as a command to initiate a spelling check,
are implemented by a method in this object.
6. File system This object handles all opening
and saving of files. These can be either editor data
or ancillary data files. To avoid data loss, many
editors have auto-save facilities that save the data
structure automatically. This can then be retrieved
in the event of system failure.
7. Display This object keeps track of the
organisation of the screen display. It calls the
Refresh method in Screen when the display has
been changed.
❖ Language-processing systems

• Language-processing systems take natural or artificial language as


input and produce another representation as output.
• Language-processing systems are used to translate texts from
one language into another and to carry out the instructions
specified in the input language. They include a translator and an
abstract machine that executes the generated language.
• Examples include compilers that translate high-level code into
machine code, systems that process XML into database queries, and
natural language processors for language translation.
• Lage-processing systems are used when solutions are best specified as
algorithms or data descriptions, such as meta-CASE tools that
generate CASE tools for software engineering methods.
• CASE tools use a special-purpose language to describe method,
components and rules, which is analyzed to configure the generated
tool.
• the architecture of a language-processing system is illustrated in
Figure 13.11.
• The instructions describe what has to be done and are translated into some
internal format by a translator.
• These instructions are then interpreted by another component that fetches the
instructions for execution and executes them using, data from the environment.
• The output of the process is the result of interpreting the instructions on the input
data.
• For many compilers, the interpreter is a hardware unit that processes machine
instructions and the abstract machine is a real processor.
• However, for languages such as Java, the interpreter is a software component.
Translators in a language-processing system have a generic
architecture (Figure 13.12) that includes the following components:
Translators in a language-processing system have a generic architecture
(Figure 13.12) that includes the following components:

1. A lexical analyser, which takes


input language tokens and
converts them to an internal form
2. A symbol table, which holds
information about the names of
entities (variables, class names,
object names, etc.) used in the text
that is being translated
3. A syntax analyser, which checks the
syntax of the language being translated. It
uses a defined grammar of the language and
builds a syntax tree
4. A syntax tree, which is an internal
structure representing the program being
compiled
5. A semantic analyser, which uses
information from the syntax tree and the
symbol table to check the semantic
correctness of the input language text
6. A code generator, which ‘walks’ the
syntax tree and generates abstract machine
code
The generic system components can then be organised in a repository
based model, as shown in Figure
• This figure illustrates how a language-
processing system can be part of an integrated
set of programming support tools.
• the symbol table and syntax tree act as a
central information repository. Tools or tool
fragments communicate through it.
• Other information that is sometimes
embedded in tools, such as the grammar
definition and the definition of the output
format for the program, have been taken out
of the tools and put into the repository.
• Therefore, a syntax-directed editor can check
that the syntax of a program is correct as it is
being typed,
• and a pretty printer can create listings of the
program in a format that is easy to read.
THANK YOU

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy