Notes Prepared By : Sarvagya Jain

Unit -1
Software Development:
The development of software is usually a planned initiative with a number of steps and stages that result in the
creation of operational software. Hence a good definition is: “a process with a set of activities that create
computer software products, including their design, development, testing, and deployment.” Software itself is
a set of instructions or programs that tell a computer what to do. It is independent of hardware and makes
computers programmable.
Software is developed using computer programming, carried out by a software developer. A software
developer definition is “a person that creates software, either by themselves or in conjunction with others.”
What do software developers do day-to-day? They use processes and techniques to create working software,
including requirements definition, data flow design, code design, process flow design, flowcharting, code
creation, software development testing, and debugging. The end-to-end process is sometimes referred to as the
software development life cycle (SDLC). The term ‘full stack software developer’ is someone that develops
both user-facing software and server software, including database development and the development of
application interfaces.
Different Types of Software Development
There are several different types. They can be grouped into four basic categories:
● Application development that provides functionality for users to perform tasks. Examples include
office productivity suites, media players, social media tools, and booking systems. Applications can
run on the user’s own personal computing equipment or on servers hosted in the cloud or by an internal
IT department. Media streaming development is one example of application development for the
cloud.
● System software development to provide the core functions such as operating systems, storage
systems, databases, networks, and hardware management.
● Development tools that provide software developers with the tools to do their job, including code
editors, compilers, linkers, debuggers, and test harnesses.
● Embedded software development that creates the software used to control machines and devices,
including automobiles, phones, and robots.

Different Model of Software Development:

8 Types of Software Development Models:
● Waterfall Model
● V-Model
● Incremental Model
● RAD Model
● Agile Model
● Iterative Model
● Spiral Model
● Prototype Model
The Eight Types of Models in Software Engineering
1. Waterfall Model

Credit: Creative Commons

The Waterfall Model is a linear sequential flow,
often used with projects that have a defined set of
requirements. Reflective of its name, the model’s
process flows steadily downwards through the
phases of software implementation.
This model relies on the completion of the previous
phase for the following to begin. Because the model
does not support going back to previously
completed phases, the Waterfall Model should be
Notes Prepared By : Sarvagya Jain
used with projects that do not anticipate unforeseen changes mid-development.
This approach was one of the earliest models used for software development.
Advantages and Disadvantages of Waterfall
Advantages: Simple and understandable, the Waterfall Model is a manageable method ideal for lifecycle
management of smaller projects where the requirements are established and finalized upfront.
Disadvantages: Because of its rigid structure, the Waterfall Model does not work well for complex projects
where there is a chance of a change in requirements and/or significant impromptu testing throughout the
software development stage.

2. V-Model

An extension of the Waterfall Model, the V-Model also

functions as a sequential flow. However, instead of
only moving linearly downward, the software
development lifecycle bends upwards after the coding
(for each of the testing phases).
For every phase in the downward sequence, there is a
corresponding testing phase in the following upwards
sequence. This model is used for projects where
software requirements and tools are known upfront.
Advantages and Disadvantages of V-Model
Advantages: The V-Model is a simple process that’s
great for smaller projects. Using the V-Model can yield
a higher chance of success due to the test plans of the development stage and regularly schedule updates
throughout its lifecycle.
Disadvantages: Similar to the Waterfall Model, the V-Model is very rigid in nature so it isn’t ideal for
applications or systems software that may require unforeseen changes/updates throughout the software
lifecycle.
3. Incremental Model
The Incremental Model consists of iterative and incremental development stages. The Incremental Model is
essentially composed of several mini Waterfall cycles.
This model divides the development into small sections/stages and it can allow the software developers to take
advantage of learnings and insights gleaned from earlier development stages.
Advantages and Disadvantages of Incremental Model
Advantages: The Incremental Model is a great solution for projects that need accommodation for some change
requests between increments. This model also yields the benefit of being able to detect problems earlier in the
software development for better lifecycle management planning.
Disadvantages: A potential disadvantage to the Incremental Model is the need for strategic planning and
documentation. This method also tends to require more resources, staff and monetary, behind the project. This
model isn’t ideal for ongoing development as the next sequence cannot begin until the previous stage has fully
completed.

4. RAD Model

Short for Rapid Application Development, the RAD

Model is a modification of the Incremental Model.
When implementing this model, several components
are developed simultaneously as if they were
smaller, individual projects. The different
Notes Prepared By : Sarvagya Jain
components are then assembled into working prototypes.
Advantages and Disadvantages of RAD
Advantages: The RAD Model allows for reduced development time and allows for more customer feedback
throughout the software development.
Disadvantages: The applicability of the RAD Model is limited, as the project needs to be easily modularized
into several increments. It also requires highly-versed developers as well as excellent modeling and planning
skills. Issues with the final assembly of components could result in unforeseen setbacks and the redeveloping
of components to properly fit the rest.
5. Agile Model

This model is rooted in process adaptability and user

engagement with rapid delivery of functioning
software components. It has both Iterative and
Incremental features, as it breaks the product
development into small incremental builds that are
then provided in iterations.
The Agile Model relies on heavy collaboration
between cross-functional teams and the
customer/user.
Advantages and Disadvantages of Agile
Advantages: The Agile Model decreases the amount
of time to yield individual system features. It also
calls for a lot of communication and continuous
feedback from the customer/user that can provide
clear direction for the project.
Disadvantages: The Agile method can potentially
veer-off track as it relies on end-user interaction that
may or may not be clearly expressed. Documentation is also minimal for an Agile software development
strategy and requires a well-versed, cross-functional team.

6. Iterative Model

The Iterative Model relies on specifying and

implementing individual parts of the software,
rather than attempting to start with full
specification requirements. Once a rough product
is created within an iteration, it is then reviewed
and improved in the next iteration and so on. The
Iterative Model relies on the whole product being
developed step-by-step (Design/Develop, Test,
Implement).
Advantages and Disadvantages of Iterative Model
Advantages: Since the product is developed
gradually, it’s easy to identify problems early
when using this software development model.
Disadvantages: Because each iteration phase is
rigid with no overlaps, the Iterative Model can
take longer and be more costly.
Notes Prepared By : Sarvagya Jain
7. Spiral Model

The Spiral Model combines elements of both the Iterative and Waterfall development models, in efforts to
combine advantages of top-down and bottom-up production. The Spiral Model has four phases –
Identification, Design, Construct/Build, Evaluation and Risk Analysis. The software project repeatedly passes
through these phases in iterations called spirals.
Advantages and Disadvantages of Spiral Model
Advantages: The Spiral Model can be advantageous as it manages risks and divides development into phases.
It also helps with more accurate estimates for budget and schedule as roadblocks are discovered earlier.
Disadvantages: Since this model is highly customized, repurposing the process can be confusing. It also
requires team members that are well-versed in risk evaluation.
8. Prototype Model

Credit: Testing Excellence

The Prototype Model relies on creating
prototypes of the software applications or
system software that are used to visualize
various components of the software. This
model is used to limit the gap of
misunderstanding of requirements by
providing ample collaboration and feedback
with the user.
Advantages and Disadvantages of Prototype
Model
Advantages: The Prototype Model can yield
reduced time and costs, with heavy user
involvement.
Disadvantages: This model can cause user
confusion between prototype and finished
Notes Prepared By : Sarvagya Jain
product and can potentially add excessive development time for prototype development.
Software Quality Model:
Software quality can be defined as 'conformance to requirements' and/or 'fitness of use‘. Quality is based upon
the customer’s actual experience with the product or service, measured against his or her requirements.
● stated or unstated
● conscious or merely sensed
● technically operational
● entirely subjective
● always representing a moving target
McCall’s Quality Model
Jim McCall produced this model for the US Air Force and the intention was to bridge the gap between users
and developers. He tried to map the user view with the developer's priority. McCall identified three main
perspectives for characterizing the quality attributes of a software product.
These perspectives are:-
● Product revision (ability to change).
● Product transition (adaptability to new environments).
● Product operations (basic operational characteristics).

Product revision The product revision perspective identifies quality factors that influence the ability to
change the software product, these factors are:- Maintainability, the ability to find and fix a defect. Flexibility,
the ability to make changes required as dictated by the business. Testability, the ability to Validate the software
requirements.
Product transition The product transition perspective identifies quality factors that influence the ability to
adapt the software to new environments:- Portability, the ability to transfer the software from one environment
to another. Reusability, the ease of using existing software components in a different context. Interoperability,
the extent, or ease, to which software components work together.

Product operations The product operations perspective identifies quality factors that influence the extent to
which the software fulfils its specification:- Correctness, the functionality matches the specification.
Reliability, the extent to which the system fails. Efficiency, system resource (including cpu, disk, memory,
network) usage. Integrity, protection from unauthorized access. Usability, ease of use.
In total McCall identified the 11 quality factors broken down by the 3 perspectives, as listed above. For each
quality factor McCall defined one or more quality criteria (a way of measurement), in this way an overall
quality assessment could be made of a given software product by evaluating the criteria for each factor. For
example the Maintainability quality factor would have criteria of simplicity, conciseness and modularity.
Boehm's Quality Model
Barry W. Boehm also defined a hierarchical model of software quality characteristics, in trying to qualitatively
define software quality as a set of attributes and metrics (measurements). At the highest level of his model,
Boehm defined three primary uses (or basic software requirements), these three primary uses are:-
As-is utility, the extent to which the as-is software can be used (i.e. ease of use, reliability and efficiency).
Maintainability, ease of identifying what needs to be changed as well as ease of modification and retesting.
Portability, ease of changing software to accommodate a new environment.
These three primary uses had quality factors associated with them , representing the next level of Boehm's
hierarchical model.
Boehm identified seven quality factors, namely:-
Portability: the extent to which the software will work under different computer configurations (i.e. operating
systems, databases etc.).
Reliability: the extent to which the software performs as required, i.e. the absence of defects.
Efficiency: optimum use of system resources during correct execution.
Usability: ease of use.
Testability: ease of validation, that the software meets the requirements.
Notes Prepared By : Sarvagya Jain
Understandability: the extent to which the software is easily comprehended with regard to purpose and
structure.
Flexibility: the ease of changing the software to meet revised requirements.
These quality factors are further broken down into Primitive constructs that can be measured, for example
Testability is broken down into:- accessibility, communicativeness, structure and self descriptiveness. As with
McCall's Quality Model, the intention is to be able to measure the lowest level of the model.
9 ISO 9000 certification
ISO (International Standards Organization) is a consortium of 63 countries established to formulate and foster
standardization. ISO published its 9000 series of standards in 1987. The ISO 9000 standard specifies the
guidelines for maintaining a quality system. The ISO standard mainly addresses operational aspects and
organizational aspects such as responsibilities, reporting, etc.
ISO 9000 specifies a set of guidelines for repeatable and high quality product development. ISO 9000 is a
series of three standards: ISO 9001, ISO 9002, and ISO The ISO 9000 series of standards is based on the
premise that if a proper process is followed for production, then good quality products are bound to follow
automatically. The types of industries to which the different ISO standards apply are as follows.
ISO 9001 applies to the organizations engaged in design, development, production, and servicing of goods.
This is the standard that is applicable to most software development organizations.
ISO 9002 applies to those organizations which do not design products but are only involved in production.
Examples of these category industries include steel and car manufacturing industries.
ISO 9003 applies to organizations that are involved only in installation and testing of the products.
The main requirements of ISO 9001 as:
1) Management Responsibility 2) Quality System 3) Contract Reviews
4) Design Control 5) Document Control 6) Purchasing 7) Purchaser Supplied Product 8) Product Identification
9) Process Control 10) Inspection and Testing 11) Inspection, Measuring and Test Equipment 12) Inspection
and Test Status 13) Control of Nonconforming Product 14) Corrective Action 15) Handling, 16) Quality
records 17) Quality Audits 18) Training
Capability Maturity Model
SEI Capability Maturity Model (SEI CMM) helped organizations to improve the quality of the software.
SEI CMM can be used two ways capability evaluation and software process assessment
The capability evaluation indicates the likely contractor performance if the contractor is awarded a work.
Therefore, we can select a contractor based on its performance.
software process assessment is used by an organization with the objective to improve its process capability.
SEI CMM classifies software development industries into the following five maturity levels.Different levels of
the model have been designed to slowly build its quality system starting from scratch.
Level 1: Initial. A software development organization at this level is characterized by ad hoc activities.
Very few or no processes are defined and followed. Since software production processes are not defined,
different engineers follow their own process and as a result development efforts become chaotic.
Therefore, it is also called chaotic level. The success is only due to some individuals, and when they leave the
organization the people left behind feel great difficulty to understand what has been done and what is to be
done due to lack of processes. This leads to low quality.
Level 2: Repeatable. At this level, the basic project management practices such as tracking cost and schedule
are established.
cost estimation techniques like function point analysis, COCOMO, etc. Are used
The necessary process discipline is in place to repeat earlier success on projects with similar applications.
Hence the existing process is repeated, it is helpful only if we are working on same kind of problems.
Level 3: Defined. At this level the processes for both management and development activities are defined and
documented.
There is a common organization-wide understanding of activities, roles, and responsibilities.
The processes though defined, the process and product qualities are not measured. ISO 9000 aims at achieving
this level.
Level 4: Managed. At this level, the focus is on software metrics. Two types of metrics are collected.
Notes Prepared By : Sarvagya Jain
Product metrics (measures size, reliability, time complexity, understandability) Process metrics (measures
average defect correction time, productivity, average number of defects found per hour inspection)
Quantitative quality goals are set for the products.
The process metrics are used to check if a project performed satisfactorily. Thus, the results of process
measurements are used to evaluate project performance rather than improve the process.

Level 5: Optimizing. At this stage, process and product metrics are collected.
For example, if from an analysis of the process measurement results, it was found that the code reviews were
not very effective and a large number of errors were detected only during the unit testing, then the process
may be fine tuned to make the review more effective. Also lessons learned from specific projects are
incorporated into the process.
Continuous process improvement is achieved both by analyzing the quantitative feedback from the process
measurements and from application of innovative ideas and technologies.
Such an organization identifies the best software engineering practices and innovations which may be tools,
methods, or processes.
Key process areas (KPA) of a software organization: Key Process Areas (KPAs) that includes the areas an
organization should focus to improve its software process to the next level. It provides a way for gradual
quality improvement over several stages.

Personal software process

PSP is suitable for individual use. It is important to note that SEI CMM does not tell software developers how
to analyze, design, code, test, or document software products.
The quality and productivity of an engineer is to a great extent dependent on his process.
PSP is a framework that helps engineers to measure and improve the way they work. It helps in developing
personal skills and methods by estimating and planning, by showing how to track performance against plans,
and provides a defined process which can be tuned by individuals.
Time measurement. PSP advocates that engineers should rack the way they spend time. actual time spent on a
task should be measured with the help of a stop-clock to get an objective picture of the time spent. An
engineer should measure the time he spends for designing, writing code, testing, etc.
PSP Planning. Individuals must plan their project. They must estimate the maximum, minimum, and the
average LOC required for the product.
They should use their productivity in minutes/LOC to calculate the maximum, minimum, and the average
development time. They must record the plan data in a project plan summary.
While carrying out the different phases, they must record the log data using time measurement. Later on it can
be compared the log data with their project plan to achieve better planning in the future projects, to improve
their process, etc.
Software Architecture:
The software architecture of a system represents the design decisions related to overall system structure and
behavior. Architecture helps stakeholders understand and analyze how the system will achieve essential
qualities such as modifiability, availability, and security.
Software architecture consists of four features; software structure, architecture decisions, architecture
characteristics, and design principles described by Mark Richards and Neil Ford.
To properly understand the software architecture, knowledge of the architectural elements, architecture
decisions, and design concepts should also be required.
Notes Prepared By : Sarvagya Jain
Another feature in describing software architecture is software architecture characteristics. Many
characteristics can be defined, and there are no hard and fast rules where any system’s architecture should
comply with all software architecture characteristics.

Evolution of Software Architecture:

One Tier Architecture

One Tier application is also known as a Standalone

application which is the simplest architecture. It is
equivalent to running the application on a personal
computer. So all the required components for an
application to run are on a single application or
server. So the Presentation layer, Business logic
(application)layer, and data layer are all located on a
single machine or a software package. Some of the
examples for one tier architecture is MP3 player and
MS office. So in one-tier architecture data can be
stored in the local system or a shared drive. Speaking
about some of the advantages of this type of systems
are,
1. It’s simple and easy to implement.
2. Very efficient.
3. No compatibility and no context switching
issues
When we think about some of the disadvantages,
1. Since it is only in one machine it does not support remote/ distributed access for data resources.

Two-Tier Architecture

After one-tier architecture, we moved to two-tier

