School of Information Technology and

Engineering
SWE2024 - Software Reuse
Winter Semester 2021-22

SLOT: D1+TD1

DIGITAL ASSIGNMENT

Assignment-1

Submitted By

Name: Sethumadhavan V
Reg.No:19MIS0010
MTech (Software Engineering) 3 rd. Year
Faculty: Asha N
 Name: Sethumadhavan V
Reg.No:19MIS0010
1. Design a complete Layered System for the domain HealthCare System.

Introduction:
Healthcare systems like other business information systems that
they involve business collaborations within and across organisational
boundaries. To design such systems, it requires a holistic view over the issues of
1)Who requires healthcare services;
2) Quality of the healthcare services;
3) Tailorable of the healthcare services to meet personalised needs;
4) Architectural representation of the healthcare services;
5) Discovery and configuration of the healthcare services for a specific request.
Web Services have been widely used for developing information systems with
such complex features. With this approach, the functionality provided by
business applications are encapsulated within software components and
technically supported by SOAP, WSDL, and UDDI. However, Web Services
lack of capability for modelling a dynamic aspect of the service. Many
emerging languages, e.g., Business Process Modelling Language (BPML),
Business Process Execution Language (BPEL), and Business Process Modelling
Notation (BPMN) have been developed to serve this purpose. To integrate these
capabilities from Web Services and business process modelling, service-
oriented architecture (SOA) provides methods for information systems
development and integration where the technical functions should be structured
around business processes and package these as interoperable services. SOA
and Web Services are not fully capable of analysing and modelling a complex
healthcare system which involves multiple stakeholders with multiple concerns.
These stakeholders demand personalised services to meet their needs. To
address this problem, we present a new adaptive architecture which will be
discussed from its underpinning theory of RDAA in Section 2; the
methodological functions of RDAA which can be adopted in this development
in Section 3; the description of the adaptive architecture with its application in
Section 4; and the conclusion is drawn in Section 5 where some future work are
proposed.

Page.No:2
 Name: Sethumadhavan V
Reg.No:19MIS0010
Requirement-Driven Adaptive Architecture Overview:

User requirement layer analyses and identifies user requirement, it also gives
standardization and pattern recognition for user requirement. Business service
layer is for service classification and standardization. Found and consummate
service pattern library. Business process, function and data layers realize
process start, function execution, resource controlling and managing of business
service in turn, URDL is used for user’s requirement, Business Service
Description Language (BSDL) is used for business service, and Business
Process Execution Language (BPEL) is used for business process. These three
languages are advanced protocols of RDAA. In RDAA, function and data layer
use SOA based on web service. Pattern, case, ontology and specification library
of requirement, services and business process are foundation of RDAA. Layer
mapping and self-adapting mechanism are basic operational mechanism of
RDAA. Consequence based on specification and cases together with Agent
technology make RDAA adapt changes of requirement and environment, also
make it with ability of selfconsummate and self-evolution. Semantic
consistency during layer mapping, consequence and matching are realized by
searching ontology library. Processing specification and knowledge, organizing
specification and knowledge, society specification and knowledge, these are
three features of RDAA. When society or organizations changing, RDAA can
track the change of environments. This makes RDAA with more agility and
adaptation. Information sharing and security make RDAA run safely.

Page.No:3
 Name: Sethumadhavan V
Reg.No:19MIS0010
SYSTEM ARCHITECTURE FOR HEALTHCARE
INFORMATION SYSTEMS
FUNCTIONAL REQUIREMENTS
The system architecture is designed to support all HIS
applications discussed emailer and achieve the following objectives:
1. Allow data communications between all applications and users of the entire
system.
2. Ensure quick response to requests and completion of transactions (fast
system performance)
3. Ensure business continuity (almost 100% up-time through sufficient
redundancy and system back-up)
4. Fully recovery from a disaster (system may be re-built from back-up of
data, system configuration and restoration of applications)
5. Storage capacity capable of containing migrated previous data and new
data for the next 5 years.
6. Scalability server-storage system hardware that is vendor independent.

ARCHITECTURE DESIGN: COMPONENTS

The information system for a single hospital is best built around a Multi-tiered
Client-Server Local Area Network (LAN) architecture. By this, it is meant that
users enter and retrieve data using clients i.e. computers with display monitors
and data input devices such as keyboard and mouse, obtain various applications
software from the Application server and store the data via the Storage server into
Storage devices (hard disks). All the tiers are linked through a network consisting
of cables joined by switches and routers. Part of the network can also be wireless.
A typical HIS System Architecture implementation is shown below:

