UNIT IV - SERVICE-ORIENTED SOFTWARE ENGINEERING, SYSTEMS

ENGINEERING AND REAL-TIME SOFTWARE ENGINEERING

Service-oriented Architecture – RESTful Services – Service Engineering – Service
Composition – Systems Engineering – Sociotechnical Systems – Conceptual Design – System
Procurement – System Development – System Operation and Evolution – Real-time Software
Engineering – Embedded System Design – Architectural Patterns for Real-time Software –
Timing Analysis – Real-time Operating Systems.

1. Service-oriented Architecture:
2. RESTful Services:
REST or Representational State Transfer is an architectural style that can be applied to web
services to create and enhance properties like performance, scalability, and modifiability.
RESTful web services are generally highly scalable, light, and maintainable and are used to
create APIs for web-based applications.
REST emerged as the predominant Web service design model just a couple of years after its
launch, measured by the number of Web services that use it. Owing to its more
straightforward style, it has mostly displaced SOAP and WSDL-based interface design.
REST became popular due to the following reasons:
1. It allows web applications built using different programming languages to
communicate with each other
2. Mobile devices have become more popular than desktops. Using REST, you don’t
need to worry about the underlying layer for the device
3. Modern applications have to be made compatible with the Cloud. As Cloud-based
architectures work using the REST principle, it makes sense for web services to
be programmed using the REST service-based architecture.

RESTful Architecture:

1. Division of State and Functionality: State and functionality are divided into
distributed resources. This is because every resource has to be accessible via
normal HTTP commands. That means a user should be able to issue the GET
request to get a file, issue the POST or PUT request to put a file on the server, or
issue the DELETE request to delete a file from the server.
2. Stateless, Layered, Caching-Support, Client/Server Architecture: A type of
architecture where the web browser acts as the client, and the web server acts as
the server hosting the application, is called a client/server architecture. The state
of the application should not be maintained by REST. The architecture should also
be layered, meaning that there can be intermediate servers between the client and
the end server. It should also be able to implement a well-managed caching
mechanism.

Principles of RESTful applications:

 1. URI Resource Identification: A RESTful web service should have a set of
resources that can be used to select targets of interactions with clients. These
resources can be identified by URI (Uniform Resource Identifiers). The URIs
provide a global addressing space and help with service discovery.
2. Uniform Interface: Resources should have a uniform or fixed set of operations,
such as PUT, GET, POST, and DELETE operations. This is a key principle that
differentiates between a REST web service and a non-REST web service.
3. Self-Descriptive Messages: As resources are decoupled from their
representation, content can be accessed through a large number of formats like
HTML, PDF, JPEG, XML, plain text, JSON, etc. The metadata of the resource
can be used for various purposes like control caching, detecting transmission
errors, finding the appropriate representation format, and performing
authentication or access control.
4. Use of Hyperlinks for State Interactions: In REST, interactions with a
resource are stateless, that is, request messages are self-contained. So explicit state
transfer concept is used to provide stateful interactions. URI rewriting, cookies,
and form fields can be used to implement the exchange of state. A state can also
be embedded in response messages and can be used to point to valid future states
of interaction.

Advantages of RESTful web services:

1. Speed
2. Compatible with SOAP
3. Language and Platform Independency
4. Supports Various Data Formats

Example :
Here is an example of a simple RESTful service that allows a client to create, read, update,
and delete (CRUD) a resource :

• Javascript

// GET /resource/123
// Returns the state of the resource with ID 123
app.get('/resource/:id', function(req, res) {
var id = req.params.id;
var resource = findResourceById(id);
res.json(resource);
});

// POST /resource
// Creates a new resource with the state specified in the request body
app.post('/resource', function(req, res) {
var resource = req.body;
var id = createResource(resource);
res.json({ id: id });
 });

// PUT /resource/123
// Updates the state of the resource with ID 123 with the state specified
in the request body
app.put('/resource/:id', function(req, res) {
var id = req.params.id;
var resource = req.body;
updateResource(id, resource);
res.sendStatus(200);
});

// DELETE /resource/123
// Deletes the resource with ID 123
app.delete('/resource/:id', function(req, res) {
var id = req.params.id;
deleteResource(id);
res.sendStatus(200);
});

In this example, the service uses the GET, POST, PUT, and DELETE HTTP methods to
implement the CRUD operations on a resource. The service uses the app.get(), app.post(),
app.put(), and app.delete() methods to register the appropriate handler functions for each
operation. The req and res objects represent the request and response, respectively, and are
used to access information about the request and send a response to the client.