architecture. The two-tier architecture is also known as
client-server application. So this architecture is divided into
two parts. Those are,
1. Client Application (Client Tier)
2. Database (Data Tier)
The client system handles both the Presentation and
Business layer(Application layer) and the Server system
handles the Database layer. So basically what happens is
the client system sends the request to the server system and
the Server system processes the request and sends back the
data to the client system. So the communication takes place
between the client and the server. When we consider the
advantages,
1. Easy to maintain and the modification is a bit easy.
2. Faster communication.
Some of the disadvantages are,
1. Application performance will be decreased when increasing the number of users.
Notes Prepared By : Sarvagya Jain

Three Tier Architecture

After two-tier architecture, we moved to three tier

architecture. Three Tier application is also known as Web
Based application. Three-tier architecture is divided into
three parts:
1. Presentation layer (Client Tier)
2. Application layer (Business Tier)
2. Database layer (Data Tier)
In a three-tier architecture client system handles the
Presentation layer, the Application server handles the
Application layer, and the Server system handles the
Database layer. Now let’s see what are the advantages of
a three-tier architecture,
1. Security is high since the client doesn’t have
direct access to the database.
2. High scalability because each layer run on a
different server
Some of the disadvantages are,
1. Complex structure
N Tier Architecture
Notes Prepared By : Sarvagya Jain

Overview of N tier architecture

N tier architecture also known as multi tier architecture. 3 tier architecture is an example of N tier architecture
but there are n-tier architecture models that have more than three tiers.

Web Servers

Web server is a computer where the web

content is stored and run web sites. So the
basic objective of the webserver is to store,
process and deliver web pages to the users.
Web Servers run only static content and it
can’t run any dynamic content. Static
content means html,css,js,images,pdf files.
Between the user and the web server
intercommunication is done using
Hypertext Transfer Protocol (HTTP). Some
of the web servers are Apache HTTP
Server, Microsoft Internet Information
Services(IIS).
Notes Prepared By : Sarvagya Jain
Web Containers
Web containers can do what web server can do addition to that it can serve dynamic content. Which means
web container can server static content as well as dynamic content. So in here dynamic content means content
of the web page is changing frequently.
Application Server

Application server is a server specifically

designed to run applications. Application server
can do every thing what web container and web
server can do. An application server provides the
processing power and memory to run
applications in real time. Application servers are
more powerful and speed but it’s very expensive
compared to web containers and web servers.
Web server VS Application server
Notes Prepared By : Sarvagya Jain

Service Oriented Architecture(SOA)

Simply put, service oriented architecture

(SOA) is an architectural approach in
which applications make use of services
that are available in the network. So the
services are provided through a
communication call over the internet. So
we can reuse any services in our new
application. Services use common
interface standards and an architectural
pattern so they can be rapidly incorporated
into new applications.
There are two main roles within service
oriented architecture. Those are,
1. Service provider: The service
provider is the maintainer of the service
and the organization that makes available
one or more services for others to use.
2. Service consumer: The service
consumer can locate the service metadata
in the registry and develop the required
client components to bind and use the
service.
Micro Services

In the past when developing applications those are

traditionally built as monolithic pieces of software. So
let’s say we want to add new features so then we need
re-configuring and updating everything from the
process and communications to security within the
application. So traditional monolithic applications have
long life cycles, which are updated infrequently, and
changes usually affect the entire application.
Microservices are self-contained and independent
deployment modules. When it’s come to the
micro-services those are created individually and
deployed separately from one another. Microservices
are an architectural design for building a distributed
application using containers. So services can be rapidly
changed without affecting other parts of the application.
Continuous delivery is one of the many advantages of
microservices.
Some of the key points about microservices are,
Notes Prepared By : Sarvagya Jain
1. Application is broken into modular, loosely coupled components
2. The application can be distributed across clouds and data centers
3. Adding new features only requires those individual microservices to be updated
4. Network services must be software-defined and run as a fabric for each microservice to connect to
Some of the most innovative and profitable microservices examples amongst enterprises companies in the
world like Amazon, Netflix, Uber, and Etsy.
Speaking about some disadvantages of the microservice,
1. Sometimes it’s difficult to manage a large number of services.
2. Complex testing over a distributed environment.
So now you have come to the end of this blog. So I hope you get an idea about the Evolution of Software
Architecture from a standalone system to microservices. You can refer to below links if you need some further
information.
Software Component and Connector:
Component and Connector (C&C) architecture view of a system has two main elements—components and
connectors. Components are usually computational elements or data stores that have some presence during the
system execution. Connectors define the means of interaction between these components.
A C&C view of the system defines the components, and which component is connected to which and through
what connector. A C&C view describes a runtime structure of the system—what components exist when the
system is executing and how they interact during the execution. The C&C structure is essentially a graph, with
components as nodes and connectors as edges. C&C view is perhaps the most common view of architecture
and most box-and-line drawings representing architecture attempt to capture this view. Most often when
people talk about architecture, they refer to the C&C view. Most architecture description languages also focus
on the C&C view.
Components:-Components are generally units of computation or data stores in the system. A component has
a name, which is generally chosen to represent the role of the
component or the function it performs.
A component is of a component-type, where the type represents a
generic component, defining the general computation and the
interfaces a component of that type must have. Note that though a
component has a type, in the C&C architecture view.
In a diagram representing a C&C architecture view of a system, it is
highly desirable to have a different representation for different
component types, so the different types can be identified visually. In
a box-and-line diagram, often all components are represented as
rectangular boxes. Such an approach will require that types of the
components are described separately
and the reader has to read the description to figure out the types of
the components. It is much better to use a different symbol/notation
for each different component type. If there are multiple components
of the same type, then each of these components will be represented
using the same symbol they will be distinguished from each other by
their names. Components use interfaces to communicate with other
components. The interfaces are sometimes called ports. A component must clearly specify itsthe component in
the supporting documents, as a C&C drawing will onlyshow the component names.
It would be useful if there was a list of standard symbols that could be used to build an architecture diagram.
However, as there is no standard list of component types, there is no such standard list.
As there are no standard notations for different component types and an architect can use his own symbols, the
type information cannot be obtained by a reader from the symbols used. To make sure that the meanings of the
different symbols is clear to the reader, it is therefore necessary to have a key of the different symbols to
describe what type of component a symbol represents.
A component is essentially a system in its own right providing some behavior at defined interfaces (i.e., ports)
to its environment. Like any system, a component may be complex and have a structure of its own, which can
Notes Prepared By : Sarvagya Jain
be determined by decomposing the component. In many situations, particularly for systems that are not too
large, there may not be a need to decompose the components to determine their internal architecture.
Connectors: - The different components of a system are likely to interact while the system is in operation to
provide the services expected of the system. After all, components exist to provide parts of the services and
features of the system, and these must be combined to deliver the overall system functionality. For composing
a system from its components, information about the
interaction between components is necessary.
Interaction between components may be through a
simple means supported by the underlying process
execution infrastructure of the operating system. For
example, a component may interact with another using
the procedure call mechanism (a connector,) which is
provided by the runtime environment for the
programming language. However, the interaction may
involve more complex mechanisms as well. Examples of
such mechanisms are remote procedure call, TCP/IP
ports, and a protocol like HTTP. These mechanisms
require a fair amount of underlying runtime
infrastructure, as well as special programming within the
components to use the infrastructure.
Consequently, it is extremely important to identify and
explicitly represent these connectors. Specification of
connectors will help identify the suitable infrastructure
needed to implement an architecture, as well as clarify
the programming needs for components using them. Without a proper understanding of the connectors, a
realization of the components using the connectors may not be possible.
Note that connectors need not be binary and a connector may provide a n-way communication between
multiple components. For example, a broadcast bus may be used as a connector, which allows a component to
broadcast its message to all the other components. (Of course, how such a connector will be implemented is
another issue that must be resolved before the architecture can be implemented. Generally, while creating
architecture, it is wise for the architect to use the connectors, which are available on the systems on which the
software will be deployed. Otherwise, there must be plans to build those connectors, or buy them, if they are
available.)
A connector also has a name that should describe the nature of interaction the connector supports. A connector
also has a type, which is a generic description of the interaction, specifying properties like whether it is a
binary or n-way, types of interfaces it supports, etc. Sometimes, the interaction supported by a connector is
best represented as a protocol. A protocol implies that when two or more components use the connector using
the protocol to communicate, they must follow some conventions about order of events or commands, order in
which data is to be grouped for sending, error condition setc. For example, if TCP ports are to be used to send
information from one process to another (TCP ports are the connector between the two components of process
type), the protocol requires that a connection must first be established and a port number obtained before
sending the information, and that the connection should be closed in the end. A protocol description makes all
these constraints explicit, and defines the error conditions and special scenarios. If a protocol is used by a
connector type, it should be explicitly stated.
Architectural Pattern:
An architectural pattern is a general, reusable solution to a commonly occurring problem in software
architecture within a given context. Architectural patterns are similar to software design pattern but have a
broader scope.
the following 10 common architectural patterns with their usage, pros and cons.
1. Layered pattern
2. Client-server pattern
3. Master-slave pattern
Notes Prepared By : Sarvagya Jain
4. Pipe-filter pattern
5. Broker pattern
6. Peer-to-peer pattern
7. Event-bus pattern
8. Model-view-controller pattern
9. Blackboard pattern
10. Interpreter pattern
1. Layered pattern
This pattern can be used to structure programs that can be decomposed into groups of
subtasks, each of which is at a particular level of abstraction. Each layer provides
services to the next higher layer.
The most commonly found 4 layers of a general information system are as follows.
● Presentation layer (also known as UI layer)
● Application layer (also known as service layer)
● Business logic layer (also known as domain layer)
● Data access layer (also known as persistence layer)
Usage
● General desktop applications.
● E commerce web applications.

2. Client-server pattern

This pattern consists of two parties; a server and multiple clients. The server
component will provide services to multiple client components. Clients request
services from the server and the server provides relevant services to those clients.
Furthermore, the server continues to listen to client requests.
Usage
● Online applications such as email, document sharing and banking.
Client-server pattern

3. Master-slave pattern

This pattern consists of two parties; master and slaves. The

master component distributes the work among identical
slave components, and computes a final result from the
results which the slaves return.
Usage
● In database replication, the master database is
regarded as the authoritative source, and the slave databases
are synchronized to it.
● Peripherals connected to a bus in a computer system
(master and slave drives).
Notes Prepared By : Sarvagya Jain

4. Pipe-filter pattern
This pattern can be used to structure systems which produce and process a stream of data. Each processing
step is enclosed within a filter component. Data to be processed is passed through pipes. These pipes can be
used for buffering or for synchronization purposes.
Usage
● Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and code
generation.
● Workflows in bioinformatics.

5. Broker pattern
This pattern is used to structure distributed systems with
decoupled components. These components can interact
with each other by remote service invocations. A broker
component is responsible for the coordination of
communication among components.
Servers publish their capabilities (services and
characteristics) to a broker. Clients request a service from
the broker, and the broker then redirects the client to a
suitable service from its registry.
Usage
● Message broker software such as Apache
ActiveMQ, Apache Kafka, RabbitMQ and JBoss
Messaging.

6. Peer-to-peer pattern
In this pattern, individual components are known as peers. Peers may
function both as a client, requesting services from other peers, and as a
server, providing services to other peers. A peer may act as a client or as a
server or as both, and it can change its role dynamically with time.
Usage
● File-sharing networks such as Gnutella and G2)
● Multimedia protocols such as P2PTV and PDTP.
● Cryptocurrency-based products such as Bitcoin and Blockchain

7. Event-bus pattern
This pattern primarily deals with events and has 4 major
components; event source, event listener, channel and event bus.
Sources publish messages to particular channels on an event bus.
Listeners subscribe to particular channels. Listeners are notified of
Notes Prepared By : Sarvagya Jain
messages that are published to a channel to which they have subscribed before.
Usage
● Android development
● Notification services

8. Model-view-controller pattern

This pattern, also known as MVC pattern, divides an interactive

application in to 3 parts as,
1. model — contains the core functionality and data
2. view — displays the information to the user (more than
one view may be defined)
3. controller — handles the input from the user
This is done to separate internal representations of information
from the ways information is presented to, and accepted from,
the user. It decouples components and allows efficient code
reuse.
Usage
● Architecture for World Wide Web applications in major programming languages.
● Web frameworks such as Django and Rails.

9. Blackboard pattern
This pattern is useful for problems for which no
deterministic solution strategies are known. The
blackboard pattern consists of 3 main components.
● blackboard — a structured global memory
containing objects from the solution space
● knowledge source — specialized modules
with their own representation
● control component — selects, configures and
executes modules.
All the components have access to the blackboard.
Components may produce new data objects that are
added to the blackboard. Components look for
particular kinds of data on the blackboard, and may
find these by pattern matching with the existing knowledge source.
Usage
● Speech recognition
● Vehicle identification and tracking
● Protein structure identification
● Sonar signals interpretation.
10. Interpreter pattern
This pattern is used for designing a component that interprets programs written in a dedicated language. It
mainly specifies how to evaluate lines of programs, known as sentences or expressions written in a particular
language. The basic idea is to have a class for each symbol of the language.
Usage
● Database query languages such as SQL.
● Languages used to describe communication protocols.
Notes Prepared By : Sarvagya Jain

Software Architecture Framework:

A framework is an integrated collection of components that collaborate to produce a reusable architecture for
a family of related applications.
A software framework is a concrete or conceptual platform where common code with generic functionality
can be selectively specialized or overridden by developers or users. Frameworks take the form of libraries,
where a well-defined application program interface (API) is reusable anywhere within the software under
development.
Examples of frameworks used in development today include: Zend framework for PHP, Spring framework for
Java, .NET Framework (ASP.NET MVC), Django for python, Java Server Faces, Java apache cocoon etc.

Architecture Business Cycle:

“Software architecture is a result of technical, business, and social influences. Its existence in turn affects the
technical, business, and social environments that subsequently influence future architectures. We call this
cycle of influences, from the environment to the architecture and back to the environment, the Architecture
Business Cycle (ABC).”
1. The organization goals of Architecture Business Cycle are beget requirements, which beget an
architecture, which begets a system. The architecture flows from the architect's experience and the
technical environment of the day.

2. Three things required for ABC are as follows:

i. Case studies of successful architectures crafted to satisfy demanding requirements, so as to help set the
technical playing field of the day.

ii. Methods to assess an architecture before any system is built from it, so as to mitigate the risks associated
with launching unprecedented designs. iii.Techniques for incremental architecture-based development, so as to
uncover design flaws before it is too late to correct them.
How the ABC Works :
1. The architecture affects the structure of the developing organization. An architecture prescribes a structure
for a system; as we will see, it particularly prescribes the units of software that must be implemented (or
otherwise obtained) and integrated to form the system. These units are the basis for the development project's
structure. Teams are formed for individual software units; and the development, test, and integration activities
all revolve around the units. Likewise, schedules and budgets allocate resources in chunks corresponding to
the units. If a company becomes adept at building families of similar systems, it will tend to invest in each
team by nurturing each area of expertise. Teams become embedded in the organization's structure. This is
feedback from the architecture to the developing organization.
In the software product line case study, separate groups were given responsibility for building and
maintaining individual portions of the organization's architecture for a family of products. In any design
Notes Prepared By : Sarvagya Jain
undertaken by the organization at large, these groups have a strong voice in the system's decomposition,
pressuring for the continued existence of the portions they control.
2. The architecture can affect the goals of the developing organization. A successful system built from it can
enable a company to establish a foothold in a particular market area. The architecture can provide
opportunities for the efficient
production and deployment of similar systems, and the organization may adjust its goals to take advantage of
its newfound expertise to plumb the market. This is feedback from the system to the developing organization
and the systems it builds.

3. The architecture can affect customer requirements for the next system by giving the customer the
opportunity to receive a system (based on the same architecture) in a more reliable, timely, and economical
manner than if the subsequent system were to be built from scratch. The customer may be willing to relax
some requirements to gain these economies. Shrink-wrapped software has clearly affected people's
requirements by providing solutions that are not tailored to their precise needs but are instead inexpensive and
(in the best of all possible worlds) of high quality. Product lines have the same effect on customers who cannot
be so flexible with their requirements. A Case Study in Product Line Development will show how a product
line architecture caused customers to happily compromise their requirements because they could get
high-quality software that fit their basic needs quickly, reliably, and at lower cost.

4. The process of system building will affect the architect's experience with subsequent systems by adding to
the corporate experience base. A system that was successfully built around a tool bus or .NET or encapsulated
finite-state machines will engender similar systems built the same way in the future. On the other hand,
architectures that fail are less likely to be chosen for future projects.