Page.No:4
 Name: Sethumadhavan V
Reg.No:19MIS0010

➢ A sufficiently fast processor.

➢ Sufficient ready access memory (RAM) to retain data
temporarily while being viewed or entered.
➢ A display monitor for viewing both applications and data.
➢ Data input tools such keyboard, bar-code reader and image
scanners and pointing devices e.g., mouse.

Page.No:5
 Name: Sethumadhavan V
Reg.No:19MIS0010
➢ A front-end Operating system (OS) that allow all the above
hardware to function and to facilitate interaction with the server.
➢ Video/graphic cards for locations where complex images are
used.
Generally, for clients, Desktop and Laptop/Tablet PCs with high end CPUs and
sizeable memory are preferred. These can be used either as thick and thin clients
or a hybrid. They are attached to the network through suitable cables and wireless
connections.
For a thick client installation, client computers with fast CPUs and sizeable RAM
memory is required. They are loaded fully or partially with Applications software.
In a thin client approach, the client is loaded only with a browser. The
Applications are retrieved from the Applications server as and when they are
needed. Lower end CPUs may be used and less RAM memory is required.
However, in a HIS set-up, the hardware usually used as thin clients (low end
computer with little processing power and memory) is not suitable because of the
need to present images and graphs. Instead PCs are more appropriate.Each client
can be used for a multitude of clinical and managerial (office automation, e-mail)
applications and also as Image viewers. The operating system (OS) for the front
end (presentation logic) must cater for all these applications. It should also
support user interfaces (GUIs) that satisfies user needs.

The system may adopt web technology within the local area network. A web
client may be used to host the browser just like thin clients. If a care provider
requires access to HIS via clients at locations outside of the hospital such as
from home or another hospital / clinic, then it should be connected to the
hospital’s LAN through a secure network such as Virtual Private Network
(VPN).SERVERSIn a comprehensive integrated HIS, the server-storage system
need to cater to both the managerial applications as well as the patient care
applications. Because a hospital functions 24 hours a day, and everyday for 365
days a year, the system should not fail. Currently an uptime of 99.9% is the
standard aimed for. To achieve this there should be duplication of the means to
make applications available and to ensure that data can be saved and retrieved
without interruption. This translates into the provision of more than one location
where each application resides and where data is stored. The ability for the
system to function if one part fails is termed as redundancy.In patient care, at
any given time there are numerous users of the system causing heavy data
traffic. Both the applications and database servers must have sufficient
processing power and memory to deal with requests. The data required at
anytime is usually great and a large amount of data accumulates over time. The

Page.No:6
 Name: Sethumadhavan V
Reg.No:19MIS0010
storage device must have a large storage space and also able to accept and
release data efficiently.Besides being used for day to day operations, a complete
system need to cater for other functions. Therefore copies of applications and
systems need to be provided for other important uses. The alternative versions
of clinical applications and separate databases are often called ‘domains’.
These usually include:
➢ Production or Operations Domain
➢ Analytical Domain
➢ Build or Test Domain
➢ Train Domain
The Operations Domain cater for day to day use where the data is actual and in
real-time. The Analytical Domain allow actual but not necessarily real-time data
to be analyzed to produce reports. The Build/test Domain contains a version of
the applications often different from that of the operations environment. It may
contain fabricated data. The Train Domain contains the same software version
as the Operations Domain but only fictitious/fabricated data. Despite the many
domains and versions, these do not necessarily mean that separate server-
storage hardware are required.

APPLICATION SERVER
Servers cater for requests from users to:
➢ use an application or a part of it
➢ input or retrieve data
The Applications server(s) contains all Applications software and provides
whatever applications the user wish to use. It integrates with the data storage
function via the Storage (Database) server. Traditionally, the Managerial
applications and the Clinical Applications use separate servers and storage
systems. Together with the need for duplication, this may result in the provision
of many physical servers and storage systems.The use of virtualization
technology can reduce the number of physical servers. A cluster of physical
servers (minimal two) may be used. Each physical server will house many
virtual servers.
The Applications server hosts all the Applications software if the thin client
approach is used. However, if PCs are used a portion may reside in the client
computer. System Software / Operating System for the Server(yet to be
written).

Page.No:7
 Name: Sethumadhavan V
Reg.No:19MIS0010
DATABASE AND DATA STORAGE HARDWARE:

Database ServerDatabase/Storage servers control data input and output from