3. Service Engineering:
Service engineering is the process of developing services for reuse in service-oriented
applications. The service has to be designed as a reusable abstraction that can be used in
different systems. Generally useful functionality associated with that abstraction must be
designed and the service must be robust and reliable. The service must be documented so that
it can be discovered and understood by potential users.
Stages of service engineering include:

• Service candidate identification, where you identify possible services that might
be implemented and define the service requirements.It involves understanding an
organization's business processes to decide which reusable services could support
these processes. Three fundamental types of service:
o Utility services that implement general functionality used by different
business processes.
o Business services that are associated with a specific business function
e.g., in a university, student registration.
o Coordination services that support composite processes such as
ordering.
• Service design, where you design the logical service interface and its
implementation interfaces (SOAP and/or RESTful). Involves thinking about the
operations associated with the service and the messages exchanged. The number of
messages exchanged to complete a service request should normally be minimized.
Service state information may have to be included in messages. Interface design
stages:
o Logical interface design. Starts with the service requirements and
defines the operation names and parameters associated with the
service. Exceptions should also be defined.
o Message design (SOAP). For SOAP-based services, design the
structure and organization of the input and output messages. Notations
such as the UML are a more abstract representation than XML. The
logical specification is converted to a WSDL description.
o Interface design (REST). Design how the required operations map
onto REST operations and what resources are required.
• Service implementation and deployment, where you implement and test the
service and make it available for use. Programming services using a standard
programming language or a workflow language. Services then have to be tested by
creating input messages and checking that the output messages produced are as
expected. Deployment involves publicizing the service and installing it on a web
server. Current servers provide support for service installation.

4. Service Composition:
Existing services are composed and configured to create new composite services and
applications. The basis for service composition is often a workflow. Workflows are logical
sequences of activities that, together, model a coherent business process. For example, provide
a travel reservation services which allows flights, car hire and hotel bookings to be coordinated.

Service construction by composition:

Formulate outline workflow
 In this initial stage of service design, you use the requirements for the composite service
as a basis for creating an 'ideal' service design.
Discover services
During this stage of the process, you search service registries or catalogs to discover
what services exist, who provides these services and the details of the service provision.
Select possible services
Your selection criteria will obviously include the functionality of the services offered.
They may also include the cost of the services and the quality of service
(responsiveness, availability, etc.) offered.
Refine workflow
This involves adding detail to the abstract description and perhaps adding or removing
workflow activities.
Create workflow program
During this stage, the abstract workflow design is transformed to an executable program
and the service interface is defined. You can use a conventional programming language,
such as Java or a workflow language, such as WS-BPEL.
Test completed service or application
The process of testing the completed, composite service is more complex than
component testing in situations where external services are used.

5. Systems Engineering:
Systems Engineering is an engineering field that takes an interdisciplinary approach to product
development. Systems engineers analyze the collection of pieces to make sure when working
together, they achieve the intended objectives or purpose of the product.

What are the fundamentals of systems engineering?

In product development, systems engineering is the interdisciplinary field that focuses on

designing, integrating, and managing the systems that work together to form a more complex
system. Systems engineering is based around systems thinking principles, and the goal of a
systems engineer is to help a product team produce an engineered system that performs a useful
function as defined by the requirements written at the beginning of the project. The final
product should be one where the individual systems work together in a cohesive whole that
meet the requirements of the product.
What is the role of a systems engineer?

Systems engineers have multi-faceted roles to play but primarily assist with:

• Design compatibility
• Definition of requirements
• Management of projects
• Cost analysis
• Scheduling
• Possible maintenance needs
• Ease of operations
• Future systems upgrades

What is the Systems Engineering Process?

The systems engineering process can take a top-down approach, bottoms up, or middle out
depending on the system being developed. The process encompasses all creative, manual, and
technical activities necessary to define the ultimate outcomes and see that the development
process results in a product that meets objectives.

The process typically has four basic steps:

• Task definition/analysis/conceptual: In this step, the systems engineer works

with stakeholders to understand their needs and constraints. This stage could be
considered a creative or idea stage where brainstorming takes place and market
analysis and end user desires are included.
• Design/requirements: In this phase, individual engineers and team members
analyze the needs in step 1 and translate them into requirements that describe how
the system needs to work. The systems engineer evaluates the systems as a whole
and offers feedback to improve integration and overall design.
• Create traceability: Although we’re listing traceability here as the third step,
traceability is actually created throughout the lifecycle of development and is not a
discrete activity taking place during one phase. Throughout the lifecycle of
development, the team works together to design individual systems that will
integrate into one cohesive whole. The systems engineer helps manage traceability
and integration of the individual systems.
 • Implementation/market launch: When everyone has executed their roles