5. A few systems will influence and actually change the software engineering culture, that is, the technical
environment in which system builders operate and learn. The first relational databases, compiler generators,
and table-driven operating systems had this effect in the 1960s and early 1970s; the first spreadsheets and
windowing systems, in the 1980s. The World Wide Web is the example for the 1990s. J2EE may be the
example for the first decade of the twenty-first century. When such pathfinder systems are constructed,
subsequent systems are affected by their legacy.
These and other feedback mechanisms form what we call the ABC, illustrated in Figure , which depicts the
influences of the culture and business of the development organization on the software architecture. That
architecture is, in turn, a primary determinant of the properties of the developed system or systems. But the
ABC is also based on a recognition that shrewd organizations can take advantage of the organizational and
experiential effects of developing an architecture and can use those effects to position their business
strategically for future projects.
Reference model :
According to OASIS (Organization for the Advancement of Structured Information Standards) a reference
model is "an abstract framework for understanding significant relationships among the entities of some
environment, and for the development of consistent standards or specifications supporting that environment. A
reference model is based on a small number of unifying concepts and may be used as a basis for education and
explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies
or other concrete implementation details, but it does seek to provide a common semantics that can be used
unambiguously across and between different implementations.
here are a number of concepts rolled up into that of a 'reference model.' Each of these concepts is important:
1. Abstract: a reference model is abstract. It provides information about environments of a certain kind. A
reference model describes the type or kind of entities that may occur in such an environment, not the
particular entities that actually do occur in a specific environment. For example, when describing the
architecture of a particular house (which is a specific environment of a certain kind), an actual exterior
wall may have dimensions and materials, but the concept of a wall (type of entity) is part of the
reference model. One must understand the concept of a wall in order to build a house that has walls.
Notes Prepared By : Sarvagya Jain
2. Entities and relationships: A reference model describes both types of entities (things that exist) and
their relationships (how they connect, interact with one another, and exhibit joint properties). A list of
entity types, by itself, doesn't provide enough information to serve as a reference model.
3. Within an environment: A reference model does not attempt to describe "all things." A reference
model is used to clarify "things within an environment" or a problem space. To be useful, a reference
model should include a clear description of the problem that it solves, and the concerns of the
stakeholders who need to see the problem get solved.
4. Technology agnostic: A reference model's usefulness is limited if it makes assumptions about the
technology or platforms in place in a particular computing environment. A reference model typically is
intended to promote understanding a class of problems, not specific solutions for those problems. As
such, it must assist the practitioner by aiding the process of imagining and evaluating a variety of
potential solutions. That does not preclude the development of a reference model that describes a set of
software applications, because the problem space may be "how to manage a set of software
applications."
The uses of a reference model
There are many uses for a reference model. One use is to create standards for both the objects that inhabit the
model and their relationships to one another.
Another use of a reference model is to educate.
A third use of a reference model is to improve communication between people.
A fourth use of a reference model is to create clear roles and responsibilities.
A fifth use of a reference model is to allow the comparison of different things.
Architectural Patterns, Reference Models, and Reference Architectures
Between box-and-line sketches that are the barest of starting points and full-fledged architectures, with all of
the appropriate information about a system filled in, lie a host of intermediate stages. Each stage represents the
outcome of a set of architectural decisions, the binding of architectural choices. Some of these intermediate
stages are very useful in their own right. Before discussing architectural structures, we define three of them.
1. An architectural pattern is a description of element and relation types together with a set of constraints on
how they may be used. A pattern can be thought of as a set of constraints on an architecture-on the element
types and their patterns of interaction-and these constraints define a set or family of architectures that satisfy
them. For example, client-server is a common architectural pattern. Client and server are two element types,
and their coordination is described in terms of the protocol that the server uses to communicate with each of
its clients. Use of the term client-server implies only that multiple clients exist; the clients themselves are not
identified, and there is no discussion of what functionality, other than implementation of the protocols, has
been assigned to any of the clients or to the server. Countless architectures are of the client-server pattern
under this (informal) definition, but they are different from each other. An architectural pattern is not an
architecture, then, but it still conveys a useful image of the system-it imposes useful constraints on the
architecture and, in turn, on the system.
2. A reference model is a division of functionality together with data flow between the pieces. A reference
model is a standard decomposition of a known problem into parts that cooperatively solve the problem.
Arising from experience, reference models are a characteristic of mature domains. Can you name the standard
parts of a compiler or a database management system? Can you explain in broad terms how the parts work
together to accomplish their collective purpose? If so, it is because you have been taught a reference model of
these applications.
3. A reference architecture is a reference model mapped onto software elements (that cooperatively implement
the functionality defined in the reference model) and the data flows between them. Whereas a reference model
divides the functionality, a reference architecture is the mapping of that functionality onto a system
decomposition. The mapping may be, but by no means necessarily is, one to one. A software element may
implement part of a function or several functions.
Notes Prepared By : Sarvagya Jain
Notes Prepared By : Sarvagya Jain
Unit -2
Software Architecture Model:
Software architecture involves the high level structure of software system abstraction, by using
decomposition and composition, with architectural style and quality attributes. A software architecture
design must conform to the major functionality and performance requirements of the system, as well as
satisfy the non-functional requirements such as reliability, scalability, portability, and availability.
A software architecture must describe its group of components, their connections, interactions among them
and deployment configuration of all components.
A software architecture can be defined in many ways −
● UML (Unified Modeling Language) − UML is one of object-oriented solutions used in software
modeling and design.
● Architecture View Model (4+1 view model) − Architecture view model represents the functional and
non-functional requirements of software application.
● ADL (Architecture Description Language) − ADL defines the software architecture formally and
semantically.
Structural models
Structural models of software display the organization of a system in terms of the components that make up
that system and their relationships. Structural models may be static models, which show the structure of the
system design, or dynamic models, which show the organization of the system when it is executing. You
create structural models of a system when you are discussing and designing the system architecture.
UML class diagrams are used when developing an object-oriented system model to show the classes in a
system and the associations between these classes. An object class can be thought of as a general definition
of one kind of system object. An association is a link between classes that indicates that there is some
relationship between these classes. When you are developing models during the early stages of the software
engineering process, objects represent something in the real world, such as a patient, a prescription, doctor,
etc.

Generalization is an everyday technique that we use to manage complexity. In modeling systems, it is often
useful to examine the classes in a system to see if there is scope for generalization. In object-oriented
languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the
language. In a generalization, the attributes and operations associated with higher-level classes are also
associated with the lower-level classes. The lower-level classes are subclasses that inherit the attributes and
Notes Prepared By : Sarvagya Jain
operations from their superclasses. These lower-level classes then add more specific attributes and
operations.

An aggregation model shows how classes that are collections are composed of other classes. Aggregation
models are similar to the part-of relationship in semantic data models.

Dynamic Model: The dynamic model is used to express and model the behaviour of the system over time.
It includes support for activity diagrams, state diagrams, sequence diagrams and extensions including
business process modelling.
Sequence Diagrams
Sequence diagrams are used to display the interaction between users, screens, objects and entities within the
system. It provides a sequential map of message passing between objects over time. Frequently these
diagrams are placed under Use Cases in the model to illustrate the use case scenario - how a user will
interact with the system and what happens internally to get the work done. Often, the objects are represented
using special stereotyped icons, as in the example below. The object labelled Login Screen is shown using
the User Interface icon. The object labelled SecurityManager is shown using the Controller icon. The Object
labelled users is shown using the Entity icon.
Notes Prepared By : Sarvagya Jain

Activity Diagrams
Activity diagrams are used to show how different workflows in the system are constructed, how they start
and the possibly many decision paths that can be taken from start to finish. They may also illustrate where
parallel processing may occur in the execution of some activities.
Notes Prepared By : Sarvagya Jain

State Charts
State charts are used to detail the transitions or changes of state an object can go through in the system. They
show how an object moves from one state to another and the rules that govern that change. State charts
typically have a start and end condition.

Process Model
A process model is a UML extension of an activity diagram used to model a business process - this diagram
shows what goal the process has, the inputs, outputs, events and information that are involved in the process.
Notes Prepared By : Sarvagya Jain

Framework Model:
An architecture framework is an encapsulation of a minimum set of practices and requirements for artifacts
that describe a system's architecture. Models are representations of how objects in a system fit structurally in
and behave as part of the system. Views are a partial expression of the system from a particular perspective.
A viewpoint is a set of representations (views and models) of an architecture that covers a stakeholder's
issues.

Architectural Styles:
The architectural styles that are used while designing the software as follows:

1. Data-centered architecture
● The data store in the file or database is occupying at the center of the architecture.
● Store data is access continuously by the other components like an update, delete, add, modify from
the data store.
● Data-centered architecture helps integrity.
● Pass data between clients using the blackboard mechanism.
● The processes are independently executed by the client components.
Notes Prepared By : Sarvagya Jain

2. Data-flow architecture
● This architecture is applied when the input data is converted into a series of manipulative
components into output data.
● A pipe and filter pattern is a set of components called as filters.
● Filters are connected through pipes and transfer data from one component to the next component.
● The flow of data degenerates into a single line of transform then it is known as batch sequential.

3. Call and return architectures

This architecture style allows to achieve a program structure which is easy to modify.

Following are the sub styles exist in this category:

1. Main program or subprogram architecture

● The program is divided into smaller pieces hierarchically.
● The main program invokes many of program components in the hierarchy that program components
are divided into subprogram.
2. Remote procedure call architecture
● The main program or subprogram components are distributed in network of multiple computers.
● The main aim is to increase the performance.
Notes Prepared By : Sarvagya Jain

4. Layered architectures
● The different layers are defined in the architecture. It consists of outer and inner layer.
● The components of outer layer manage the user interface operations.
● Components execute the operating system interfacing at the inner layer.
● The inner layers are application layer, utility layer and the core layer.
● In many cases, It is possible that more than one pattern is suitable and the alternate architectural style
can be designed and evaluated.

Microservice Architecture:
Microservices architecture (often shortened to microservices) refers to an architectural style for developing
applications. Microservices allow a large application to be separated into smaller independent parts, with
each part having its own realm of responsibility. To serve a single user request, a microservices-based
application can call on many internal microservices to compose its response.
Containers are a well-suited microservices architecture example, since they let you focus on developing the
services without worrying about the dependencies. Modern cloud-native applications are usually built as
microservices using containers.
A microservices architecture is a type of application architecture where the application is developed as a
collection of services. It provides the framework to develop, deploy, and maintain microservices architecture
diagrams and services independently.
microservices architecture consists of a collection of small, autonomous services. Each service is
self-contained and should implement a single business capability within a bounded context. A bounded
context is a natural division within a business and provides an explicit boundary within which a domain
model exists.
Notes Prepared By : Sarvagya Jain

Reactive Architecture
Reactive systems architecture is a computer systems paradigm that takes advantage of the responsiveness,
flexibility and resiliency offered in reactive programming so that various components (e.g., software
applications, databases and servers) can continue to function and even thrive if one of the components is
compromised.
The reactive programming on which reactive systems architecture allows -- at its simplest expression -- data
to automatically change when related data changes. So, for example, in the expression a = b + c, if either b
or c changes, then the value of a will change automatically when a notification of the change to b or c to is
sent. The change represented by b or c might be a change in availability, while a might be the price.

Representational state transfer (REST):

Representational state transfer (REST) is a software architectural style that was created to guide the design
and development of the architecture for the World Wide Web. REST defines a set of constraints for how the
architecture of an Internet-scale distributed hypermedia system, such as the Web, should behave. The REST
architectural style emphasises the scalability of interactions between components, uniform interfaces,
independent deployment of components, and the creation of a layered architecture to facilitate caching
components to reduce user-perceived latency, enforce security, and encapsulate legacy systems.
The REST architectural style is designed for network-based applications, specifically client-server
applications. But more than that, it is designed for Internet-scale usage, so the coupling between the user
agent (client) and the origin server must be as lightweight (loose) as possible to facilitate large-scale
adoption. This is achieved by creating a layer of abstraction on the server by defining resources that
encapsulate entities (e.g. files) on the server and so hiding the underlying implementation details (file server,
database, etc.). But the definition is even more general than that: any information that can be named can be a
Notes Prepared By : Sarvagya Jain
resource: an image, a database query, a temporal service (e.g. “today’s weather in London”), or even a
collection of other resources. This approach allows the greatest interoperability between clients and servers
in a long-lived Internet-scale environment which crosses organisational (trust) boundaries.
Clients can only access resources using URIs. In other words, the client requests a resource using a URI and
the server responds with a representation of the resource. A representation of a resource is another important
concept in REST; to ensure responses can be interpreted by the widest possible number of client applications
a representation of the resource is sent in hypertext format. Thus, a resource is manipulated through
hypertext representations transferred in messages between the clients and servers.
Notes Prepared By : Sarvagya Jain
Unit-3
Architecture Description Language:
Architecture description languages (ADLs) are formal languages that can be used to represent
the architecture of a software system. Architecture Description Language (ADL) is defined as
"a language (graphical, textual, or both) for describing a software system in terms of its
architectural elements and the relationship among them"

Elements of ADL
• Components
– Primitive building blocks
• Connectors
– Mechanisms of combining components
• Abstraction
– Rules for referring to the combination of components and connectors
Important Properties of ADL
● Composition – composition of independent components and connections
● Abstraction – need to describe design elements clearly and explicitly
● Reusability – ability to reuse components, connectors in different architectural
descriptions
● Configuration – ability to understand and change the architectural structure
● Heterogeneity – ability to combine multiple, heterogeneous architectural descriptions
● Analysis - possible to perform rich and varied analysis of architectural description

Struts Framework:
Struts is an open source framework that extends the Java Servlet API and employs a
Model, View, Controller (MVC) architecture. It enables you to create maintainable,
extensible, and flexible web applications based on standard technologies, such as JSP
pages, JavaBeans, resource bundles, and XML.
When you use Struts, the framework provides you with a controller servlet,
ActionServlet, which is defined in the Struts libraries that are included in the IDE, and
which is automatically registered in the web.xml deployment descriptor.
The controller servlet uses a struts-config.xml file to map incoming requests to Struts
Action objects, and instantiate any ActionForm objects associated with the action to
temporarily store form data. The Action object processes requests using its execute
method, while making use of any data stored in the form bean. Once the Action object
Notes Prepared By : Sarvagya Jain
processes a request, it stores any new data (i.e., in the form bean, or in a separate result
bean), and forwards the results to the appropriate view.

Step 1 - Create The Model Class MessageStore.java

MessageStore.java
package org.apache.struts.helloworld.model;
public class MessageStore {
private String message;

public MessageStore() {
message = "Hello Struts User";
}

public String getMessage() {

return message;
}
}

Step 2 - Create The Action Class HelloWorldAction.java

HelloWorldAction.java
package org.apache.struts.helloworld.action;
import org.apache.struts.helloworld.model.MessageStore;
import com.opensymphony.xwork2.ActionSupport;
public class HelloWorldAction extends ActionSupport {
private MessageStore messageStore;
public String execute() {
messageStore = new MessageStore() ;
return SUCCESS;
}
public MessageStore getMessageStore() {
Notes Prepared By : Sarvagya Jain
return messageStore;
}
}

Step 3 - Create The View HelloWorld.jsp

HelloWorld.jsp
<!DOCTYPE html>
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Hello World!</title>
</head>
<body>
<h2><s:property value="messageStore.message" /></h2>
</body>
</html>

Step 4 - Add The Struts Configuration In struts.xml

struts.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
"http://struts.apache.org/dtds/struts-2.5.dtd">
<struts>
<constant name="struts.devMode" value="true" />
<package name="basicstruts2" extends="struts-default">
<action name="index">
<result>/index.jsp</result>
</action>
<action name="hello"
class="org.apache.struts.helloworld.action.HelloWorldAction" method="execute">
<result name="success">/HelloWorld.jsp</result>
</action>
</package>
</struts>
Step 5 - Create The URL Action
index.jsp
<!DOCTYPE html>
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Basic Struts 2 Application - Welcome</title>
</head>
<body>
<h1>Welcome To Struts 2!</h1>
<p><a href="<s:url action='hello'/>">Hello World</a></p>
Notes Prepared By : Sarvagya Jain
</body>
</html>
Step 6 - Build the WAR File and Run The Application
Execute mvn jetty:run to run the application.
Go to this URL http://localhost:8080/helloworld/index.action where you should see the
following:

Hibernate Framework
Hibernate is a Java framework that simplifies the development of Java application to interact
with the database. It is an open source, lightweight, ORM (Object Relational Mapping) tool.
Hibernate implements the specifications of JPA (Java Persistence API) for data persistence.
ORM Tool
An ORM tool simplifies the data creation, data manipulation and data access. It is a
programming technique that maps the object to the data stored in the database.