storage devices such as Storage Area Network (SAN storage) or Network Area
Storage (NAS). The software that defines the structure and content of the
database is the Database Management System (DBMS). This can be of the
relational, hierarchical or object-oriented types. The database server itself and
the DBMS requires an appropriate system software (OS).Data Storage
DeviceCurrently, the hardware that holds the data is a set of hard-disks (disk
array). Magnetic tapes (tape library) are used mainly to archive data as back-up.
NETWORK (Cables & Wireless)Hardware components of the various tiers of
HIS are linked through a network (both cables and wireless). The network need
to have the following features:
➢ Sufficient bandwidth corresponding to volume of data that will traverse through two
points to be connected.

Page.No:8
 Name: Sethumadhavan V
Reg.No:19MIS0010
➢ Redundancy to ensure an alternative passage of data if one route is impossible.

Page.No:9
 Name: Sethumadhavan V
Reg.No:19MIS0010
Train Domain:

Page.No:10
 Name: Sethumadhavan V
Reg.No:19MIS0010
Analytical Domain Within His:

TraLayer modular design and matching:

1) User’s requirement layer:
The design and matching of URP. This makes classification and standardization
for user’s requirement which appear more frequently, in the form of various
user’ requirement patterns (URPs). URDL which can be recognized by system
to describe and define user’s requirement is adopted to construct URP .A user’s
requirement is always realized by one or many services, some service patterns
are organized effectually to satisfy user’s requirement. The usage of URP and
transaction engine can satisfy changes of user’s requirement compared to basic
requirement. For example changes in business process can be satisfied by the
restriction, decomposition or combination of originality functions. According to
layer theory of complex system, changes in high layer can be mapped into lower
layer, keeping stability of lower layer’s data and function.

Page.No:11
 Name: Sethumadhavan V
Reg.No:19MIS0010

User’s requirement pattern matching process

The mechanism of URP matching is as follows:
Searching engine search and matching URP in URPs library, if
succeed, calling certain service; if failed, system will form a new URP, calling
lower layer for a new service pattern. Whenever the result according with some
specification, it will be added in to system as a new URP.
Requirement/Service mapping and calling. Mapping mechanism can transfer
URP to service pattern. Mapping of two layers is stored in requirement library.
The URP will be satisfied by offering standard service description. Under the
support of knowledge library, Requirement/Service mapping use user’s
requirement agent to realize intellectualized matching, and then call for matched
service pattern .
2) Business service layer (BSL)
The design and matching of business service patterns (BSPs). Business
service layer is made up of business service engine, BSPs library, case library
and specification library. In BSL, every service pattern corresponds with one or
several business process pattern which is composed dynamically with certain
business relation. Business service description language (BSDL) is adopted to
describe it. Service pattern can orient user or self-adaptive service provided by

Page.No:12
 Name: Sethumadhavan V
Reg.No:19MIS0010
URPs, which can’t be realized by current function model nor business process
pattern. Service requirement is beyond single business process and service
usually need support by some various kinds of business process.

3) Business Process layer (BPL)

The design and matching of BPP. BPP is used for classification
and specification of business process. BPP is described by business process
execution language (BPEL). A BPP may be made up by many independence
function subassembly, or may contain other BPPs. They are managed and called
by logic of service pattern which provide service to user. BPP is an advanced
service pattern, and under the current condition of commercial activity, business
processes usually need many functions work together. BPP of web service
which is based on XML, SOAP, UDDL is popular now. In RDAA, we use
BMPI, expending BPML and BPEL in order to suit the description and
execution of business process.

4) Function layer (FL)

The design of Function Pattern (FP) and its mechanism. FP is used
for classification and specification of application service with certain function
model. A BPP is made up of many function models. A function model is made
up of some data manipulation models. Function model is a popular service
pattern, executing business logic by high level language and operating data by
data manipulation language, to provide user with functional service. The feature
of function model is the fixed interface of man-machine interaction, so the
function is predesigned according to program. In FL, management is embedded
in execution process which mainly relates to technology. For example several of
high level language, software architecture, design and develop method etc.
function model is middle layer between user’s logical operation and physical
information operation . In RDAA, we define function model using web service
technology which makes RDAA more flexibility and expansibility.

5) Data layer (DL)

Difference from other models, data model realizes transferring from
information service to physical information operation, which is the fundamental
mode of the whole self-adaptive information service. Data model and its

Page.No:13
 Name: Sethumadhavan V
Reg.No:19MIS0010
mapping pay more attention to technical realization of physical information
operation, using lower level language which can be recognized by hardware
system. Typical instance of data layer is database managing system. Mapping
between function model and data model use normal data driven mode like
JDBC, ODBC etc.