properly, the final product is manufactured or launched with the assurance that it
will operate as expected in a complex system throughout its anticipated life cycle.

The “V” Diagram of Systems Engineering

The “V” diagram allows system engineers multiple viewpoints and opportunities to evaluate
systems as they integrate with each other. This approach starts with the desired outcomes and
objectives and then deconstructs them into individual systems and system components for the
purpose of design. Once the requirements and design details are established, individual systems
can be tested and evaluated, then integrated into the overall piece for testing and verification.
As the systems are integrated and become closer to the final complex system, teams have
multiple opportunities to validate and verify concepts, requirements, and design.
Systems engineering is a discipline that’s vital to the success of a complex system. By including
systems engineers in all stages of product development and requirements management, teams
can reduce risks, improve time to market, and produce better products that more adequately
meet end user requirements.

6. Sociotechnical Systems:
Socio-technical system is a mixture of people and technology. It consists of many items.
These items are difficult to distinguish from each other because they all have close inter-
relationships. Some of the items are shown in

Socio-technical systems include:

1. People: People can be individuals or in groups. An organization employs the
people, who build and make use of hardware and software, operate within law and
regulations, and share and maintain the data.
2. Hardware: The classical meaning if the technology is hardware. It involves
mainframe, workstations, peripheral, connecting devices.
3. Softwares: Software is nothing but an executable code. Softwares include
operating system, utilities, application programs. Software is an integral part of
the socio-technical system.
4. Law and regulations: There might be laws about the protection of privacy, or
regulations of chips testing in military use, etc. Laws and regulations set by
organization and government need to be followed.
5. Data: The design of the socio-technical systems design involve what data are
collected, to whom the data should be available and in which formats the data
should be stored.
These Systems have properties that are perceptible when all the components are integrated
and operate together.
1. The equipment layer: It contains set of hardware devices some of which may
be computer, laptops, phones, etc. Most of the devices include embedded system
of some kind.
2. The operating system layer: This layer provides a set of common facilities for
higher software layers in the system. This layer acts as an bridge to the hardware
as it allows interaction between software and hardware.
3. The communications and data management layer: This layer extends the
operating system facilities and provides an interface that allows interaction with
more extensive functionality, such as access to remote systems, access to a system
database, etc. This is sometimes called middleware, as it is in between the
application and the operating system.
4. The application layer: This layer provides more specific functionality to meet
some organization requirements. There may be many different application
programs in this layer.
5. The business process layer: This layer consists a set of processes involving
people and computer systems that support the activities of the business. The use
of software system, are defined and enacted.
6. The organizational layer: At this level, the business rules, regulations, policies
along with high-level strategic processes are defined and are to be followed when
using the system.
7. The social layer: Laws, regulations and culture that govern the operation of the
system are defined.

7. Conceptual Design:
Conceptual design investigates the feasibility of an idea and develops that idea to create an
overall vision of a system. Conceptual design precedes and overlaps with requirements
engineering. May involve discussions with users and other stakeholders and the identification
of critical requirements. The aim of conceptual design is to create a high-level system
description that communicates the system purpose to non-technical decision makers.
Conceptual design activities:

• Concept formulation: Refine an initial statement of needs and work out what type
of system is most likely to meet the needs of system stakeholders.
• Problem understanding: Discuss with stakeholders how they do their work, what
is and isn't important to them, what they like and don't like about existing systems.
• System proposal development: Set out ideas for possible systems (maybe more
than one).
• Feasibility study: Look at comparable systems that have been developed
elsewhere (if any) and assess whether or not the proposed system could be
implemented using current hardware and software technologies.
• System structure development: Develop an outline architecture for the system,
identifying (where appropriate) other systems that may be reused.
• System vision document: Document the results of the conceptual design in a
readable, non-technical way. Should include a short summary and more detailed
appendices.

8. System Procurement:
System procurement is the process of acquiring a system (or systems) to meet some identified
organizational need. Before procurement, decisions are made on: scope of the system,
system budgets and timescales, high-level system requirements. Based on this information,
decisions are made on whether to procure a system, the type of system and the potential system
suppliers. These decisions are driven by:

• The state of other organizational systems and whether or not they need to be
replaced
• The need to comply with external regulations
• External competition
• Business re-organization
• Available budget