The ORM tool internally uses the JDBC API to interact with the database.
Java Persistence API (JPA) is a Java specification that provides certain functionality and
standard to ORM tools. The javax.persistence package contains the JPA classes and
interfaces.
The Hibernate architecture includes many objects such as persistent object, session factory,
transaction factory, connection factory, session, transaction etc.
The Hibernate architecture is categorized in four layers.
● Java application layer
● Hibernate framework layer
● Backhand api layer
● Database layer
Let's see the diagram of hibernate
architecture:
This is the high level architecture of
Hibernate with mapping file and
configuration file.
Notes Prepared By : Sarvagya Jain

Hibernate framework uses many objects such as session factory, session, transaction etc.
alongwith existing Java API such as JDBC (Java Database Connectivity), JTA (Java
Transaction API) and JNDI (Java Naming Directory Interface).
Elements of Hibernate Architecture
For creating the first hibernate application, we must know the elements of Hibernate
architecture. They are as follows:
SessionFactory
The SessionFactory is a factory of session and client of ConnectionProvider. It holds a second
level cache (optional) of data. The org.hibernate.SessionFactory interface provides a factory
method to get the object of Session.
Session
The session object provides an interface between the application and data stored in the
database. It is a short-lived object and wraps the JDBC connection. It is factory of
Transaction, Query and Criteria. It holds a first-level cache (mandatory) of data. The
org.hibernate.Session interface provides methods to insert, update and delete the object. It
also provides factory methods for Transaction, Query and Criteria.
Transaction
The transaction object specifies the atomic unit of work. It is optional. The
org.hibernate.Transaction interface provides methods for transaction management.
ConnectionProvider
It is a factory of JDBC connections. It abstracts the application from DriverManager or
DataSource. It is optional.
TransactionFactory
It is a factory of Transactions. It is optional.
First Hibernate Example without IDE
Steps to create first Hibernate Application
1. Create the Persistent class
2. Create the mapping file for Persistent class
3. Create the Configuration file
4. Create the class that retrieves or stores the persistent object
Notes Prepared By : Sarvagya Jain
5. Load the jar file
6. Run the first hibernate application without IDE
Here, we are going to create the first hibernate application without IDE. For creating the first
hibernate application, we need to follow the following steps:
1. Create the Persistent class
2. Create the mapping file for Persistent class
3. Create the Configuration file
4. Create the class that retrieves or stores the persistent object
5. Load the jar file
6. Run the first hibernate application by using command prompt
1) Create the Persistent class
A simple Persistent class should follow some rules:
● A no-arg constructor: It is recommended that you have a default constructor at least
package visibility so that hibernate can create the instance of the Persistent class by
newInstance() method.
● Provide an identifier property: It is better to assign an attribute as id. This attribute
behaves as a primary key in database.
● Declare getter and setter methods: The Hibernate recognizes the method by getter
and setter method names by default.
● Prefer non-final class: Hibernate uses the concept of proxies, that depends on the
persistent class. The application programmer will not be able to use proxies for lazy
association fetching.
Let's create the simple Persistent class:
Employee.java
package com.javatpoint.mypackage;
public class Employee {
private int id;
private String firstName,lastName;

public int getId() {

return id;
}
public void setId(int id) {
this.id = id;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}

2) Create the mapping file for Persistent class

Notes Prepared By : Sarvagya Jain
The mapping file name conventionally, should be class_name.hbm.xml. There are many
elements of the mapping file.
● hibernate-mapping : It is the root element in the mapping file that contains all the
mapping elements.
● class : It is the sub-element of the hibernate-mapping element. It specifies the
Persistent class.
● id : It is the subelement of class. It specifies the primary key attribute in the class.
● generator : It is the sub-element of id. It is used to generate the primary key. There
are many generator classes such as assigned, increment, hilo, sequence, native etc. We
will learn all the generator classes later.
● property : It is the sub-element of class that specifies the property name of the
Persistent class.
Let's see the mapping file for the Employee class: employee.hbm.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 5.3//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-5.3.dtd">
<hibernate-mapping>
<class name="com.javatpoint.mypackage.Employee" table="emp1000">
<id name="id">
<generator class="assigned"></generator>
</id>
<property name="firstName"></property>
<property name="lastName"></property>
</class>
</hibernate-mapping>

3) Create the Configuration file

The configuration file contains information about the database and mapping file.
Conventionally, its name should be hibernate.cfg.xml .
hibernate.cfg.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 5.3//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-5.3.dtd">
<hibernate-configuration>
<session-factory>
<property name="hbm2ddl.auto">update</property>
<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
<property name="connection.url">jdbc:oracle:thin:@localhost:1521:xe</property>
<property name="connection.username">system</property>
<property name="connection.password">jtp</property>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
<mapping resource="employee.hbm.xml"/>
</session-factory>
</hibernate-configuration>

4) Create the class that retrieves or stores the object

In this class, we are simply storing the employee object to the database.
package com.javatpoint.mypackage;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
Notes Prepared By : Sarvagya Jain
import org.hibernate.Transaction;
import org.hibernate.boot.Metadata;
import org.hibernate.boot.MetadataSources;
import org.hibernate.boot.registry.StandardServiceRegistry;
import org.hibernate.boot.registry.StandardServiceRegistryBuilder;

public class StoreData {

public static void main(String[] args) {
//Create typesafe ServiceRegistry object
StandardServiceRegistry ssr = new
StandardServiceRegistryBuilder().configure("hibernate.cfg.xml").build();
Metadata meta = new MetadataSources(ssr).getMetadataBuilder().build();
SessionFactory factory = meta.getSessionFactoryBuilder().build();
Session session = factory.openSession();
Transaction t = session.beginTransaction();
Employee e1=new Employee();
e1.setId(101);
e1.setFirstName("Gaurav");
e1.setLastName("Chawla");
session.save(e1);
t.commit();
System.out.println("successfully saved");
factory.close();
session.close();
}
}

5) Load the jar file

For successfully running the hibernate application, you should have the hibernate5.jar file.
6) How to run the first hibernate application without IDE
We may run this hibernate application by IDE (e.g. Eclipse, Myeclipse, Netbeans etc.) or
without IDE. We will learn about creating a hibernate application in Eclipse IDE in next
chapter.
To run the hibernate application without IDE:
● Install the oracle 10g for this example.
● Load the jar files for hibernate. (One of the way to load the jar file is copy all the jar
files under the JRE/lib/ext folder). It is better to put these jar files inside the public and
private JRE both.
● Now, run the StoreData class by java com.javatpoint.mypackage.StoreData
Notes Prepared By : Sarvagya Jain

Node.js
Node.js is a very powerful JavaScript-based platform built on Google Chrome's JavaScript
V8 Engine. It is used to develop I/O intensive web applications like video streaming sites,
single-page applications, and other web applications. Node.js is open source, completely free,
and used by thousands of developers around the world.Node.js is an open source,
cross-platform runtime environment for developing server-side and networking applications.
Node.js applications are written in JavaScript, and can be run within the Node.js runtime on
OS X, Microsoft Windows, and Linux.Node.js also provides a rich library of various
JavaScript modules which simplifies the development of web applications using Node.js to a
great extent.
Node.js = Runtime Environment + JavaScript Library
The following diagram depicts some important parts of Node.js

Creating Node.js Application

Step 1 - Import Required Module
Notes Prepared By : Sarvagya Jain
We use the require directive to load the http module and store the returned HTTP instance
into an http variable as follows −
var http = require("http");
Step 2 - Create Server
We use the created http instance and call http.createServer() method to create a server
instance and then we bind it at port 8081 using the listen method associated with the server
instance. Pass it a function with parameters request and response. Write the sample
implementation to always return "Hello World".
http.createServer(function (request, response) {
// Send the HTTP header
// HTTP Status: 200 : OK
// Content Type: text/plain
response.writeHead(200, {'Content-Type': 'text/plain'});
// Send the response body as "Hello World"
response.end('Hello World\n');
}).listen(8081);
// Console will print the message
console.log('Server running at http://127.0.0.1:8081/');
The above code is enough to create an HTTP server which listens, i.e., waits for a request
over 8081 port on the local machine.
Step 3 - Testing Request & Response
Let's put step 1 and 2 together in a file called main.js and start our HTTP server as shown
below −
var http = require("http");
http.createServer(function (request, response) {
// Send the HTTP header
// HTTP Status: 200 : OK
// Content Type: text/plain
response.writeHead(200, {'Content-Type': 'text/plain'});
// Send the response body as "Hello World"
response.end('Hello World\n');
}).listen(8081);
// Console will print the message
console.log('Server running at http://127.0.0.1:8081/');
Now execute the main.js to start the server as follows −
$ node main.js
Verify the Output. Server has started.
Server running at http://127.0.0.1:8081/
Make a Request to the Node.js Server
Open http://127.0.0.1:8081/ in any browser and observe the following result.
Notes Prepared By : Sarvagya Jain

AngularJS
AngularJS is a very powerful JavaScript Framework. It is used in Single Page Application
(SPA) projects. It extends HTML DOM with additional attributes and makes it more
responsive to user actions. AngularJS is open source, completely free, and used by thousands
of developers around the world. It is licensed under the Apache license version 2.0.AngularJS
is a MVC based framework.
An AngularJS application consists of following three important parts −
● ng-app − This directive defines and links an AngularJS application to HTML.
● ng-model − This directive binds the values of AngularJS application data to HTML
input controls.
● ng-bind − This directive binds the AngularJS Application data to HTML tags.
Creating AngularJS Application
Step 1: Load framework
Being a pure JavaScript framework, it can be added using <Script> tag.
<script
src = "https://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">
</script>

Step 2: Define AngularJS application using ng-app directive

<div ng-app = "">
...
</div>
Step 3: Define a model name using ng-model directive
<p>Enter your Name: <input type = "text" ng-model = "name"></p>
Step 4: Bind the value of above model defined using ng-bind directive
<p>Hello <span ng-bind = "name"></span>!</p>
Executing AngularJS Application
Use the above-mentioned three steps in an HTML page.
testAngularJS.htm
<html>
<head>
<title>AngularJS First Application</title>
</head>
<body>
Notes Prepared By : Sarvagya Jain
<h1>Sample Application</h1>
<div ng-app = "">
<p>Enter your Name: <input type = "text" ng-model = "name"></p>
<p>Hello <span ng-bind = "name"></span>!</p>
</div>
<script src = "https://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">
</script>
</body>
</html>
Output
Open the file testAngularJS.htm in a web browser. Enter your name and see the result.
J2EE
Java 2 Platform, Enterprise Edition which is also known as J2EE is a Java API collection
owned by Oracle. It is used by programmers for creating server-side applications. J2EE is a
set of specifications, which define the standard for developing multi-tier enterprise
applications with Java. The J2EE platform provides a complete framework for design,
development, assembly, and deployment of Java applications built on multi-tiered distributed
application models.The J2EE specification defines numerous API services and multiple
application programming models for developing applications and integrating them with the
enterprise systems. The latest J2EE 1.3 APIs include the following:
● Enterprise JavaBeans (EJB) 2.0
● J2EE Connector Architecture (JCA) 1.0
● JDBC 2.0 (for database connectivity)
● JavaServer Pages (JSP) 1.2
● Servlet 2.3
● Java Transaction API (JTA) 1.0.1
● Java Messaging Service (JMS) 1.0.2
● Java Name and Directory Interface (JNDI) 1.2
● Java RMI 1.0 ● RMI/IIOP 1.0
● Java Authentication and Authorization Service (JAAS) 1.0
● JavaMail 1.1
● Java API for XML Parsing (JAXP) 1.1

How J2EE Framework works?

The Java application’s server-side development steps involve:
1. Write code that makes use of core technologies in Java EE
Notes Prepared By : Sarvagya Jain
2. Compile the created code to bytecode
3. Package the created bytecode as well as resources associated with it into an EAR,
Enterprise Archive file
4. Deploy the Enterprise Archive file to an application server
JSP (Java Server Page):
Java Server Pages (JSP) is a server-side programming technology that enables the creation of
dynamic, platform-independent methods for building Web-based applications. JSP have
access to the entire family of Java APIs, including the JDBC API to access enterprise
databases. This tutorial will teach you how to use Java Server Pages to develop your web
applications in simple and easy steps.
JavaServer Pages (JSP) is a technology for developing Webpages that supports dynamic
content. This helps developers insert java code in HTML pages by making use of special JSP
tags, most of which start with <% and end with %>.
A JavaServer Pages component is a type of Java servlet that is designed to fulfill the role of a
user interface for a Java web application. Web developers write JSPs as text files that
combine HTML or XHTML code, XML elements, and embedded JSP actions and
commands.
Using JSP, you can collect input from users through Webpage forms, present records from a
database or another source, and create Webpages dynamically.
JSP tags can be used for a variety of purposes, such as retrieving information from a
database or registering user preferences, accessing JavaBeans components, passing control
between pages, and sharing information between requests, pages etc.
JSP ARCHITECTURE:
The web server needs a JSP engine, i.e, a container to process JSP pages. The JSP container
is responsible for intercepting requests for JSP pages. This tutorial makes use of Apache
which has a built-in JSP container to support JSP pages development.
A JSP container works with the Web server to provide the runtime environment and other
services a JSP needs. It knows how to understand the special elements that are part of JSPs.
Following diagram shows the position of JSP containers and JSP files in a Web application.

Elements of JSP
The elements of JSP have been described below −
The Scriptlet
A scriptlet can contain any number of JAVA language statements, variable or method
declarations, or expressions that are valid in the page scripting language.
Following is the syntax of Scriptlet −
<% code fragment %>
You can write the XML equivalent of the above syntax as follows −
<jsp:scriptlet>
code fragment
Notes Prepared By : Sarvagya Jain
</jsp:scriptlet>
Any text, HTML tags, or JSP elements you write must be outside the scriptlet. Following is
the simple and first example for JSP −
<html>
<head><title>Hello World</title></head>
<body>
Hello World!<br/>
<%
out.println("Your IP address is " + request.getRemoteAddr());
%>
</body>
</html>
NOTE − Assuming that Apache Tomcat is installed in C:\apache-tomcat-7.0.2 and your
environment is setup as per environment setup tutorial.
Let us keep the above code in JSP file hello.jsp and put this file in
C:\apache-tomcat7.0.2\webapps\ROOT directory. Browse through the same using URL
http://localhost:8080/hello.jsp. The above code will generate the following result −

Servlet :
Servlet can be described in many ways, depending on the context.
● Servlet is a technology which is used to create a web application.
● Servlet is an API that provides many interfaces and classes including documentation.
● Servlet is an interface that must be implemented for creating any Servlet.
● Servlet is a class that extends the capabilities of the servers and responds to the
incoming requests. It can respond to any requests.
● Servlet is a web component that is deployed on the server to create a dynamic web
page.
Servlets are the Java programs that run on the Java-enabled web server or application server.
They are used to handle the request obtained from the webserver, process the request, produce
the response, then send a response back to the webserver.
Servlet Architecture is can be depicted from the image itself as provided below as follows:
Notes Prepared By : Sarvagya Jain

Execution of Servlets basically involves six basic steps:

1. The clients send the request to the web server.
2. The web server receives the request.
3. The web server passes the request to the corresponding servlet.
4. The servlet processes the request and generates the response in the form of output.
5. The servlet sends the response back to the webserver.
6. The web server sends the response back to the client and the client browser
displays it on the screen.
JSP - Servlets: A servlet example
This section is going to show you a step by step to implement a simple servlet example and
run it. The example is going to:
● Ask the user for a color in a JSP - in our example it will be "Home.jsp"
● Display "Hello World" in the chosen color using a servlet - in our example it will be
"helloWorld.java"
Steps
1. Create a new project
○ In the menu bar, File / new / Dynamic web project.
○ Name your project - to be consistent with the example, name it
"ServletExample". This By choosing "Dynamic web project", eclipse creates
the default folders hierarchy. The folders hierarchy is shown in the "Project
Notes Prepared By : Sarvagya Jain
Explorer" view at the left side of the eclipse window.If it is not shown, you can

○ show it from the menu bar, Window / Show View / Project Explorer. It should
look like that:
○ JSP, CSS files, images… etc will be placed in the "WebContent" folder. Java
files (Servlets) will be placed in the "Java Resources: src" folder.
2. Create the JSP file
○ In the "Project Explorer" view, R-click "WebContent" / New / JSP.
○ Name your JSP - to be consistent with the example, name it "Home.jsp"
place the JSP the following code:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title> My first JSP </title>
</head>
<body>
<form action="HelloServlet">
Please enter a color <br>
<input type="text" name="color"size="20px">
<input type="submit" value="submit">

</form>
</body>
</html>

3. Create the Servlet

○ In the "Project Explorer" view, R-click "Java Resources: src" / New / Class
○ Name your class - to be consistent with the example, name it "HelloWorld"
place the following code in the class:
import java.io.IOException;
import javax.servlet.ServletException;
Notes Prepared By : Sarvagya Jain
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;