Design language in RDAA

1) URDL, based on XML and XPath, describes a series of formula
of grammar and semantic, and it is actually operation protocols of application
layer. URDL is specification language used for description of user’s
requirement layer. A URDL must represent user’s requirements clearly,
including functional demand and non-functional demand; define questions,
solution method, restriction, condition and environment; express logial
relationship between user’s requirement and business service; and execute
mappings.
2)BSDL represents business processes where stakeholders are
responsible to conduct communications by following the business norm. BSDL
also realizes control between manage layer and application layer by hierarchical
control.

The adaptive mapping mechanism:

The searching and mapping mechanism between neighboring
layers assisted by norm based reasoning, case based reasoning and necessary
human coordination are the operation mechanism of our system. The basic
information unit in each layer is pattern. A user requirements pattern is the
collection of characters of a whole requirement. A business service pattern is
the collection of characters of a whole service in certain business domain and
other layers are similar. There are one-to-many relationships from upper layer to
lower layer. That is to say, a URP matches one or several BSPs and a BSP
matches one or several BPPs. The granular size of the patterns in this
framework become larger and larger form bottom level to top level .The
granularity of patterns and the mapping mechanism are the basis of system’s
adaptability to changing requirement and environment, since various
permutation and combination of small-sized elements from lower layer can
satisfy the changes of large-sized elements from upper layer.

Page.No:14
 Name: Sethumadhavan V
Reg.No:19MIS0010
A HEALTHCARE SYSTEMS ARCHITECTURE:
A healthcare information system is normally complex and
dynamic, because it involves various stakeholders, such as patients, physicians,
hospitals, government and the third-party institutions, with different interests
and concerns . Their requirements need to be modeled to possess reusability,
expansibility, adaptive and selfevolving ability. Therefore, RDAA has been
adapted to create a healthcare systems architecture which can guide an analysis
of users’ requirements and build a IT-enabled healthcare system.

The adaptive architecture for healthcare systems

There are five major components, i.e. requirements layer, service layer, process
layer, function layer and data layer, and the mapping mechanisms which
facilitate communications between the layers based on the patterns in their
corresponding layers.
The RDAA’s technique of URP can be used to articulate and model the user’s
requirements for a focal stakeholder, e.g. patients in the requirement layer. A
clear understand of each stakeholder’s needs will form the basis (i.e. URP) for a
business service pattern in the service layer. Service layer interacts with
requirement layer and provides services in certain domains to satisfy user’s

Page.No:15
 Name: Sethumadhavan V
Reg.No:19MIS0010
requirement pattern. Each domain, for example medical domain, has its
particular BSP. A BSP comprises the requirements described by URPs and the
behavioural process. The process enables to deliver the right service required by
the right users. To generically pattern processes for services, the process layer
pre-define some common processes which are likely to be conducted by
hospitals, health bureaus, healthcare communities, and etc.
Each BSP can be supported by the BPPs.A BPP delivers the service by
executing functions which manipulate data from data sources. The functions are
defined in the form of web services which can be invoked by the BPP to
provide the capabilities of the BSP to meet the user’s needs in the URP. The
data layer complies the medical data exchange standard HL7 (Health Level
Seven) and DICOM (Digital Imaging and Communication in Medicine) which
are applied for distributed data sources.

The adaptive architecture for healthcare systems enables the modification of

norms and ontological knowledge according to the changes of society,
organization and environment. The information sharing mechanism supports
interoperation, data sharing, and security control.

Conclusion:
RDAA decompose and organize information services into five levels,
which help to realize specification, components and easy integration of business
logic. By decomposing top-down and organizing for requirement bottom-up, the
commonness and individuality of business requirement in macrocosm and
microcosmic are both unified. The problems of requirement such as variation,
instability and nonstandard represented are resolved. In this paper, we present
RDAA, discuss the layer pattern matching and language study, function call
between layers and operational mechanism in RDAA. RDAA is not only
considering the various management organizations but also using hierarchy and
layer mapping, together with intelligence information processing, semantic web
method and technology, which provide system with feature of self-adaptive,
self-improvement and self-development, being smart to meet user’s
requirement. In technology, RDAA is based on SOA but is advanced than SOA,
and provide information systems with social attributes, highlighting
characteristics of people-cantered.
Our future work includes semi-automatically Constructing the ontological
knowledge for the system. The analysing and modelling of Business Service
Pattern in service layer is also under investigation.

Page.No:16