It is usually necessary to develop a conceptual design document and high-level requirements

before procurement. You need a specification to let a contract for system development. The
specification may allow you to buy a commercial off-the-shelf (COTS) system. Almost always
cheaper than developing a system from scratch. Large complex systems usually consist of a
mix of off the shelf and specially designed components. The procurement processes for these
different types of components are usually different.
Three types of systems or system components may have to be procured:

• Off-the-shelf applications that may be used without change and which need only
minimal configuration for use.
• Configurable application or ERP systems that have to be modified or adapted for
use either by modifying the code or by using inbuilt configuration features, such as
process definitions and rules.
• Custom systems that have to be designed and implemented specially for use.

Issues with system procurement:

 • Organizations often have an approved and recommended set of application software
that has been checked by the IT department. It is usually possible to buy or acquire
open source software from this set directly without the need for detailed
justification. There are no detailed requirements and the users adapt to the features
of the chosen application.
• Off-the-shelf components do not usually match requirements exactly. Choosing a
system means that you have to find the closest match between the system
requirements and the facilities offered by off-the-shelf systems.
• When a system is to be built specially, the specification of requirements is part of the contract
for the system being acquired. It is therefore a legal as well as a technical document. The
requirements document is critical and procurement processes of this type usually take a
considerable amount of time.
• For public sector systems especially, there are detailed rules and regulations that affect the
procurement of systems. These force the development of detailed requirements and make
agile development difficult.
• For application systems that require change or for custom systems there is usually a contract
negotiation period where the customer and supplier negotiate the terms and conditions for
the development of the system. During this process, requirements changes may be agreed to
reduce the overall costs and avoid some development problems.

9. System Development:
System development usually follows a plan-driven approach because of the need for parallel
development of different parts of the system. Little scope for iteration between phases because
hardware changes are very expensive. Software may have to compensate for hardware
problems. Inevitably involves engineers from different disciplines who must work together.
Much scope for misunderstanding here. Different disciplines use a different vocabulary and
much negotiation is required. Engineers may have personal agendas to fulfil.
The system development process:

• Requirements engineering: The process of refining, analyzing and documenting

the high-level and business requirements identified in the conceptual design.
• Architectural design: Establishing the overall architecture of the system,
identifying components and their relationships.
• Requirements partitioning: Deciding which subsystems (identified in the system
architecture) are responsible for implementing the system requirements.
• Subsystem engineering: Developing the software components of the system,
configuring off-the-shelf hardware and software, defining the operational processes
for the system and re-designing business processes.
• System integration: Putting together system elements to create a new system.
• System testing: The whole system is tested to discover problems.
• System deployment: the process of making the system available to its users,
transferring data from existing systems and establishing communications with other
systems in the environment.

Requirements engineering and system design are inextricably linked. Constraints posed by
the system's environment and other systems limit design choices so the actual design to be used
may be a requirement. Initial design may be necessary to structure the requirements. As you
do design, you learn more about the requirements.
Subsystem engineering may involve some application systems procurement. Typically
parallel projects developing the hardware, software and communications. Lack of
communication across implementation teams can cause problems. There may be a bureaucratic
and slow mechanism for
proposing system changes, which means that the development schedule may be extended
because of the need for rework.
System integration is the process of putting hardware, software and
people together to make a system. Should ideally be tackled incrementally so that sub-
systems are integrated one at a time. The system is tested as it is integrated. Interface
problems between sub-systems are usually found at this stage. May be problems with
uncoordinated deliveries
of system components.
System delivery and deployment takes place after completion, when the system has to be
installed in the customer's environment. A number of issues can occur:

• Environmental assumptions may be incorrect;

• May be human resistance to the introduction of a new system;
• System may have to coexist with alternative systems for some time;
• May be physical installation problems (e.g. cabling problems);
• Data cleanup may be required;
• Operator training has to be identified. ‘/n

10. System Operation and Evolution:

Operational processes are the processes involved in using the system for its defined purpose.
For new systems, these processes may have to be designed and tested and operators trained in
the use of the system. Operational processes should be flexible to allow operators to cope with
problems and periods of fluctuating workload.
Problems with operation automation:

• It is likely to increase the technical complexity of the system because it has to be

designed to cope with all anticipated failure modes. This increases the costs and
time required to build the system.
• Automated systems are inflexible. People are adaptable and can cope with problems
and unexpected situations. This means that you do not have to anticipate everything
that could possibly go wrong when you are specifying and designing the system.