public class HelloWorld extends HttpServlet {

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
// reading the user input
String color= request.getParameter("color");
PrintWriter out = response.getWriter();
out.println (
"<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\"
\"http://www.w3.org/TR/html4/loose.dtd\">\n" +
"<html> \n" +
"<head> \n" +
"<meta http-equiv=\"Content-Type\" content=\"text/html;
charset=ISO-8859-1\"> \n" +
"<title> My first jsp </title> \n" +
"</head> \n" +
"<body> \n" +
"<font size=\"12px\" color=\"" + color + "\">" +
"Hello World" +
"</font> \n" +
"</body> \n" +
"</html>"
);
}
}
4. Define your servlet in "web.xml"
○ Open web.xml from the "Project Explorer" view, WebContent / Web-INF /
R-click web.xml / Open With / Text Editor
Replace its content by the following code:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<servlet>
<servlet-name>Hello</servlet-name>
<servlet-class>HelloWorld</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Hello</servlet-name>
<url-pattern>/HelloServlet</url-pattern>
</servlet-mapping>
</web-app>
○
5. Add your project to Tomcat
○ R-click the Tomcat server record / Add and Remove Projects; add your project
Notes Prepared By : Sarvagya Jain
○ Open the "Servers" view by clicking the "Servers" tab at the bottom of eclipse
window. If the "Servers" tab is not shown, you can show it from the menu bar,
Window / Show View/ Servers. Or Window / Show View / Other… / Server /
Servers.
○ In the "Servers" view, R-click Tomcat-server record / Add and Remove
Projects (If Tomcat-server record is not there, please check Steps 5-6 in the
Configurations section by clicking next from here)
○ Add your project

6. Start "Tomcat": In the "Servers" view, R-click Tomcat-server record / Start

7. Test your project:
○ In your web browser (Internet Explorer or Firefox) :
■ If the port is set to 80: Type http://localhost/YourProjectName - In
our example the URL is http://localhost/ServletExample
■ If the port is set to 8080: Type
http://localhost:8080/YourProjectName - In our example the URL
is http://localhost:8080/ServletExample
○ Please note that Tomcat's default port is 8080, but the version refer to in
the Downloads section (the pre-configured version), has its port set to 80.
We will proceed in this tutorial assuming that the port is set to 80. (You
can check your version's port from Tomcat-Installation-Directory / conf /
server.xml)
○ Click your JSP file name shown in the directory listing - in our example it
is Home.jsp

○ This should be the result

Enterprise Java beans:

Notes Prepared By : Sarvagya Jain
The EJB stands for Enterprise Java beans that is a server-based architecture that follows the
specifications and requirements of the enterprise environment. EJB is conceptually based on
the Java RMI(Remote Method Invocation) specification. In EJB, the beans are run in a
container having four-tier architecture. This architecture consists of four layers, i.e., Client
layer, Web layer, Application layer, and Data layer.
Architecture
The EJB architecture has two main layers, i.e., Application Server and EJB Container, based
on which the EJB architecture exist. The graphical representation of the EJB architecture is
given below.

In the above diagram, the logical representation of how EJBs are invoked and deployed by
using RMI(Remote Method Invocation) is defined. The containers of the EJB cannot be
self-deployed. In order to deploy the containers, it requires the Application server.
Application Server
In the EJB architecture, the Application server is the outermost layer that holds or contains
the Container to be deployed. The application layer plays an important role in executing the
application developed using the beans. It provides the necessary environment to execute those
applications. Some most popular application servers are Web-logic, Tomcat, JBoss,
Web-sphere, Wildfly, and Glass-finish. The main tasks of the application server are:
1. Manage Interfaces
2. Execution of the processes
3. Connecting to the database
4. Manage other resources.
Container
In EJB architecture, the Container is the second outermost layer. It is a very important layer
for enterprise beans that are contained in it. For the enterprise bean, the Container provides
various supporting services, which are as follows:
● It provides support for transactional services such as registering the objects, assign
remote interfaces, purge the instances.
● It provides support for monitoring the object's activities and coordinating distributed
components.
● It provides support for security services.
● It provides support for the pooling of resources.
● It provides support for managing the Life-cycle of beans and their concurrency.
Notes Prepared By : Sarvagya Jain
● It provides support to concentrate on business logic.
Beans:
Java beans of the enterprise are installed in the Container in the same way as a Plain old java
object (POJO) is installed and registered to the Container. For developing secured, large scale
and robust business applications, beans provide business logic.
Middleware:
Middleware is software that bridges gaps between other applications, tools, and databases in
order to provide unified services to users.
It enables one or more kinds of communication or connectivity between two or more
applications or application components in a distributed network.
types of middleware
There are 14 specific types of middleware software that can be used to solve various
problems for either enterprise or platform purposes, including:
1. Application Programming Interface (API): A toolset for building applications such as
an API for developing mobile apps on a particular operating system.
2. Application Server: A software framework used to create and run enterprise
applications.
3. Application Integration: Enterprise application integration is an integration framework
composed of a collection of technologies and services which form a middleware or
“middleware framework” to enable integration of systems and applications across an
enterprise.
4. Content-Centric Middleware: Similar to publish/subscribe middleware,
content-centric middleware utilizes provider-consumer abstraction to obtain specific
content.
5. Data Integration: Tools for data integration, such as an enterprise service bus.
6. Device Middleware: A toolset for developing hardware environment-specific
applications.
7. Embedded Middleware: Serving as an intermediary, embedded middleware enables
communication between and an integration interface for embedded applications,
operating systems, and applications.
8. Games Engines: A framework that enables graphics, physics, scripting, or networking.
9. Message-Oriented Middleware (MOM): Infrastructure that supports the transaction of
messages between distributed systems or elements.
10. Object Request Broker (ORB): Object middleware enables the sending of objects and
request services by way of an object oriented system
11. Portals: In reference to enterprise portal servers, this piece of software facilitates
front-end integration as well as interactions between a device and its back-end system.
12. Remote Procedure Call (RPC): A Remote Procedure Call is used synchronously or
asynchronously to call on services from remote systems.
13. Robotic Middleware: Robotic middleware is used to manage the complexity involved
when building a robot, such as robot control and simulation.
14. Transaction Processing (TP): Transcation processing middleware is used in
transaction processing monitors to provide an environment for developing and
deploying disparate applications.
JDBC:
JDBC stands for Java Database Connectivity. JDBC is a Java API to connect and execute the
query with the database. It is a part of JavaSE (Java Standard Edition). JDBC API uses JDBC
drivers to connect with the database. There are four types of JDBC drivers:
JDBC-ODBC Bridge Driver: The JDBC-ODBC bridge driver uses ODBC driver to connect
to the database. The JDBC-ODBC bridge driver converts JDBC method calls into the ODBC
function calls.
Notes Prepared By : Sarvagya Jain
Native Driver:The Native API driver uses the client-side libraries of the database. The driver
converts JDBC method calls into native calls of the database API.
Network Protocol Driver:The Network Protocol driver uses middleware (application server)
that converts JDBC calls directly or indirectly into the vendor-specific database protocol. It is
fully written in java.
Thin Driver:The thin driver converts JDBC calls directly into the vendor-specific database
protocol. That is why it is known as thin driver. It is fully written in Java language.
We can use JDBC API to access tabular data stored in any relational database. By the help of
JDBC API, we can save, update, delete and fetch data from the database. It is like Open
Database Connectivity (ODBC) provided by Microsoft.

JDBC (Java Database Connectivity)

5 Steps to connect to the database in java
1. Register the driver class
2. Create the connection object
3. Create the Statement object
4. Execute the query
5. Close the connection object
Java Database Connectivity Steps
1) Register the driver class
The forName() method of Class class is used to register the driver class. This method is used
to dynamically load the driver class.
Syntax of forName() method
public static void forName(String className)throws ClassNotFoundException
Example to register the OracleDriver class
Here, Java program is loading oracle driver to esteblish database connection.
Class.forName("oracle.jdbc.driver.OracleDriver");
2) Create the connection object
The getConnection() method of DriverManager class is used to establish connection with the
database.
Syntax of getConnection() method
1) public static Connection getConnection(String url)throws SQLException
2) public static Connection getConnection(String url,String name,String password)
throws SQLException
Example to establish connection with the Oracle database
Connection con=DriverManager.getConnection(
"jdbc:oracle:thin:@localhost:1521:xe","system","password");
3) Create the Statement object
The createStatement() method of Connection interface is used to create statements. The object
of the statement is responsible to execute queries with the database.
Syntax of createStatement() method
public Statement createStatement()throws SQLException
Example to create the statement object
Statement stmt=con.createStatement();
4) Execute the query
The executeQuery() method of Statement interface is used to execute queries to the database.
This method returns the object of ResultSet that can be used to get all the records of a table.
Syntax of executeQuery() method
public ResultSet executeQuery(String sql)throws SQLException
Example to execute query
ResultSet rs=stmt.executeQuery("select * from emp");
while(rs.next()){
Notes Prepared By : Sarvagya Jain
System.out.println(rs.getInt(1)+" "+rs.getString(2));
}
5) Close the connection object
By closing connection object statement and ResultSet will be closed automatically. The
close() method of Connection interface is used to close the connection.
Syntax of close() method
public void close()throws SQLException
Example to close connection
con.close();
Example to Connect Java Application with Oracle database
import java.sql.*;
class OracleCon{
public static void main(String args[]){
try{
//step1 load the driver class
Class.forName("oracle.jdbc.driver.OracleDriver");
//step2 create the connection object
Connection con=DriverManager.getConnection(
"jdbc:oracle:thin:@localhost:1521:xe","system","oracle");
//step3 create the statement object
Statement stmt=con.createStatement();
//step4 execute query
ResultSet rs=stmt.executeQuery("select * from emp");
while(rs.next())
System.out.println(rs.getInt(1)+" "+rs.getString(2)+" "+rs.getString(3));
//step5 close the connection object
con.close();
}catch(Exception e){ System.out.println(e);}
}
}
JNDI:
The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that
allows Java software clients to discover and look up data and resources (in the form of Java
objects) via a name. Like all Java APIs that interface with host systems, JNDI is independent
of the underlying implementation.
The information looked up via JNDI may be supplied by a server, a flat file, or a database; the
choice is up to the implementation used.
Typical uses of JNDI include:
● connecting a Java application to an external directory service (such as an address
database or an LDAP server)
● allowing a Java Servlet to look up configuration information provided by the
hosting web container
The Java RMI and Java EE APIs use the JNDI API to look up objects in a network.[3]
The API provides:
● a mechanism to bind an object to a name
● a directory-lookup interface that allows general queries
● an event interface that allows clients to determine when directory entries have
been modified
● LDAP extensions to support the additional capabilities of an LDAP service

To use the JNDI, you must

have the JNDI classes and
Notes Prepared By : Sarvagya Jain
one or more service providers. The Java 2 SDK, v1.3 includes three service providers for the
following naming/directory services:
1. Lightweight Directory Access Protocol (LDAP)
2. Common Object Request Broker Architecture (CORBA) Common Object
Services (COS) name service

3. Java Remote Method Invocation (RMI) Registry

So basically you create objects and register them on the directory services which you can later
do lookup and execute operations on.
JMS:
(Java Message Service) is an API that provides the facility to create, send and read messages.
It provides loosely coupled, reliable and asynchronous communication.
JMS is also known as a messaging service. Messaging is a technique to communicate
applications or software components.
JMS is mainly used to send and receive message from one application to another.
Generally, user sends a message to application. But, if we want to send message from one
application to another, we need to use JMS API.
Consider a scenario, one application A is running in INDIA and another application B is
running in USA. To send message from A application to B, we need to use JMS.
JMS Programming Model

JMS Queue Example

To develop a JMS queue example, you need to install any application server. Here, we are
using glassfish3 server where we are creating two JNDI.
1. Create connection factory named myQueueConnectionFactory
2. Create destination resource named myQueue
After creating JNDI, create server and receiver application. You need to run server and
receiver in different console. Here, we are using eclipse IDE, it is opened in different console
by default.
1) Create connection factory and destination resource
Open server admin console by the URL http://localhost:4848
Login with the username and password.
Click on the JMS Resource -> Connection Factories -> New, now write the pool name and
select the Resource Type as QueueConnectionFactory then click on ok button.
Notes Prepared By : Sarvagya Jain

Click on the JMS Resource -> Destination Resources -> New, now write the JNDI name and
physical destination name then click on ok button.

2) Create sender and receiver application

Let's see the Sender and Receiver code. Note that Receiver is attached with listener which
will be invoked when user sends message.
Notes Prepared By : Sarvagya Jain
File: MySender.java
import java.io.BufferedReader;
import java.io.InputStreamReader;
import javax.naming.*;
import javax.jms.*;
public class MySender {
public static void main(String[] args) {
try
{ //Create and start connection
InitialContext ctx=new InitialContext();
QueueConnectionFactory
f=(QueueConnectionFactory)ctx.lookup("myQueueConnectionFactory");
QueueConnection con=f.createQueueConnection();
con.start();
//2) create queue session
QueueSession ses=con.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
//3) get the Queue object
Queue t=(Queue)ctx.lookup("myQueue");
//4)create QueueSender object
QueueSender sender=ses.createSender(t);
//5) create TextMessage object
TextMessage msg=ses.createTextMessage();
//6) write message
BufferedReader b=new BufferedReader(new InputStreamReader(System.in));
while(true)
{
System.out.println("Enter Msg, end to terminate:");
String s=b.readLine();
if (s.equals("end"))
break;
msg.setText(s);
//7) send message
sender.send(msg);
System.out.println("Message successfully sent.");
}
//8) connection close
con.close();
}catch(Exception e){System.out.println(e);}
}
}
File: MyReceiver.java
import javax.jms.*;
import javax.naming.InitialContext;

public class MyReceiver {

public static void main(String[] args) {
try{
//1) Create and start connection
InitialContext ctx=new InitialContext();
QueueConnectionFactory
f=(QueueConnectionFactory)ctx.lookup("myQueueConnectionFactory");
Notes Prepared By : Sarvagya Jain
QueueConnection con=f.createQueueConnection();
con.start();
//2) create Queue session
QueueSession ses=con.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
//3) get the Queue object
Queue t=(Queue)ctx.lookup("myQueue");
//4)create QueueReceiver
QueueReceiver receiver=ses.createReceiver(t);

//5) create listener object

MyListener listener=new MyListener();

//6) register the listener object with receiver

receiver.setMessageListener(listener);

System.out.println("Receiver1 is ready, waiting for messages...");

System.out.println("press Ctrl+c to shutdown...");
while(true){
Thread.sleep(1000);
}
}catch(Exception e){System.out.println(e);}
}

}
File: MyListener.java
import javax.jms.*;
public class MyListener implements MessageListener {

public void onMessage(Message m) {

try{
TextMessage msg=(TextMessage)m;

System.out.println("following message is received:"+msg.getText());

}catch(JMSException e){System.out.println(e);}
}
}
Run the Receiver class first then Sender class.
Remote Method Invocation
RMI stands for Remote Method Invocation. It is a mechanism that allows an object residing
in one system (JVM) to access/invoke an object running on another JVM.
RMI is used to build distributed applications; it provides remote communication between
Java programs. It is provided in the package java.rmi.
Architecture of an RMI Application
In an RMI application, we write two programs, a server program (resides on the server) and
a client program (resides on the client).
● Inside the server program, a remote object is created and reference of that object is
made available for the client (using the registry).
● The client program requests the remote objects on the server and tries to invoke its
methods.
The following diagram shows the architecture of an RMI application.
Notes Prepared By : Sarvagya Jain

Let us now discuss the components of this architecture.

● Transport Layer − This layer connects the client and the server. It manages the
existing connection and also sets up new connections.
● Stub − A stub is a representation (proxy) of the remote object at client. It resides in the
client system; it acts as a gateway for the client program.
● Skeleton − This is the object which resides on the server side. stub communicates with
this skeleton to pass request to the remote object.
● RRL(Remote Reference Layer) − It is the layer which manages the references made
by the client to the remote object.
Working of an RMI Application
The following points summarize how an RMI application works −
● When the client makes a call to the remote object, it is received by the stub which
eventually passes this request to the RRL.
● When the client-side RRL receives the request, it invokes a method called invoke() of
the object remoteRef. It passes the request to the RRL on the server side.
● The RRL on the server side passes the request to the Skeleton (proxy on the server)
which finally invokes the required object on the server.
● The result is passed all the way back to the client.
Java RMI Example
The is given the 6 steps to write the RMI program.
1. Create the remote interface
2. Provide the implementation of the remote interface
3. Compile the implementation class and create the stub and skeleton objects using the
rmic tool
4. Start the registry service by rmiregistry tool
5. Create and start the remote application
6. Create and start the client application