Large systems have a long lifetime. They must evolve to meet changing requirements. Existing
systems which must be maintained are sometimes called legacy systems. Evolution is
inherently costly for a number of reasons:

• Changes must be analyzed from a technical and business perspective;

• Sub-systems interact so unanticipated problems can arise;
• There is rarely a rationale for original design decisions;
• System structure is corrupted as changes are made to it.

Factors that affect system lifetimes:

 • Investment cost: The costs of a systems engineering project may be tens or even
hundreds of millions of dollars. These costs can only be justified if the system can
deliver value to an organization for many years.
• Loss of expertise: As businesses change and restructure to focus on their core
activities, they often lose engineering expertise. This may mean that they lack the
ability to specify the requirements for a new system.
• Replacement cost: The cost of replacing a large system is very high. Replacing an
existing system can only be justified if this leads to significant cost savings over the
existing system.
• Return on investment: If a fixed budget is available for systems engineering,
spending this on new systems in some other area of the business may lead to a
higher return on investment than replacing an existing system.
• Risks of change: Systems are an inherent part of business operations and the risks
of replacing existing systems with new systems cannot be justified. The danger with
a new system is that things can go wrong in the hardware, software and operational
processes. The potential costs of these problems for the business may be so high
that they cannot take the risk of system replacement.
• System dependencies: Other systems may depend on a system and making
changes to these other systems to accommodate a replacement system may be
impractical.

11. Architectural Patterns for Real-time Software:

Different Software Architecture Patterns :
1. Layered Pattern
2. Client-Server Pattern
3. Event-Driven Pattern
4. Microkernel Pattern
5. Microservices Pattern
1. Layered Pattern :

As the name suggests, components(code) in this pattern are separated into layers of
subtasks and they are arranged one above another.
Each layer has unique tasks to do and all the layers are independent of one another. Since
each layer is independent, one can modify the code inside a layer without affecting others.
It is the most commonly used pattern for designing the majority of software. This layer is
also known as ‘N-tier architecture’. Basically, this pattern has 4 layers.
1. Presentation layer (The user interface layer where we see and enter data into an
application.)
2. Business layer (this layer is responsible for executing business logic as per the
request.)
3. Application layer (this layer acts as a medium for communication between the
‘presentation layer’ and ‘data layer’.
4. Data layer (this layer has a database for managing data.)
Ideal for:
E-commerce web applications development like Amazon.
3. Client-Server Pattern :

The client-server pattern has two major entities. They are a server and multiple clients.
Here the server has resources(data, files or services) and a client requests the server for a
particular resource. Then the server processes the request and responds back accordingly.
Examples of software developed in this pattern:
• Email.
• WWW.
• File sharing apps.
• Banking, etc…
So this pattern is suitable for developing the kind of software listed in the examples.
4. Event-Driven Pattern :

Event-Driven Architecture is an agile approach in which services (operations) of the

software are triggered by events. When a user takes action in the application built using
the EDA approach, a state change happens and a reaction is generated that is called an
event.
Eg: A new user fills the signup form and clicks the signup button on Facebook and then a
FB account is created for him, which is an event.
Ideal for: Building websites with JavaScript and e-commerce websites in general.
5. Microkernel Pattern :

Microkernel pattern has two major components. They are a core system and plug-in
modules.
• The core system handles the fundamental and minimal operations of the
application.
• The plug-in modules handle the extended functionalities (like extra features) and
customized processing.
Let’s imagine, you have successfully built a chat application. And the basic functionality of
the app is that you can text with people across the world without an internet connection. After
some time, you would like to add a voice messaging feature to the application, then you are
adding the feature successfully. You can add that feature to the already developed application
because the microkernel pattern facilitates you to add features as plug-ins.
Microkernel pattern is ideal for: Product-based applications and scheduling applications. We
love new features that keep giving dopamine boost to our brain. Such as Instagram reels,
YouTube Shorts and a lot more that feasts us digitally. So this pattern is mostly preferred for
app development.
6. Microservices Pattern :

The collection of small services that are combined to form the actual application is the
concept of microservices pattern. Instead of building a bigger application, small programs
are built for every service (function) of an application independently. And those small
programs are bundled together to be a full-fledged application. So adding new features
and modifying existing microservices without affecting other microservices are no longer
a challenge when an application is built in a microservices pattern.
Modules in the application of microservices patterns are loosely coupled. So they are easily
understandable, modifiable and scalable.
Example Netflix is one of the most popular examples of software built-in microservices
architecture. This pattern is most suitable for websites and web apps having small
components.