RMI Example
In this example, we have followed all the 6 steps to create and run the rmi application. The
client application need only two files, remote interface and client application. In the rmi
Notes Prepared By : Sarvagya Jain
application, both client and server interacts with the remote interface. The client application
invokes methods on the proxy object, RMI sends the request to the remote JVM. The return
value is sent back to the proxy
object and then to the client
application.

1) create the remote interface

For creating the remote
interface, extend the Remote
interface and declare the
RemoteException with all the
methods of the remote
interface. Here, we are creating
a remote interface that extends
the Remote interface. There is
only one method named add()
and it declares
RemoteException.
1. import java.rmi.*;
2. public interface Adder extends Remote{
3. public int add(int x,int y)throws RemoteException;
4. }

2) Provide the implementation of the remote interface

Now provide the implementation of the remote interface. For providing the implementation of
the Remote interface, we need to
● Either extend the UnicastRemoteObject class,
● or use the exportObject() method of the UnicastRemoteObject class
In case you extend the UnicastRemoteObject class, you must define a constructor that
declares RemoteException.
1. import java.rmi.*;
2. import java.rmi.server.*;
3. public class AdderRemote extends UnicastRemoteObject implements Adder{
4. AdderRemote()throws RemoteException{
5. super();
6. }
7. public int add(int x,int y){return x+y;}
8. }

3) create the stub and skeleton objects using the rmic tool.
Next step is to create stub and skeleton objects using the rmi compiler. The rmic tool invokes
the RMI compiler and creates stub and skeleton objects.
1. rmic AdderRemote

4) Start the registry service by the rmiregistry tool

Now start the registry service by using the rmiregistry tool. If you don't specify the port
number, it uses a default port number. In this example, we are using the port number 5000.
1. rmiregistry 5000

5) Create and run the server application

Now rmi services need to be hosted in a server process. The Naming class provides methods
to get and store the remote object. The Naming class provides 5 methods.
Notes Prepared By : Sarvagya Jain

public static java.rmi.Remote lookup(java.lang.String) throws It returns the reference of

java.rmi.NotBoundException, the remote object.
java.net.MalformedURLException,
java.rmi.RemoteException;

public static void bind(java.lang.String, java.rmi.Remote) It binds the remote object

throws java.rmi.AlreadyBoundException, with the given name.
java.net.MalformedURLException,
java.rmi.RemoteException;

public static void unbind(java.lang.String) throws It destroys the remote

java.rmi.RemoteException, java.rmi.NotBoundException, object which is bound
java.net.MalformedURLException; with the given name.

public static void rebind(java.lang.String, java.rmi.Remote) It binds the remote object

throws java.rmi.RemoteException, to the new name.
java.net.MalformedURLException;

public static java.lang.String[] list(java.lang.String) throws It returns an array of the

java.rmi.RemoteException, names of the remote
java.net.MalformedURLException; objects bound in the
registry.
In this example, we are binding the remote object by the name sonoo.
import java.rmi.*;
import java.rmi.registry.*;
public class MyServer{
public static void main(String args[]){
try{
Adder stub=new AdderRemote();
Naming.rebind("rmi://localhost:5000/sonoo",stub);
}catch(Exception e){System.out.println(e);}
}
}

6) Create and run the client application

At the client we are getting the stub object by the lookup() method of the Naming class and
invoking the method on this object. In this example, we are running the server and client
applications, in the same machine so we are using localhost. If you want to access the remote
object from another machine, change the localhost to the host name (or IP address) where the
remote object is located.
import java.rmi.*;
public class MyClient{
public static void main(String args[]){
try{
Adder stub=(Adder)Naming.lookup("rmi://localhost:5000/sonoo");
System.out.println(stub.add(34,4));
}catch(Exception e){}
}
}
CORBA:
Notes Prepared By : Sarvagya Jain
The Common Object Request Broker Architecture (CORBA) is a standard defined by the
Object Management Group (OMG) designed to facilitate the communication of systems that
are deployed on diverse platforms. CORBA enables collaboration between systems on
different operating systems, programming languages, and computing hardware. CORBA has
many of the same design goals as object-oriented programming: encapsulation and reuse.
CORBA uses an object-oriented model although the systems that utilize CORBA do not have
to be object-oriented. CORBA is an example of the distributed object paradigm.
CORBA supports at least two different server-side mappings for implementing an IDL
interface:
● The Inheritance Model
Using the Inheritance Model, you implement the IDL interface using an implementation
class that also extends the compiler-generated skeleton.
Inheritance models include:
○ The OMG-standard, POA. Given an interface My defined in My.idl, the file MyPOA.java
is generated by the idlj compiler. You must provide the implementation for My and it
must inherit from MyPOA, a stream-based skeleton that extends
org.omg.PortableServer.Servant , which serves as the base class for all POA servant
implementations.
○ ImplBase. Given an interface My defined in My.idl, the file _MyImplBase.java is
generated. You must provide the implementation for My and it must inherit from
_MyImplBase.
● The Delegation Model
Using the Delegation Model, you implement the IDL interface using two classes:
○ An IDL-generated Tie class that inherits from the compiler-generated skeleton, but
delegates all calls to an implementation class.
○ A class that implements the IDL-generated operations interface (such as
HelloOperations), which defines the IDL function.
● The Delegation model is also known as the Tie model, or the Tie Delegation model. It
inherits from either the POA or ImplBase compiler-generated skeleton, so the models
will be described as POA/Tie or ImplBase/Tie models
Defining the Interface (Hello.idl)
Hello.idl
module HelloApp
{
interface Hello
{
string sayHello();
oneway void shutdown();
};
};
Implementing the Server (HelloServer.java)
HelloServer.java
// HelloServer.java
// Copyright and License
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
import java.util.Properties;
class HelloImpl extends HelloPOA {
Notes Prepared By : Sarvagya Jain
private ORB orb;
public void setORB(ORB orb_val) {
orb = orb_val;
}

// implement sayHello() method

public String sayHello() {
return "\nHello world !!\n";
}

// implement shutdown() method

public void shutdown() {
orb.shutdown(false);
}
}
public class HelloServer {
public static void main(String args[]) {
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get reference to rootpoa & activate the POAManager
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
HelloImpl helloImpl = new HelloImpl();
helloImpl.setORB(orb);
// get object reference from the servant
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloImpl);
Hello href = HelloHelper.narrow(ref);
// get the root naming context
// NameService invokes the name service
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
// Use NamingContextExt which is part of the Interoperable
// Naming Service (INS) specification.
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
// bind the Object Reference in Naming
String name = "Hello";
NameComponent path[] = ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println("HelloServer ready and waiting ...");
// wait for invocations from clients
orb.run();
}

catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}

System.out.println("HelloServer Exiting ...");

Notes Prepared By : Sarvagya Jain
}
}
Implementing the Client Application (HelloClient.java)
HelloClient.java
// Copyright and License
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class HelloClient
{
static Hello helloImpl;
public static void main(String args[])
{
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
// Use NamingContextExt instead of NamingContext. This is
// part of the Interoperable naming Service.
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
// resolve the Object Reference in Naming
String name = "Hello";
helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));
System.out.println("Obtained a handle on server object: " + helloImpl);
System.out.println(helloImpl.sayHello());
helloImpl.shutdown();
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
}
}
Building and Running Hello World
To run this client-server application on your development machine:
1. Change to the directory that contains the file Hello.idl.
2. Run the IDL-to-Java compiler, idlj, on the IDL file to create stubs and skeletons.
This step assumes that you have included the path to the java/bin directory in your
path.
idlj -fall Hello.idl
use the -fall option with the idlj compiler to generate both client and server-side bindings.
3. Compile the .java files, including the stubs and skeletons (which are in the
directory HelloApp). This step assumes the java/bin directory is included in your
path.
javac *.java HelloApp/*.java
4. Start orbd
From an MS-DOS system prompt (Windows), enter:
start orbd -ORBInitialPort 1050
5. Start the Hello server
From an MS-DOS system prompt (Windows), enter:
Notes Prepared By : Sarvagya Jain
start java HelloServer -ORBInitialPort 1050 -ORBInitialHost localhost
6. Run the client application:
java HelloClient -ORBInitialPort 1050 -ORBInitialHost localhost
Roll of UML in Software Architecture:
UML. UML stands for Unified Modeling Language. It is a pictorial language used to
make software blueprints. … UML can be described as a general purpose visual
modeling language to visualize, specify, construct, and document a software system.
It is used in software development to represent the architecture of the system and how
the different components are interconnected (not how they behave or communicate,
simply where they stand). Below you can see an example of a sequence diagram,
depicting a course registration system.
UML diagrams can be used as a way to visualize a project before it takes place or as
documentation for a project afterward. But the overall goal of UML diagrams is to
allow teams to visualize how a project is or will be working, and they can be used in
any field, not just software engineering.
A system architecture is the conceptual model that defines the structure, behavior, and
more views of a system. An architecture description is a formal description and
representation of a system, organized in a way that supports reasoning about the
structures and behaviors of the system.
Notes Prepared By : Sarvagya Jain
Unit 4
Software Architecture Analysis:
Architectural analysis is the activity of discovering important system properties using the system’s architectural
model. The analysis of architectural models can have varying goals like early estimation of system size,
complexity and cost. It can include satisfaction of system requirements-both functional and non-functional,
evaluation of opportunities for reusing existing functionalities etc.
The goals of architectural analysis are categorized into four groups and referred to as 4 c’s.
1. Completeness
2. Consistency
3. Compatibility
4. Correctness
Completeness is an external and internal analysis goal. It is external with respect to system requirements. The
main goal of assessing architecture’s completeness is to establish whether it adequately captures all of the
system’s key functional and nonfunctional requirements. Analyzing architecture for internal completeness
establishes whether all of the system’s elements have been fully captured with respect to modeling notation and
the system undergoing architectural design. Establishing the completeness of the model with respect to the
modeling notation ensures that the model includes all the information demanded by the notation’s syntactic and
semantic rules. Establishing the completeness of the model with respect to the system being designed requires
checking whether there are missing components and connectors in the architecture, whether the specified
components’ and connectors’ interfaces and protocols of interaction are fully specified, whether all of the
dependencies and interaction paths are captured by the systems’ architectural configurations.
Consistency is an internal property of an architectural model which is intended to ensure that different elements
of that model do not contradict one another. Some of the inconsistencies in a model include:
● Name inconsistencies: it occurs at the level of components and connectors or their constituent elements
such as names of services exported by a component.
● Interface inconsistencies: it includes naming inconsistency and other forms of inconsistencies. A
component's service name might be the same as another component but their parameter list may differ.
● Behavioral inconsistencies: it occurs between components that request and provide services whose
names and interfaces match but behaviors don’t.
● Interaction inconsistencies: it occurs when a component’s provided operations are accessed in a manner
that violates certain interaction constraints.
● Refinement inconsistencies: it stems from the fact that a system’s architecture is frequently captured at
multiple levels of abstraction.
Compatibility is an external property of the architectural model, intended to ensure that the model adheres to
the design guidelines and constraints imposed by an architectural style, reference architecture or an architectural
standard. If architecture must be compatible with a set of semi- formally or informally specified design
guidelines, analyzing the architecture for compatibility may be more challenging and the outcome of the
analysis process may also be ambiguous.
Correctness is an external property of an architectural model. A systems’ architecture is said to be correct if the
architectural design decisions fully realize those specifications. The system's implementation is correct if the
implementation fully captures and realizes all the principal design decisions comprising the architecture.
Software Architecture Design:
Software design is the process of conceptualizing the software requirements into software implementation. This
is the initial phase within the software development life cycle (SDLC)—shifting the concentration from the
problem to the solution.
When conceptualizing the software, the design process establishes a plan that takes the user requirements as
challenges and works to identify optimum solutions. The plan should determine the best possible design for
implementing the intended solution.
Software design includes all activities that aid in the transformation from requirement specification to
implementation. Major artifacts of the software design process include:
● Software requirements specification. This document describes the expected behavior of the system in
the form of functional and non-functional requirements. These requirements should be clear, actionable,
Notes Prepared By : Sarvagya Jain
measurable, and traceable to business requirements. Requirements should also define how the software
should interact with humans, hardware, and other systems.
● High-level design. The high-level design breaks the system’s architectural design into a less-abstracted
view of subsystems and modules and depicts their interaction with each other. This high-level design
perspective focuses on how the system, along with all its components, implements in the form of
modules. It recognizes the modular structure of each sub-system and their interaction among one
another.
● Detailed design. Detailed design involves the implementation of what is visible as a system and its
sub-systems in a high-level design. This activity is more detailed towards modules and their
implementations. It defines a logical structure of each module and their interfaces to communicate with
other modules.
Requirement for Architecture:
The purpose of a requirements for architecture is to structure and organize requirements in such a way that the
requirements are stable, usable, adapt to changes, and are elegant (more on why this is important later). When a
requirements architecture is sound, it helps facilitate better design of the system it attempts to describe. When a
requirements architecture is faulty, it can cause problems. When the requirements architecture is poor, the
following problems result:
● No one knows why a requirement was changed
● Requirements cannot be reused
● Traceability is superficial or unused by other teams
● Requirements reviews involve irrelevant information
● Big picture of the system being built and reasons for building it are not well-understood
● It is important to keep in mind that the purpose of a good requirements architecture is to build working
software that meets business objectives.
It is important to keep in mind that the purpose of a good requirements architecture is to build working software
that meets business objectives.
Attributes of a Good Requirements Architecture
Just as software requirements must be testable, unambiguous, and concise, a requirements architecture must
also possess certain attributes. The above blueprint provides some general guidelines for how to structure
requirements, but keeping in mind the following attributes:
● Maintainable: Whatever choices you make in organizing requirements, ensure that you create a structure
that can adapt to changes in requirements.
● Traceable: Do you know which requirements any given process flow step is traced to?
● Usable: Consider the stakeholders in the org chart—are the requirements architectured in such a way
that you could either produce output for each of them or such that they could navigate to the
requirements in the tool and find the requirements objects that are relevant to them? The hierarchies and
traces you create should be consistent: Don’t create one hierarchy where the FRs are children of the
models and another hierarchy for the same project where FRs are not children of the models but are
traced to them. The absolute worst thing to do is to list all requirements objects in a flat list or to manage
your requirements in word or excel.
● Scalable: Imagine your requirements architecture with 10 times the number of requirements it has. Now
imagine it with 100 times the number of requirements. Architects should be able to support the addition
of new requirements with minimal overhead.
● Elegant: Are there just enough hierarchies to facilitate use? Are you repeating hierarchies just to make
traceability easier? Does your architecture contain duplicate models or requirements?
● Generalizable: The architecture approach should be repeatable. You ought to be able to go into any
project and no matter the domain use the same approach to requirements architecture.
A Life-Cycle View of Architecture Analysis and Design Methods:
Any organization that embraces architecture as a foundation for its software development processes needs to
understand its place in the life cycle. Several life-cycle models exist in the literature, but one that puts
architecture squarely in the middle of things is the Evolutionary Delivery Life Cycle model shown in Figure.
The intent of this model is to get user and customer feedback and iterate through several releases before the
Notes Prepared By : Sarvagya Jain
final release. The model also allows the adding of functionality with each iteration and the delivery of a limited
version once a sufficient set of features has been developed. (For more about this life-cycle model, see For
Further Reading.)
Figure Evolutionary Delivery Life Cycle

The life-cycle model shows the design of the architecture as iterating with preliminary requirements analysis.
Clearly, you cannot begin the design until you have some idea of the system requirements. On the other hand, it
does not take many requirements in order for design to begin.
An architecture is "shaped" by some collection of functional, quality, and business requirements. We call these
shaping requirements architectural drivers and we see examples of them in our case studies. The architecture of
the A-7E is shaped by its modifiability and performance requirements. The architecture for the air traffic control
system is shaped by its availability requirements. In the flight simulator software, we will see an architecture
shaped by performance and modifiability requirements. And so on.
To determine the architectural drivers, identify the highest priority business goals. There should be relatively
few of these. Turn these business goals into quality scenarios or use cases. From this list, choose the ones that
will have the most impact on the architecture. These are the architectural drivers, and there should be fewer than
ten. The Architecture Tradeoff Analysis Method uses a utility tree to help turn the business drivers into quality
scenarios.
Once the architectural drivers are known, the architectural design can begin. The requirements analysis process
will then be influenced by the questions generated during architectural design-one of the reverse-direction
arrows
Economics Based Architecture Analysis:
Cost-Benefit Analysis Method:
A cost-benefit analysis is a systematic process that businesses use to analyze which decisions to make and
which to forgo. The cost-benefit analyst sums the potential rewards expected from a situation or action and then
subtracts the total costs associated with taking that action. Some consultants or analysts also build models to
assign a dollar value on intangible items, such as the benefits and costs associated with living in a certain town.
● A cost-benefit analysis (CBA) is the process used to measure the benefits of a decision or taking action
minus the costs associated with taking that action.
Notes Prepared By : Sarvagya Jain
● A CBA involves measurable financial metrics such as revenue earned or costs saved as a result of the
decision to pursue a project.
● A CBA can also include intangible benefits and costs or effects from a decision such as employees
morale and customer satisfaction.
Understanding Cost-Benefit Analysis (CBA)
Before building a new plant or taking on a new project, prudent managers conduct a cost-benefit analysis to
evaluate all the potential costs and revenues that a company might generate from the project. The outcome of
the analysis will determine whether the project is financially feasible or if the company should pursue another
project.
In many models, a cost-benefit analysis will also factor the opportunity cost into the decision-making process.
Opportunity costs are alternative benefits that could have been realized when choosing one alternative over
another. In other words, the opportunity cost is the forgone or missed opportunity as a result of a choice or
decision. Factoring in opportunity costs allows project managers to weigh the benefits from alternative courses
of action and not merely the current path or choice being considered in the cost-benefit analysis.
By considering all options and the potential missed opportunities, the cost-benefit analysis is more thorough and
allows for better decision-making.
The Cost-Benefit Analysis Process
A cost-benefit analysis should begin with compiling a comprehensive list of all the costs and benefits associated
with the project or decision.
The costs involved in a CBA might include the following:
● Direct costs would be direct labor involved in manufacturing, inventory, raw materials, manufacturing
expenses.
● Indirect costs might include electricity, overhead costs from management, rent, utilities.
● Intangible costs of a decision, such as the impact on customers, employees, or delivery times.
● Opportunity costs such as alternative investments, or buying a plant versus building one.
● Cost of potential risks such as regulatory risks, competition, and environmental impacts.

Tools or Methods Used in CBA

Depending on the specific investment or project being evaluated, one may need to discount the time value of
cash flows using net present value calculations. A benefit-cost ratio (BCR) may also be computed to summarize
the overall relationship between the relative costs and benefits of a proposed project. Other tools may include
regression modeling, valuation, and forecasting techniques.
Notes Prepared By : Sarvagya Jain
Architecture Tradeoff Analysis Method (ATAM)
Architecture Tradeoff Analysis :
This Method is a method used to evaluate the quality attributes(such as performance, availability, and security)
of software architectures. ATAM is used to mitigate risks in software architectures in the early stages of the
software development life cycle (SDLC).
Participants in ATAM :
The ATAM requires the participation of three groups as follows.
The evaluation team –
The evaluation team consists of the members who are external to the project. This team consists of 3-5
members who play their specific roles in the team.
1. Project decision-makers –
Project decision-makers have the power to speak for the development of the project and have the
authority to mandate changes.
2. Architecture stakeholders –
Any individual, team, or organization who has an interest in the realization of the architecture and is
somehow related to the architecture is a stakeholder of that architecture. Stakeholders include users,
maintainers, performance engineers, testers, integrators, developers.
Process of Architecture Tradeoff Analysis Method :
The ATAM process starts with bringing all the stakeholders to find business drivers like system goals,
constraints, system functionality, and desired non-functional properties. Then from these drivers quality
attributes and business scenarios are created. Then, in conjunction with architectural approaches and
architectural designs, these scenarios are used to create an analysis of trade-offs, sensitivity points, and risks (or
non-risks).
This analysis is then converted to the risk themes and their impacts from where the process can be repeated.
With every analysis cycle, the process gradually proceeds from the more general to the more specific. The
whole architecture will be fine-tuned and risk themes will be addressed by examining the questions that were
discovered in the previous cycle.

ATAM Process
Steps of ATAM Process :
There are nine steps in the ATAM process as follows.
1. Present ATAM –
Present the concept of the process to all the stakeholders of the process and answer the questions asked
by the participants. This step makes the participants familiar with the process.
Notes Prepared By : Sarvagya Jain
2. Present Business Drivers –
All the participants involved in the presentation are expected to present, understand, and evaluate the
business drivers for the system.
3. Present Architecture –
A brief overview of the architecture is presented by the architect with an appropriate level of detail, i.e.
at least modules and C&C views are discussed.
4. Identify Architectural Approaches –
The architect presents some specific architectural approaches to the team and then the proposed
architecture is discussed.
5. Generate Quality Attribute Utility Tree –
In this step, the core business and technical requirements of the system are defined and then mapped into
an appropriate architectural property. Put all these parts of evaluations, designs, and requirement
elicitation into a tree.
6. Analyze architectural approaches –
Each and every scenario is compared and rated by priority, and then highly rated scenario is mapped
onto the architecture.
7. Brainstorm Scenarios –
The larger stakeholders group present and contribute current scenarios and their concerns.
8. Analyze architectural approaches –
Step 6 is repeated again with added knowledge from larger stakeholders in step.
9. Present results –
At the end of the evaluation, the team reviews the existing and newly discovered risks, non-risks,
sensitivities, and tradeoffs. The team discusses whether any new risk themes have arisen. Then the team
provides all the documentation to the stakeholders.
Phases of ATAM :
The ATAM consists of four phases as follows.
1. Phase 0 –
Preparation, planning, stakeholder recruitment, and team formation takes place in this phase.
Participants are evaluation team key project decision-makers.
2. Phase 1 –
This phase consists of steps 1-6 of the evaluation process. Participants are evaluation team key project
decision-makers. Its typical duration is 1 day followed by a hiatus of 2 to 3 weeks.
3. Phase 2 –
This phase consists of steps 7-9 of the evaluation process. Participants are evaluation team key project
decision-makers and stakeholders. The duration of this phase is 2 days.
4. Phase 3 –
This phase is a follow-up phase. Report generation and delivery of the report is done in this phase. Any
scope of improvement in the process is also looked upon. Participants are the Evaluation team and
evaluation clients. Duration is 1 week.
Outputs of ATAM :
1. A concise presentation of the architecture. The architecture is presented in one hour.
2. Articulation of business goals. This helps the new participants in understanding the business goals.
3. Prioritized quality attribute requirements expressed as quality attribute scenarios.
4. A set of risks and non-risks as follows –
○ A risk is defined as an architectural decision that may lead to undesirable consequences in light
of quality attribute requirements.
○ A non-risk is an architectural decision that may lead to undesirable consequences in light of
quality attributes.
5. A set of risk themes. This set helps the evaluation team to examine all the discovered risk themes that
identify systematic weakness in the architecture, process, and team.
6. Mapping of architectural decisions to quality requirements. For each quality attribute scenario examined
during an ATAM, those architectural decisions that help to achieve it are determined and captured.
Notes Prepared By : Sarvagya Jain
Active Reviews for Intermediate Designs (ARID):
Both Active Design Reviews and ATAM are used to evaluate preliminary designs. In the active design review,
stakeholders receive detailed documentation and then complete exercise questionnaires on their own. ATAM is
used to evaluate whole architecture and not a portion of it.
Both ATAM and ADR’s have strong qualities for evaluating software architectures and designs, but still,
something was needed which could provide an early insight into design strategies. Thus, ARID was born by
combining stakeholder-centric, scenario-based, architecture evaluation method like ATAM and an ARD of
design specifications.
ARID is an easy, lightweight evaluation approach that is made by combining ADR’s and evaluation strategies
like ATAM, which focuses on suitability and does not require complete architectural documentation.
ARID Participants :
The main participants in ARID process are ARID review team (facilitator, scribe, and questioners), software
architect/lead designer, and reviewers.
1. ARID review team : It consists of three roles :
○ Facilitator –
The facilitator works with the software architect to prepare for the review meeting and facilitates
it when it takes place.
○ Scribe –
The scribe captures the issues and results in the review meeting.
○ Questioners –
One or more questioners raise issues, ask questions, and assist with creating scenarios during the
review meeting.
2. Software architect/Lead designer :
The software architect(or designer) is the spokesperson for design and is responsible for preparing and
presenting the design as well as participating in it.
3. The reviewers :
The reviewers are drawn from the community of stakeholders of the design, people who have an interest
in its adequacy and usability, and the software engineers who are expected to use the design.
ARID Steps :
An ARID process progresses across two phases that comprise of nine steps :
Notes Prepared By : Sarvagya Jain

ARID Steps
Phase-1 of ARID is carried out as a meeting between the lead designer and the review facilitator.
○ Step-1 : Identify Reviewers –
The lead designer and facilitator work together to identify the set of people who should be
present at the review.
○ Step-2 : Prepare the design presentation –
Designer prepares a brief explanation of design. Goal of this step is to present design in
sufficient detail so that a knowledgeable audience could use design. Here, during Phase One, the
designer gives a dry run of presentation to review facilitator.
○ Step-3 : Prepare seed scenarios –
Designer and review facilitator prepare a set of seed scenarios. Like seed scenarios in ATAM,
these are designed to illustrate concept of a scenario to reviewers, who have opportunity to see a
sample set.
○ Step-4 : Prepare for the review meeting –
Copies of presentation, seed scenarios, and review agenda are produced for distribution to the
reviewers during main review meeting.
4. During Phase-2, the reviewers assemble and the meeting commences.
5. Step-5 : Present ARID method –
The review facilitator spends 30 minutes explaining the steps of the ARID to the participants.
6. Step-6 : Present design –
The lead designer presents two – hour overview presentation and walks through examples. During this
time, a ground rule is that no questions concerning implementation or rationale are allowed, nor are
suggestions about alternate designs. Goal is to see if design is usable, not to find out why things are
done in a certain way, or to learn about implementation secrets behind interfaces. Questions of factual
clarification are allowed and encouraged. Facilitator enforces this rule during presentation.
During this time, the scribe captures each question, or each instance where designer indicated that sort
of resource (usually a kind of documentation) was on its way nut not yet available. Resulting list is
Notes Prepared By : Sarvagya Jain
summarized to show potential issues that the designer should address before design could be considered
complete and ready for production.
7. Step-7 : Brainstorm and prioritize scenarios –
Just as in ATAM, participants suggests scenarios for using design to solve problems they expect to face.
During brainstorming, all scenarios are given a fair chance. Then seed scenarios are also kept in the
pool. Then, scenarios getting the most votes will be used to test design for usability.
8. Step-8 : Perform review –
Considering highest voted scenario, facilitator asks reviewers to jointly craft code that uses design
services to solve problem posed by scenario. After review of considered scenarios team reach up to a
conclusion.
9. Step-9 : Present conclusion –
At the end, list of issues is recounted, participants are polled for their opinions regarding efficacy of the
review exercise.

Attribute-driven design
Attribute-driven design(also called ADD or Attribute-driven design method) is a methodology to create
software architectures that takes into account the quality attributes of the software. It was previously known as
the Architecture Based Design Method (or ABD), but due to trademark issues the name was changed to
Attribute-driven design around 2001.
ADD as an iterative method that, at each iteration, helps the architect to do the following steps:
● Choose a part of the system to design.
● Marshal all the architecturally significant requirements for the selected part. This means that you select
all quality attributes and business goals that could affect the architecture of this phase.
● Create an architecture for the selected part that meets the selected architecturally significant
requirements and test this design.
Required input
ADD can only be started successfully when the following resources are already available:
● functional requirements
● quality requirements
● constraints
Of course, we cannot wait until all these requirements are finalized since this can take a while. The ADD
process can start once a set of ASRs (architecturally significant requirements, which are the three resources
listed above) are available.
Process steps
1. Choose an element of the system to design
○ Select an element of the system that is not yet designed. In the first iteration this will be the
system itself. Later on, a choice will need to be made between several elements. This choice can
be based on personnel availability, input resources availability, risk mitigation, etc. In case you
do not have any of these limitations, it is suggested to go for a breadth-first strategy.
2. Identify the Architecturally Significant Requirements (ASR) for the chosen element
○ Identify the ASRs that are most important for this selected element. You should prioritize these
requirements to make sure that your design reflects the most important ASRs.
3. Generate a design solution for the chosen element
○ This step is the heart of ADD since the architecture will be created in this step. The architecture
you create should reflect the selected ASRs. You can do this by making use of architectural
patterns or tactics. Most of the times you will have to make a trade-off between several tactics
and ASRs.
4. Inventory remaining requirements and select the input for the next iteration
○ Take a look at the listed ASRs and see whether they are already fulfilled with the design you
have at the moment. For each ASR you will have to check whether it is satisfied, delegated to
one of the children, distributed among the children or whether it can not be satisfied. In the last
case you will need to change your architecture.
Notes Prepared By : Sarvagya Jain
5. Repeat steps 1-4 until all the ASRs have been satisfied
○ Repeat!
Output
A set of sketches of architectural views, not a full-blown detailed architecture.

Architecture Reuse:
A major goal of the software architecture discipline is to develop an environment that promotes the reuse of
components across separate software projects. One of the areas that would most benefit from this reuse is in
product families of similar software products. Many organizations are in the business of creating several closely
related products, whether it be a line of cell phones, cameras, printers, or a banking software suite, each product
will need very similar software, with only slight modifications based on the version being produced. In this
case, two aspects are needed in order to improve the production of such organizations. First, a common
architecture foundation should be shared by each of the products. Second, there should be at least some small
amount of basic code at the core of each product that can be reused without modification.
Identifying a reusable component and its functionality is important to heighten productivity of
component-based software. A component repository is required to facilitate storing and maintaining reusable
software components efficiently. We describe the component repository, which supports facilitating reuse of
software components in component-based software development. Our component repository provides
functionality for component reuse processes such as specification viewing, adapting, testing, and deploying.
Through the component repository with these functions, components can be efficiently reused in component
reuse process

Fig. Architectural Component Diagram Model

Notes Prepared By : Sarvagya Jain

Fig. Repository Component Model

Fig. The component reuse facilitating functions

Domain specific software architecture:

Domain specific software architecture comprises:
● A reference architecture, which describes a general computational framework for a significant domain
of applications.
● A component library, which contains reusable chunks of domain expertise.
● An application configuration method for selecting and configuring components within the architectural
to meet particular application requirements.
DSSAs involve a number of domain engineering activities. The regions of the problem space (domains) are
mapped into domain-specific software architectures (DSSAs) which are specialized into application-specific
architectures and then implemented.
The three key factors of DSSA are:
1. Domain: Must have a domain to constrain the problem space and focus development
2. Technology: Must have a variety of technological solutions like tools, patterns, architectures & styles,
legacy systems to bring to bear on a domain
3. Business: Business goals motivate the use of DSSE Minimizing costs: reuse assets when possible
Maximize market: develop many related applications for different kinds of end users
Notes Prepared By : Sarvagya Jain
These three factors together apply technology to domain-specific goals which is made firm by business
knowledge. The overview of the DSSA process is given below:
Notes Prepared By : Sarvagya Jain
Unit-5
Software Architecture Document
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the
significant architectural decisions which have been made on the system.
Here Software Architecture Document provides an architectural overview of the C-Registration System. The
C-Registration System is being developed to support online course registration.
This Document has been generated directly from the C-Registration Analysis & Design Model implemented
in Rose. The majority of the sections have been extracted from the Rose Model using SoDA and the
Software Architecture Document template.
Architectural Representation
This document presents the architecture as a series of views; use case view, logical view, process view and
deployment view. There is no separate implementation view described in this document. These are views on
an underlying Unified Modeling Language (UML) model developed using Rational Rose.
Use-Case View
A description of the use-case view of the software architecture. The Use Case View is an important input to
the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of
scenarios and/or use cases that represent some significant, central functionality. It also describes the set of
scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural
elements) or that stress or illustrate a specific, delicate point of the architecture.
The C-Registration use cases are:
- Login
- Register for Courses
- Maintain Student Information
- Maintain Professor Information
- Select Courses to Teach
- Submit Grades
- View Report Card
- Close Registration.
These use cases are initiated by the student, professor, or the registrar actors. In addition, interaction
with external actors; Course Catalog and Billing System occur.
Architecturally-Significant Use Cases :
1 Close Registration
Brief Description:This use case allows a Registrar to close the registration process. Course offerings that do
not have enough students are cancelled. Course offerings must have a minimum of three students in them.
The billing system is notified for each student in each course offering that is not cancelled, so the student can
be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an
actor involved within this use case.
2 Login
Brief Description:This use case describes how a user logs into the Course Registration System. The actors
starting this use case are Student, Professor, and Registrar.
3 Maintain Professor Information
Brief Description:This use case allows the registrar to maintain professor information in the registration
system. This includes adding, modifying, and deleting professors from the system. The actor of this use case
is the Registrar.
Notes Prepared By : Sarvagya Jain

Diagram Name: Architecturally Significant Use-Cases

4 Select Courses to Teach

Brief Description:This use case allows a professor to select the course offerings (date- and time- specific
courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach
in the upcoming semester. The actor starting this use case is the Professor. The Course Catalog System is an
actor within the use case.
5 Register for Courses
Brief Description:This use case allows a student to register for courses in the current semester. The student
can also modify or delete course selections if changes are made within the add/drop period at the beginning
of the semester. The Billing System is notified of all registration updates. The Course Catalog provides a list
of all the course offerings for the current semester. The main actor of this use case is the student. The Course
Catalog System is an actor within the use case.
6 View Report Card
Brief Description:This use case allows a student to view his/her report card for the previously completed
semester. The student is the actor of this use case.
7 Submit Grades
Notes Prepared By : Sarvagya Jain
Brief Description:This use case allows a professor to submit student grades for one or more classes
completed in the previous semester. The actor in this use case is the Professor.
8 Maintain Student Information
Brief Description:This use case allows the registrar to maintain student information in the registration
system. This includes adding, modifying, and deleting students from the system. The actor for this use case
is the Registrar.
Logical View
A description of the logical view of the architecture. Describes the most important classes, their organization
in service packages and subsystems, and the organization of these subsystems into layers. Also describes the
most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams
may be included to illustrate the relationships between architecturally significant classes, subsystems,
packages and layers.
The logical view of the course registration system consists of the 3 main packages: User Interface, Business
Services, and Business Objects.
The User Interface Package contains classes for each of the forms that the actors use to communicate with
the System. Boundary classes exist to support login, maintaining schedules, maintaining professor info,
selecting courses, submitting grades, maintaining student info, closing registration, and viewing report cards.
The Business Services Package contains control classes for interfacing with the billing system, controlling
student registration, and managing the student evaluation.
The Business Objects Package includes entity classes for the university artifacts (i.e. course offering,
schedule) and boundary classes for the interface with the Course Catalog System.
Architecture Overview – Package and Subsystem Layering
Notes Prepared By : Sarvagya Jain

1 Application Layer
This application layer has all the boundary classes that represent the application screens that the user sees.
This layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier.
2 Business Services layer
The Business Services process layer has all the controller classes that represent the use case managers
that drive the application behavior. This layer represents the client-to-mid-tier border. The Business
Services layer depends upon the Process Objects layer; that straddles the separation of the client from
mid-tier.
3 Middleware layer
The Middleware layer supports access to Relational DBMS and OODBMS.
4 Base Reuse
The Base Reuse package includes classes to support list functions and patterns.

Process View
A description of the process view of the architecture. Describes the tasks (processes and threads) involved in
the system's execution, their interactions and configurations. Also describes the allocation of objects and
classes to tasks.
The Process Model illustrates the course registration classes organized as executable processes. Processes
exist to support student registration, professor functions, registration closing, and access to the external
Billing System and Course Catalog System.
Processes
Notes Prepared By : Sarvagya Jain

Diagram Name: Processes

Deployment View
A description of the deployment view of the architecture Describes the various physical nodes for the most
typical platform configurations. Also describes the allocation of tasks (from the Process View) to the
physical nodes.
This section is organized by physical network configuration; each such configuration is illustrated by a
deployment diagram, followed by a mapping of processes to each processor.
Notes Prepared By : Sarvagya Jain

Diagram Name: Deployment View

Principle of Sound Documentation:

1. Write from the reader’s point of view.

This rule simply reminds us to keep the end game in mind as we produce our documentation: Make
your document serve its stakeholders and their intended uses of it. It is surprisingly easy to forget that
rule in the midst of looming deadlines, an overflowing e-mail queue, and a cell phone that won’t shut
up.
2. Avoid unnecessary repetition.
Each kind of information should be recorded in exactly one place. This makes documentation easier
to use and much easier to change as it evolves. It also avoids confusion.
It should be a goal that information never be repeated. However, at times the cost to the reader of not
repeating information in the other places where it’s needed is high. Readers don’t like to flip pages or
click hyperlinks unnecessarily.
3. Avoid ambiguity.
Ambiguity occurs when documentation can be interpreted in more than one way and at least one of
those ways is incorrect. The most dangerous kind of ambiguity is undetected ambiguity. Here, each
reader will think he or she understands the document, but unwittingly each reader will come to
different conclusions about what it is saying.
Notes Prepared By : Sarvagya Jain
4. Use a standard organization.
Establish a standard, planned organization scheme, make your documents adhere to it, and ensure that
readers know about it. A standard organization, also called a template, offers many benefits.
5. Record your rationale.
Architecture is the result of making a set of important design decisions, and architecture
documentation records the outcomes of those decisions. For the most important decisions, you should
record why you made them the way you did. You should also record the important or most likely
alternatives you rejected and state why. Later, when those decisions come under scrutiny or pressure
to change, you will find yourself revisiting the same arguments and wondering why you didn’t take
another path. Recording your rationale will save you enormous time in the long run, although it
requires discipline to record your rationale in the heat of the moment.
6. Keep documentation current,but not too current.
Documentation that is incomplete or out of date does not reflect truth, does not obey its own rules for
form and internal consistency, and is not used. Documentation that is kept current and accurate is
used. Because questions about the software can be most easily and most efficiently answered by
referring to the appropriate document. Documentation that is somehow inadequate to answer the
question needs to be fixed. Updating it and then referring the questioner to it will deliver a strong
message that the documentation is the final, authoritative source for information.
7. Review documentation.
Only the intended users of a document will be able to tell you whether it contains the right
information presented in the right way. Enlist their aid. Before a document is released, have it
reviewed by representatives of the community or communities for which it was written.
Refinement:
Refinement is a general approach of adding details to a software design. refinement is the idea that software
is developed by moving through the levels of abstraction, beginning at higher levels and, incrementally
refining the software through each level of abstraction, providing more detail at each increment. At higher
levels, the software is merely its design models; at lower levels there will be some code; at the lowest level
the software has been completely developed.
At the early steps of the refinement process the software engineer does not necessarily know how the
software will perform what it needs to do. This is determined at each successive refinement step, as the
design and the software is elaborated upon.

Refinement can be seen as the complement of abstraction. Abstraction is concerned with hiding lower levels
of detail; it moves from lower to higher levels. Refinement is the movement from higher levels of detail to
lower levels. Both concepts are necessary in developing software.

Context diagrams

The context diagram is used to establish the context and boundaries of the system to be modelled: which
things are inside and outside of the system being modelled, and what is the relationship of the system with
these external entities.
Notes Prepared By : Sarvagya Jain
A context diagram, sometimes called a level 0 data-flow diagram, is drawn in order to define and clarify the
boundaries of the software system. It identifies the flows of information between the system and external
entities. The entire software system is shown as a single process.

A possible context diagram for the Video-Rental LTD case study is shown below.

Figure. A context diagram for Video-Rental LTD

A context diagram for Video-Rental LTD

The process of establishing the analysis framework by drawing and reviewing the context diagram inevitably
involves some initial discussions with users regarding problems with the existing system and the specific
requirements for the new system. These are formally documented along with any specific system
requirements identified in previous studies.

Having agreed on the framework, the detailed investigation of the current system must be planned. This
involves identifying how each of the areas included within the scope will be investigated. This could be by
interviewing users, providing questionnaires to users or clients, studying existing system documentation and
procedures, observation and so on. Key users are identified and their specific roles in the investigation are
agreed upon.

Constructing a context diagram

In order to produce the context diagram and agree on system scope, the following must be identified:
external entities data-flows
You may find the following steps useful:

Identify data-flows by listing the major documents and information flows associated with the system,
including forms, documents, reference material, and other structured and unstructured information (emails,
telephone conversations, information from external systems, etc.).

Identify external entities by identifying sources and recipients of the data-flows, which lie outside of the
system under investigation. The actors an any use case models you have created may often be external
entities.

Draw and label a process box representing the entire system.

Draw and label the external entities around the outside of the process box.
Notes Prepared By : Sarvagya Jain
Add the data-flows between the external entities and the system box. Where documents and other packets of
information flow entirely within the system, these should be ignored from the point of view of the context
diagram – at this stage they are hidden within the process box.

This system boundary and details depicted in the context diagram should then be discussed (and updated if
necessary) in consultation with your customers until an agreement is reached.

Having defined the system boundary and scope, the areas for investigation will be determined, and
appropriate techniques for investigating each area will need to be decided.

Variability

Variability is a fundamental aspect of software. It is the ability to create system variants for different market
segments or contexts of use. Variability has been most extensively studied in software product lines , but is
also relevant in other areas, including software ecosystems and context-aware software . Virtually any
successful software eventually faces the need to exist in multiple variants.A software product line is a means
to develop a set of products in which variability is a central phenomenon captured in variability models.

Variability in software-intensive systems is usually understood as the ability of a software artifact to be

changed in order to fit different contexts, environments, or purposes. Software architecture on the other hand
determines the structure of a software system, and is described in an architecture description. This
description includes the major stakeholders of a software system and their concerns. Variability is reflected
in and facilitated through the software architecture.

Documenting the package using the seven part template:

1. Primary presentation shows the elements and the relationships among them that populate the view. The
primary presentation should contain the information you wish to convey about the system (in the
vocabulary of that view) first. It should certainly include the primary elements and relations of the view,
but under some circumstances it might not include all of them. For example, you may wish to show the
elements and relations that come into play during normal operation, but relegate error handling or
exceptional processing to the supporting documentation.
The primary presentation is usually graphical. In fact, most graphical notations make their contributions
in the form of the primary presentation and little else. If the primary presentation is graphical, it must be
accompanied by a key that explains, or that points to an explanation of, the notation or symbology used.
Sometimes the primary presentation can be tabular; tables are often a superb way to convey a large
amount of information compactly. An example of a textual primary presentation is the A-7E module
decomposition view illustrated in. A textual presentation still carries the obligation to present a terse
summary of the most important information in the view.
2. Element catalog details at least those elements and relations depicted in the primary presentation, and
perhaps others. Producing the primary presentation is often what architects concentrate on, but without
backup information that explains the picture, it is of little value.[1] For instance, if a diagram shows
elements A, B, and C, there had better be documentation that explains in sufficient detail what A, B, and
C are, and their purposes or the roles they play, rendered in the vocabulary of the view. For example, a
module decomposition view has elements that are modules, relations that are a form of "is part of," and
properties that define the responsibilities of each module. A process view has elements that are
processes, relations that define synchronization or other process-related interaction, and properties that
Notes Prepared By : Sarvagya Jain
include timing parameters.
To emphasize that it is but a sketch of the complete picture, we call a primary presentation by itself an
architectural cartoon.
In addition, if there are elements or relations relevant to the view that were omitted from the primary
presentation, the catalog is where those are introduced and explained.
The behavior and interfaces of elements are two other aspects of an element catalog; these will be
discussed shortly.
3. Context diagram shows how the system depicted in the view relates to its environment in the vocabulary
of the view. For example, in a component-and-connector view you show which component and
connectors interact with external components and connectors, via which interfaces and protocols.
4. Variability guide shows how to exercise any variation points that are a part of the architecture shown in
this view. In some architectures, decisions are left unbound until a later stage of the development
process, and yet the architecture must still be documented. An example of variability is found in
software product lines where the product line architecture is suitable for multiple particular systems. A
variability guide should include documentation about each point of variation in the architecture,
including
- the options among which a choice is to be made. In a module view, the options are the various versions
or parameterizations of modules. In a component-and-connector view, they might include constraints on
replication, scheduling, or choice of protocol. In an allocation view, they might include the conditions
under which a software element would be allocated to a particular processor.
- the binding time of the option. Some choices are made at design time, some at build time, and others at
runtime.
5. The Architectural background explains why the design reflected in the view came to be. The goal of this
section is to explain to someone why the design is as it is and to provide a convincing argument that it is
sound. An architecture background includes
- rationale, explaining why the decisions reflected in the view were made and why alternatives were
rejected.
- analysis results, which justify the design or explain what would have to change in the face of a
modification.
- assumptions reflected in the design.
6. Glossary of terms used in the views, with a brief description of each.
7. Other information. The precise contents of this section will vary according to the standard practices of
your organization. They might include management information such as authorship, configuration
control data, and change histories. Or the architect might record references to specific sections of a
requirements document to establish traceability. Strictly speaking, information such as this is not
architectural. Nevertheless, it is convenient to record it alongside the architecture, and this section is
provided for that purpose. In any case, the first part of this section must detail its specific contents.
Figure. Documenting a view packet consists of documenting seven parts: (1) the primary presentation; (2)
the element catalog; (3) a context diagram; (4) a variability guide; (5) architecture background, including
rationale, results of analysis, and assumptions made; (6) organization- or project-specific information; and
(7) pointers to the view packet's siblings, parent(s), or children. If the primary presentation is graphical, we
call it a cartoon. A cartoon must be accompanied by a key that explains the notational symbology used or
that points to the place where the notation is explained.
Notes Prepared By : Sarvagya Jain

DOCUMENTING BEHAVIOR
Views present structural information about the system. However, structural information is not sufficient to
allow reasoning about some system properties. Reasoning about deadlock, for example, depends on
understanding the sequence of interactions among the elements, and structural information alone does not
present this sequencing information. Behavior descriptions add information that reveals the ordering of
interactions among the elements, opportunities for concurrency, and time dependencies of interactions (at a
specific time or after a period of time).
Notes Prepared By : Sarvagya Jain
Behavior can be documented either about an element or about an ensemble of elements working in concert.
Exactly what to model will depend on the type of system being designed. For example, if it is a real-time
embedded system, you will need to say a lot about timing properties and the time of events. In a banking
system, the sequence of events (e.g., atomic transactions and rollback procedures) is more important than the
actual time of events being considered. Different modeling techniques and notations are used depending on
the type of analysis to be performed. In UML, sequence diagrams and statecharts are examples of behavioral
descriptions. These notations are widely used.
Statecharts are a formalism developed in the 1980s for describing reactive systems. They add a number of
useful extensions to traditional state diagrams such as nesting of state and "and" states, which provide the
expressive power to model abstraction and concurrency. Statecharts allow reasoning about the totality of the
system. All of the states are assumed to be represented and the analysis techniques are general with respect
to the system. That is, it is possible to answer a question such as Will the response time to this stimulus
always be less than 0.5 seconds?
A sequence diagram documents a sequence of stimuli exchanges. It presents a collaboration in terms of
component instances and their interactions and shows the interaction arranged in time sequence. The vertical
dimension represents time and the horizontal dimension represents different components. Sequence diagrams
allow reasoning based on a particular usage scenario. They show how the system reacts to a particular
stimulus and represent a choice of paths through the system. They make it possible to answer a question such
as What parallel activities occur when the system is responding to these specific stimuli under these specific
conditions?

DOCUMENTING INTERFACES
An interface is a boundary across which two independent entities meet and interact or communicate with
each other. Our definition of software architecture made it clear that elements' interfaces-carriers of the
properties externally visible to other elements-are architectural. Since you cannot perform analyses or system
building without them, documenting interfaces is an important part of documenting architecture.
Documenting an interface consists of naming and identifying it and documenting its syntactic and semantic
information. The first two parts constitute an interface's "signature." When an interface's resources are
invokable programs, the signature names the programs and defines their parameters. Parameters are defined
by their order, data type, and (sometimes) whether or not their value is changed by the program. A signature
is the information that you would find about the program, for instance, in an element's C or C++ header file
or in a Java interface.
Signatures are useful (for example, they can enable automatic build checking), but are only part of the story.
Signature matching will guarantee that a system will compile and/or link successfully. However, it
guarantees nothing about whether the system will operate successfully, which is after all the ultimate goal.
That information is bound up in the semantics to the interface, or what happens when resources are brought
into play.
An interface is documented with an interface specification, which is a statement of element properties the
architect chooses to make known. The architect should expose only what is needed to interact with the
interface. Put another way, the architect chooses what information is permissible and appropriate for people
to assume about the element, and what is unlikely to change. Documenting an interface is a matter of striking
a balance between disclosing too little information and disclosing too much. Too little information will
Notes Prepared By : Sarvagya Jain
prevent developers from successfully interacting with the element. Too much will make future changes to the
system more difficult and widespread and make the interface too complicated for people to understand. A
rule of thumb is to focus on how elements interact with their operational environments, not on how they are
implemented. Restrict the documentation to phenomena that are externally visible.
Elements that occur as modules often correspond directly to one or more elements in a
component-and-connector view. The module and component-and-connector elements are likely to have
similar, if not identical, interfaces and documenting them in both places would produce needless duplication.
To avoid that, the interface specification in the component-and-connector view can point to the interface
specification in the module view, and only contain the information specific to its view. Similarly, a module
may appear in more than one module view-such as the module decomposition or uses view. Again, choose
one view to hold the interface specification and refer to it in the others.