CS701 Software Architecture

15 November 2022 09:47 PM

UNIT - 1

1. Overview of Software development methodology

Software development methodology refers to a process or series of procedures used to structure,
organize and control the whole development process. It has less to do with programming and
more to do with planning for an efficient software development life cycle.
All methodologies have their strengths and weaknesses. Here, we will look at informative details
about each method, followed by their respective strong points and pitfalls.
a. Waterfall Development Methodology:
i. The workflow only goes in one direction in the Waterfall development method. That
is, the Waterfall model is rigid in its approach. And should a software project using the
Waterfall methodology require changes, the Waterfall model demands a complete
restart.
ii. It involves dividing development into phases, arranged in sequential order. The
waterfall development method functions with the following basic principles or
phases:
1. Requirements: This is the conceptualization phase, where developers define the
problem the software project is aiming to fix. They also describe the initial
software concept and expectations for the project in this stage.
2. System design: Here, developers determine the software architecture and
system core.
3. Implementation: The team splits up to develop the software in separate units.
There is also testing of each isolated section for functionality.
4. Integration and Testing: The team combines all the output of all the separate
units. And they test and fine-tune the integrated system for optimal
functionality.
5. Deployment: Software is ready for customer use.
6. Maintenance: Developers troubleshoot or get feedback from clients during use
and repair such issues as they come.
Pros Cons
waterfall approach is particularly great Since there is no client feedback in the
for newbie developers because of its initial stages, developers are more likely
linearity to stray off product requirements.
Using the waterfall model to develop Testing is at the end of the software
iii. software saves time since all phases are development process, so it would be
clearly defined. harder to fix compounded errors.
emphasis of Waterfall systems is on Unsuitable for complex projects and
planning, time schedules, target dates, rapidly-changing needs.
budgets, and perpetuation of an entire
system at one time.
b. Agile Development Methodology
i. Perhaps the most popular modern software development methodology is the agile
software development methodology. In a word, Agile is adaptive. The agile
methodology came as a relief from highly inflexible and structured methodologies like
Waterfall.
ii. The emphasis of an Agile software development methodology is communication
between individuals.
iii. Agile development methodology calls for collaboration and cross-functional
teamwork.
iv. Agile answers what the development process should look like, but it does not specify
any specified techniques for building software. That is why many professionals don't
exactly consider Agile as a methodology. More so, it is a software development
methodology framework.
v. It comprises the principles on which Agile software development methodologies like
scrum, crystal, extreme programming (XP), and feature-driven development (FDD)
build.
PROS CONS
It helps in minimizing project risk for defects Sometimes, the team may stray off
due to continuous learning and iterative testing track because of changing requests
practices and fine-tuning of customers.
vi. It is more preventive than reactive. Agile Because Agile focuses on working
software systems focus more on mitigating software, documentation is
risks than fixing bugs. secondary.
The intent of minimizing risks means there's There is hardly any place for
much less need for security specialists. beginner programmers.
c. Lean Development Methodology
i. At its core, lean development combines linear and iterative systems development
methodologies. And while Agile describes some of the best practices for developing a
software program, it does not include instructions for their application.
ii. The lean development methodology entails applying the following principles in
various projects and industries, including optimizing software development processes.
PROS CONS
Lean is scalable and adaptable to different facets and Using lean requires extensive
industries. documentation.
iii. Lean development is best for low-cost projects. not suitable for less-skilled
developers.
elimination of unnecessary tasks and activities means
optimal efficiency and saved time.

d. Rapid Application Development (RAD)

i. IBM first used rapid application development (RAD) to describe a software
development process introduced in 1991.
ii. Rapid application development methodology is one of the best software development
frameworks for building a high quality system with low investment cost.
iii. That is primarily due to Iterative Prototyping, active user feedback, and computerized
development tools (such as Object Oriented programming techniques, Database
Management Systems etc)
iv. Rapid application development is comprised of four stages:
Requirements This is the project specification and requirement definition
Planning phase.
User Design There is iterative communication between user and
developer throughout the development process. Here, the
feedback, prototype development, and testing procedures
 feedback, prototype development, and testing procedures
cyclically continue until a satisfactory level of refinement.
Construction Developers deploy the final software based on the
prototypes developed in the former phase.
Cutover This final phase includes data conversion, exhaustive
product testing, and user training.
PROS CONS
Since clients are directly involved in the software The process is mainly dependent
development process, it is more likely they favor on if customers are active.
v. the final product.
Perfect for small and medium software Developers must be highly
applications with time constraints. skilled and experienced.
Maintenance is easier

2. Software quality model

a. Software Quality Models are a standardised way of measuring a software product. With the
increasing trend in software industry, new applications are planned and developed
everyday. This eventually gives rise to the need for reassuring that the product so built
meets at least the expected standards.
b. Following are few models that explains what kind of quality criteria is to be followed:
i. Mc Call's Model: Mccall Model is the first quality model developed, which defines a
layout of the various aspects that define the product's quality. It defines the product
quality in the following manner – Product Revision, Product Operation, Product
Transition. Product revision deals with maintainability, flexibility and testability,
product operation is about correctness, reliability, efficiency and integrity.
ii. Boehm Model: This model describes how easily and reliably a software product can
be used. This model actually elaborates the aspects of McCall model in detail. It
begins with the characteristics that resorts to higher level requirements. The model's
general utility is divided into various factors - portability, efficiency and human
engineering, which are the refinement of factors like portability and utility. Further
maintainability is refined into testability, understandability and modifiability.
c. Importance of software quality models:
i. With the growing number of customer's demand for software systems, the
expectations for quality has also grown in terms of how reliable a software product
will be.
ii. As we know a software application is quite complex in nature, hence the task of
verifying whether a specific functionality has been implemented or not, becomes
quite difficult. Therefore software developers often divide the tasks in the form of
deliverables, that is, defining a benchmark to mark the completion of one specific
task.
iii. If the errors in some of the previous phases are not rectified on time, then it may lead
to that error being carried over to the next consecutive phases, which may have a
 to that error being carried over to the next consecutive phases, which may have a
serious problem in the later stages of the project.
d. Lot of effort is invested in the process quality improvement. When a project is undertaken,
the aim is to deliver the right product at the right time with the right functionalities. It is a
common scenario that the one at the receiving end always desires/expects the best to be
delivered to them. The onus lies on the developers and testers to ensure that they are able
to meet the expectations of their clients.

3. Different models of software development and their issues

Point 1 - Waterfall, agile, lean, RAD

4. Software Architecture
a. Software Architecture is the blueprint of building software. It shows the overall structure of
the software, the collection of components in it, and how they interact with one another
while hiding the implementation. This helps the software development team to clearly
communicate how the software is going to be built as per the requirements of customers.

b. Importance of Software Architecture : Software architecture comes under design phase of

software development life cycle. It is one of initial step of whole software development
process. Without software architecture proceeding to software development is like building
a house without designing architecture of house.
c. Advantages of Software Architecture:
i. Provides a solid foundation for software project.
ii. Helps in providing increased performance.
iii. Reduces development cost.
d. Disadvantages of Software Architecture :
i. Sometimes getting good tools and standardization becomes a problem for software
architecture.
ii. Initial prediction of success of project based on architecture is not always possible.

5. Evolution of software architecture

Software architecture is the blueprint of building software. It shows the overall structure of the
software, the collection of components in it, and how they interact with one another while hiding
the implementation. This helps the software development team to clearly communicate how the
software is going to be built as per the requirements of customers.
a. Monolith:
i. Monolithic software is designed to be self-contained, wherein the program's
components or functions are tightly coupled rather than loosely coupled. In a
monolithic architecture, each component and its associated components must all be
present for code to be executed or compiled and for the software to run.
ii. Monolithic applications are single-tiered, which means multiple components are
combined into one large application. Consequently, they tend to have large
codebases, which can be cumbersome to manage over time.
iii. Furthermore, if one program component must be updated, other elements may also
require rewriting, and the whole application has to be recompiled and tested.
 require rewriting, and the whole application has to be recompiled and tested.
iv. Advantages - simple and easy to implement
v. Disadvantages - scalability, elasticity and resilience

b. Service Oriented Architecture:

i. A Service-Oriented Architecture or SOA is a design pattern which is designed to build
distributed systems that deliver services to other applications through the protocol. It
is only a concept and not limited to any programming language or platform.
ii. Advantages - Easy to integrate, Reliable, parallel development
iii. Disadvantage- huge dependency

c. Microservices:
i. Emerged as a remedy to many difficulties faced in all Monolithic architectures. As the
microservices are decoupled, they could scale more easily. The main disadvantage in a
classical Microservices architecture is a dependency between synchronized service
calls.
ii. So adding new features and modifying existing microservices without affecting other
microservices are no longer a challenge when an application is built in a microservices
pattern.
iii. Example: Netflix is one of the most popular examples of software built-in
microservices architecture. This pattern is most suitable for websites and web apps
having small components.

d. Serverless architecture: Serverless is getting more and more popular, being adopted from a
large number of companies. Serverless computing is a new paradigm that provides a
platform to efficiently develop and deploy applications to the market without having to
manage any underling infrastructure

6. Software components and connectors

6. Software components and connectors
a. 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.

b. 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.

7. Common software architecture frameworks

a. Software Frameworks: 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.
b. For example, multiple Java frameworks, such as Spring, ZK, and the Java Collections
Framework (JCF) can be used to create Java programs. Additionally, Apple has created
several specific frameworks that can be accessed by OS X programs. These frameworks are
saved with a .FRAMEWORK file extension and are installed in the
/System/Library/Frameworks directory. Examples of OS X frameworks include
AddressBook.framework, CoreAudio.framework, CoreText.framework, and
QuickTime.framework
c. 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.
d. Advantages
i. Reuse code that has been pre-built and pre-tested. Increase the reliability of the new
 i. Reuse code that has been pre-built and pre-tested. Increase the reliability of the new
application and reduce the programming and testing effort, and time to market.
ii. A framework can help establish better programming practices and appropriate use of
design patterns and new programming tools.
iii. A framework can provide new functionality, improved performance, or improved
quality without additional programming by the framework user.
iv. By definition, a framework provides you with the means to extend its behaviour.
e. Disadvantages
i. Creating a framework is difficult and time-consuming (i.e. expensive).
ii. The learning curve for a new framework can be steep.
iii. Over time, a framework can become increasingly complex.
iv. Frameworks often add to the size of programs, a phenomenon termed “code bloat”.

8. Architecture business cycle

a. 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).
b. The organization goals of Architecture Business Cycle are bring about requirements, which
bring about an architecture, which bring abouts a system. The architecture flows from the
architect's experience and the technical environment of the day.
c. Three things required for ABC are as follows:
Case studies Methods Techniques
of successful architectures to assess an architecture for incremental
crafted to satisfy demanding before any system is built architecture-based
requirements, so as to help from it, so as to mitigate the development, so as to
set the technical playing field risks associated with uncover design flaws
of the day. launching unprecedented before it is too late to
designs. correct them.

9. Architectural patterns: 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.
Different Software Architecture Patterns :
a. Layered Pattern
i. As the name suggests, components(code) in this pattern are separated into layers of
subtasks and they are arranged one above another.
ii. Each layer has unique tasks to do and all the layers are independent of one another.
Since each layer is independent, one can modify the code inside a layer without
affecting others.
iii. The most commonly found 4 layers are as follows:
 iii. The most commonly found 4 layers are as follows:
1. Presentation layer (also known as UI layer)
2. Application layer (also known as service layer)
3. Business logic layer (also known as domain layer)
4. Data access layer (also known as persistence layer)
iv. Ideal for: E-commerce web applications development like Amazon.

b. Client-Server Pattern
i. 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.
ii. Usage: Online applications such as email, document sharing and banking.

c. Pipe-filter pattern
i. 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.
ii. Usage:
1. Compilers. The consecutive filters perform lexical analysis, parsing, semantic
analysis, and code generation.
2. Workflows in bioinformatics.

d. Master-slave pattern
i. 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.
ii. Usage:
1. In database replication, the master database is regarded as the authoritative
 1. In database replication, the master database is regarded as the authoritative
source, and the slave databases are synchronized to it.
2. Peripherals connected to a bus in a computer system (master and slave drives).

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

10. Reference model

a. A reference model is an abstract framework for understanding significant relationships
among the entities of some environment. It enables the development of specific reference
or concrete architectures using consistent standards or specifications supporting that
environment. A reference model consists of a minimal set of unifying concepts, axioms and
relationships within a particular problem domain, and is independent of specific standards,
technologies, implementations, or other concrete details.

UNIT - 2
UNIT - 2

1. Software architecture models:

a. Structural models
i. 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.
ii. Illustrates architecture as an ordered collection of program components
b. Framework models
i. Attempts to identify repeatable architectural design patterns encountered in similar
types of application. This leads to an increase in the level of abstraction.
c. Dynamic models
i. Specifies the behavioral aspect of the software architecture and indicates how the
structure or system configuration changes as the function changes due to change in
the external environment
d. Process models
i. Process models reveal how the system being developed is used in broader business
processes. UML activity diagrams may be used to define business process models.

2. Architectures styles:
a. Dataflow architecture
i. Dataflow architecture is a computer architecture that directly contrasts the traditional
von Neumann architecture or control flow architecture.
ii. Dataflow architectures have no program counter, in concept: the executability and
execution of instructions is solely determined based on the availability of input
arguments to the instructions.
iii. Although no commercially successful general-purpose computer hardware has used a
dataflow architecture, it has been successfully implemented in specialized hardware
such as in digital signal processing, network routing, graphics processing, telemetry,
and more recently in data warehousing, and artificial intelligence.
iv. In a data flow machine, a program consists of data flow nodes. A data flow node fires
(fetched and executed) when all its inputs are ready i.e. when all inputs have tokens
v. Data flow node

vi. Advantage of Data Flow architecture

• It supports reusability.
• It is maintainable and modifiable.
vii. Disadvantage of Data Flow architecture
• It frequently degenerates to batch sequential system
• Data flow architecture does not allow applications that require greater user
engagement.
• It is not easy to coordinate two different but related streams

b. Pipes and filters architecture

i. The Pipe and Filter is an architectural pattern for stream processing. It consists of one
or more components called filters. These filters will transform or filter data and then
pass it on via connectors called pipes. These filters, which merely consume and
 pass it on via connectors called pipes. These filters, which merely consume and
produce data, can be seen as functions like sorting and counting. All of these filters
can work at the same time. Also, every pipe connected to a filter has its own role in
the function of the filter. When data is sent from the producer (pump), it goes
through the pipes and filters, and arrives the destination (sink). The pump can be a
static text file or a keyboard input. The sink can be a file, a database or a computer
screen.
ii. The Pipe and Filter architectural style is suitable for applications that require a defined
series of independent computations to be performed on data.
Filter Pipe
A filter is an independent data stream Pipes are stateless and they carry
transformer or stream transducers. It transforms binary or character stream which
the data of the input data stream, processes it, exist between two filters. It can
and writes the transformed data stream over a move a data stream from one
iii.
pipe for the next filter to process. It works in an filter to another. Pipes use a little
incremental mode, in which it starts working as contextual information and retain
soon as data arrives through connected pipe. no state information between
There are two types of filters − active filter and instantiations.
passive filter.
iv. Examples of Pipe and Filter architectural style can be found in Unix Shell Scripts and
Compilers. In Unix programs, the output of one program can be linked to the input of
another program, i.e. connecting Unix processes via pipes.

c. Call-and return architecture

It is used to create a program that is easy to scale and modify. Many sub-styles exist within
this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.

d. Data-centered architecture
i. In data-centered architecture, the data is centralized and accessed frequently by
other components, which modify data. The main purpose of this style is to achieve
integrality of data. Data-centered architecture consists of different components that
communicate through shared data repositories. The components access a shared data
structure and are relatively independent, in that, they interact only through the data
store.
ii. In this architectural style, new components corresponding to clients can be added and
existing components can be modified easily without taking into account other clients.
This is because client components operate independently of one another.
iii. There are two types of components:
A central data structure or data store or A data accessor or a collection of
 A central data structure or data store or A data accessor or a collection of
data repository, which is responsible for independent components that operate on
providing permanent data storage. It the central data store, perform
represents the current state. computations, and might put back the
results.
iv. Some advantages of the data-centered architecture are listed below:
1. Clients operate independently of one another.
2. Data repository is independent of the clients.
3. It adds scalability (that is, new clients can be added easily).
4. It supports modifiability.

e. Layered architecture
i. Layered architectures are said to be the most common and widely used architectural
framework in software development. It is also known as an n-tier architecture and
describes an architectural pattern composed of several separate horizontal layers that
function together as a single unit of software. A layer is a logical separation of
components or code.
ii. In these frameworks, components that are related or that are similar are usually
placed on the same layers. However, each layer is different and contributes to a
different part of the overall system.
iii. Components of a Layered Architecture:
Presentation Layer responsible for user interactions with the
software system
Application/Business Layer handles aspects related to accomplishing
functional requirements
Domain Layer responsible for algorithms, and programming
components
Infrastructure/Persistence/Data esponsible for handling data, databases
base Layer

iv. One common example of this architectural style is OSI-ISO (Open Systems
 iv. One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication
system.
Advantages Disadvantages
The framework is simple and easy to Scalability is difficult because the
learn and implement. structure of the framework does not
allow for growth.
v. Cost overheads are fairly low. Parallel processing is not possible.
Testing is easier because of the separated They can be difficult to maintain. A
components change in a single layer can affect the
entire system because it operates as a
single unit.

f. Agent based architecture

i. Agents are autonomous or semi-autonomous hardware or software systems that
carry out tasks in complex, continuously changing environment.
ii. Capabilities of Agents: In order to cope with the tasks for which they are designed,
agents have the following basic capabilities;
Reactive That is, agents must react timely and appropriately to unplanned
events and to changes in the environment.
Goal oriented Agents act in a purposeful manner.
Communicative They should be able to communicate with the environment, other
agents, and/or people.
Adaptive They should be able to change their behavior due to previous
experience
Autonomous They must exercise control over their own actions.
iii. Two types:
Single-Agent Single-agent systems are based on the centralized process model. In
Systems these systems, there is a single agent which makes all the decisions,
leaving all the other agents to act as remote slaves.

Multi-Agent a multi-agent system is a loosely coupled network of problem-solving

Systems agents that work together to solve problems that none of them could
solve alone. The main difference between multi-agent systems and
single-agent systems is that in multi-agent systems several agents
exist, and they are aware of each other’s goals and actions.
g. Micro-services architecture
i. Microservices is a software or application development process. And this process
emphasizes on devising single-purpose modules with specific interfaces and
operations.
ii. Rather than building an application or software as a whole, the entire functionality set
is split up into unique processes. And then, each process is devised (both designed
and developed) as an independent service. Lastly, by combining all the microservices
together, a complete and efficient application emerges.
iii. As you might have guessed already, development complexity significantly reduces
with this practice. Also, your business gets the opportunity to adopt new technologies
and processes. This helps your business to stay competitive in today’s market.
iv. Example.Netflix, Uber, Spotify, etc. are leveraging the power of microservices
architecture.
Language Frameworks
Java Spring Boot, Spark
Python Flask
C++ REST SDK
.NET ASP.NET

h. Reactive Architecture
i. 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.
ii. Reactive Systems, in a nutshell, is an Architectural and Design pattern of building large
scale, responsive, resilient, self-healing systems where individual components talk to
each other over non-blocking Asynchronous Messaging.
iii. There are 4 principles in the context of Reactive Systems:
• Responsive : The system has to respond quickly to all users under all conditions.
• Resilient: The system stays responsive in the face of failure.
• Elastic: The system should provide responsiveness, despite increases(or
decreases) in load. Scaling up provides responsiveness during peak, while scaling
 decreases) in load. Scaling up provides responsiveness during peak, while scaling
down improves cost effectiveness.
• Message Driven: Reactive Systems rely on asynchronous message-passing to
establish a boundary between components that ensures loose coupling,
isolation and location transparency.

i. Representational state transfer architecture etc

REST, or REpresentational State Transfer, is an architectural style for providing standards
between computer systems on the web, making it easier for systems to communicate with
each other. REST-compliant systems, often called RESTful systems, are characterized by
how they are stateless and separate the concerns of client and server. REST is popular due
to its simplicity and the fact that it builds upon existing systems and features of the
internet's Hypertext Transfer Protocol (HTTP) in order to achieve its objectives, as opposed
to creating new standards, frameworks and technologies.
i. Advantages
1) Communication. REST-based interactions communicate their status through
numerical HTTP status codes
• 404 error indicates that a requested resource wasn't found
• 401 status response code is triggered by an unauthorized request
• 200 status response code indicates that a request was successful
• 500 error signals an unrecoverable application fault on the server.
2) Familiarity. Most developers are already familiar with key elements of the REST
architecture
3) Web APIs. When it comes to caching, RESTful services employ effective HTTP
mechanisms
4) The popularity of REST is due to its widespread use in both server- and client-
side implementations.
ii. Disadvantages
1) Developers working with REST frequently encounter limitations due to its
architecture design
2) Data overfetching/underfetching. RESTful services frequently return large
amounts of unusable data combined with relevant information, typically the
result of multiple server queries

UNIT - 3
UNIT - 3

1. Software architecture implementation technologies:

a. Software Architecture Description Languages (ADLs)
i. Architecture description languages (ADLs) are formal languages that can be used to
represent the architecture of a software-intensive system.
ii. UML and ADL
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".
A good ADL must provide abstractions that are adequate for modeling a large system.
Each ADL embodies a particular approach to the specification and evolution of
architecture.
Unified Modeling Language (UML) is formal graphical language considered a de facto
industrial stand. Although the language has been initially created as a graphical
language that supports object oriented software analysis and design, the language has
been revised a couple of times and today, it is a general formal language capable of
describing a software system.
iii. ADLs and their relationship to other languages
How do ADLs differ from programming languages, requirements languages, modeling
languages, and the like?
- - ADL
Requirements describes problem spaces describes solution space
languages
Programming binds all architectural abstractions ADLs do not bind
languages to specific point solutions architectural abstractions to
specific point solutions
Modeling Modeling languages represent ADLs focus on
languages behaviors representation of
components

2. Struts
a. Apache Struts is an elegant, extensible framework for creating enterprise-ready Java web
applications. This framework is designed to streamline the full development cycle from
building, to deploying and maintaining applications over time. Struts are thoroughly useful
in building J2EE (Java 2 Platform, Enterprise Edition) applications because struts takes
advantage of J2EE design patterns.
b. Struts depend on the MVC (Model View Controller) framework.
c. Model View Controller or MVC as it is popularly called, is a software design pattern for
developing web applications. A Model View Controller pattern is made up of the following
three parts −
Model The lowest level of the pattern which is responsible for maintaining data.
View This is responsible for displaying all or a portion of the data to the user.
Controller Software Code that controls the interactions between the Model and View.
 d. Struts has the following features:
i. Struts is almost simple, so easy to learn and use.
ii. Struts is very well integrated with J2EE.
iii. Struts has large user community.
iv. It takes much of the complexity out as instead of building your own MVC framework,
you can use struts.
v. It is flexible and extensible, it is easy for the existing web applications to adapt the
struts framework.

3. Hibernate
a. Hibernate is a java based ORM tool that provides a framework for mapping application
domain objects to the relational database tables and vice versa.
b. Hibernate is an open-source, non-invasive, light-weight java ORM(Object-relational
mapping) framework to develop objects which are independent of the database software
and make independent persistence logic in all JAVA, JEE
c. It is a java framework which is used to develop persistence logic. Persistence logic means to
store and process the data for long use.
d. Hibernate has a layered architecture which helps the user to operate without having to
know the underlying APIs. Hibernate makes use of the database and configuration data to
provide persistence services (and persistent objects) to the application.
e. How does Hibernate relate to JDBC?
Hibernate uses JDBC for all database communications. Hibernate uses JDBC to interact with
the database. Hibernate acts as an additional layer on top of JDBC and enables you to
implement a database-independent persistence layer:

f. Architecture
 g. Advantages of Hibernate:
i. Hibernate eliminates all the boiler-plate code that comes with JDBC
ii. Hibernate provides a powerful query language (HQL) that is similar to SQL.
iii. Hibernate is an open-source project from Red Hat Community and is used worldwide.
iv. Hibernate is easy to integrate with other Java EE frameworks
v. Hibernate supports caching that is better for performance

4. Node JS
a. Node.js is an extremely powerful JavaScript-based platform that’s built on Google Chrome's
JavaScript V8 Engine, used to develop I/O intensive web applications like video streaming
sites, single-page applications, online chat applications, and other web apps.
b. Node.js is used by large, established companies and newly-minted start-ups alike. Open-
source and completely free, the platform is used by thousands of developers around the
world. It brings plenty of advantages to the table, making it a better choice than other
server-side platforms like Java or PHP in many cases.
c. A web application, as you may already know, is a program that runs on a server and is
rendered by a client browser, using the internet to access all the resources of that
application. It usually can be easily broken down into three parts:
Client Server Database
The user interacts with the front- The server is The database stores the data
end part of a web application. The responsible for for a web application. The data
front-end is usually developed taking the client can be created, updated, and
using languages like HTML and CSS requests, deleted whenever the client
styles, along with extensive usage performing the requests. MySQL and MongoDB
of JavaScript-based frameworks required tasks, and are among the most popular
like ReactJS and Angular, which sending responses databases used to store data
help with application design. back to the clients. for web applications.
 d. Node.js Server Architecture: Node.js uses the “Single Threaded Event Loop” architecture to
handle multiple concurrent clients. Node.js Processing Model is based on the JavaScript
event-based model along with the JavaScript callback mechanism.
e. Advantages of Node.js Architecture:
i. Handling multiple concurrent client requests is fast and easy
ii. No need for creating multiple threads
iii. Requires fewer resources and memory

5. Angular JS
a. AngularJS is an open-source Model-View-Controller framework that is similar to the
JavaScript framework. AngularJS is probably one of the most popular modern-day web
frameworks available today. This framework is used for developing mostly Single Page
applications. This framework has been developed by a group of developers from Google
itself.
b. The Architecture of AngularJS: AngularJS is built upon the MVC design pattern. The
principles behind the MVC architecture are very well incorporated in AngularJS. One might
have known MVC to be a robust architecture for many server-side languages. AngularJS
amalgamated the MVC pattern on the client-side as well.
Model The lowest level of the pattern which is responsible for maintaining data.
View This is responsible for displaying all or a portion of the data to the user.
Controller Software Code that controls the interactions between the Model and View.

c. AngularJS Advantages:
i. Since it’s an open source framework, you can expect the number of errors or issues to be
minimal.
ii. Two-way binding – Angular.js keeps the data and presentation layer in sync.
iii. Routing – Angular can take care of routing which means moving from one view to
 iii. Routing – Angular can take care of routing which means moving from one view to
another.
iv. Angular supports testing, both Unit Testing, and Integration Testing.

6. J2EE: Java 2 Platform Enterprise Edition (J2EE) is a specification for a collection of software
components to enable development of multi-tiered web-based applications. These software
components include servlets, Java Server Pages (JSPs), and Enterprise Java Beans (EJBs)
The platform is based on a standard 3-tier architecture:
client tier (typically a web browser) (typically a web browser)
middle tier (the focus of J2EE)
Enterprise Information System (EIS) tier (databases, ERP, or legacy applications)

a. JSP:
i. Java Server 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 %>
ii. A Java Server Pages component is a type of Java servlet that is designed to fulfill the
role of a user interface for a Java web application
iii. Using JSP, you can collect input from users through Webpage forms, present records
from a database or another source, and create Webpages dynamically.
iv. Advantages of JSP
1) Coding in JSP is easy :- As it is just adding JAVA code to HTML/XML.
2) Reduction in the length of Code :- In JSP we use action tags, custom tags etc.
3) Connection to Database is easier
4) No Redeployment and No Re-Compilation :- It is dynamic
5) Portable, Powerful, flexible and easy to maintain

a. Servlets
i. Servlet technology is used to create a web application (resides at server side and
generates a dynamic web page). Servlet technology is robust and scalable because of
java language.
For example, we can use a Servlet to collect input from a user through an HTML form,
query records from a database, and create web pages dynamically.
ii. Servlets are under the control of another Java application called a Servlet Container.
When an application running in a web server receives a request, the Server hands the
request to the Servlet Container – which in turn passes it to the target Servlet.
iii. Advantages of Servlet
1) Better performance: because it creates a thread for each request, not process.
2) Portability: because it uses Java language.
3) Robust: JVM manages Servlets, so we don't need to worry about the memory
leak, garbage collection, etc.
4) Secure: because it uses java language.
5) Servlets are server independent, as they are compatible with any web server.
 b. EJBs
i. EJB is an acronym for enterprise java bean. It is a specification provided by Sun
Microsystems to develop secured, robust and scalable distributed applications.
ii. To run EJB application, you need an application server (EJB Container) such as Jboss,
Glassfish, Weblogic, Websphere etc. It performs:
1) life cycle management,
2) security,
3) transaction management, and
4) object pooling.
iii. Types of Enterprise Java Bean

Session Bean Session bean contains business logic that can be invoked by local,
remote or webservice client.
Message Like Session Bean, it contains the business logic but it is invoked by
Driven Bean passing message.
Entity Bean It encapsulates the state that can be persisted in the database. It is
deprecated. Now, it is replaced with JPA (Java Persistent API).
iv. Difference between RMI(point 7d) and EJB
RMI EJB
In RMI, middleware services such as security, In EJB, middleware services are
transaction management, object pooling etc. need provided by EJB Container
to be done by the java programmer. automatically.
RMI is not a server-side component. It is not EJB is a server-side
required to be deployed on the server. component, it is required to be
deployed on the server.
RMI is built on the top of socket programming. EJB technology is built on the
top of RMI.

7. Middleware:
Middleware is software that enables one or more kinds of communication or connectivity
between two or more applications or application components in a distributed network. By
making it easier to connect applications that weren't designed to connect with one another - and
providing functionality to connect them in intelligent ways - middleware streamlines application
development and speeds time to market.
At the most basic level, middleware enables developers to build applications without having to
create a custom integration every time they need to connect to application components (services
create a custom integration every time they need to connect to application components (services
or microservices), data sources, computing resources or devices.
a. JDBC
i. 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,
• Native Driver,
• Network Protocol Driver, and
• Thin Driver
ii. 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
iii. JDBC can be used to:
1) Connect to the database
2) Execute queries and update statements to the database
3) Retrieve the result received from the database.

iv. Hibernate is used to overcome the limitations of JDBC like:

i. If working with JDBC, changing of Database in middle of the project is very
costly.
ii. JDBC code is not portable code across the multiple database software.
iii. While working with JDBC, There is no support Object-level relationship.
iv. JDBC code is dependent upon the Database software being used

b. JNDI
i. JNDI stands for Java Naming and Directory Interface. JNDI is an API that provides
naming and directory functionality to Java applications. It can be used in distributed
systems so that even if a system has multiple servers, all the servers can share
information.
ii. For example, you can store configuration data such as IP addresses of application
servers in a JNDI directory, and applications can access it.
iii. Functionality provided by JNDI: JNDI can store and retrieve configuration information
for an enterprise bean or any other application. It uses a client-side API to let
applications perform directory operations such as binding or unbinding an enterprise
bean to a JNDI directory.
Benefits Limitations
You can write programs using JNDI APIs Only certain types of data can be stored
without knowing how your application’s using the standard set method provided
data is stored in a directory service. by JNDI, and data such as configuration
information does not fit into this model.
You can write code to access data on a There is no provision for transactions.
iv. single machine or across multiple
systems, as long as the resources are
accessible from a JNDI directory.
You can write programs using JNDI in any No built-in security model is provided,
programming language that provides a although some implementations provide
JNDI API. APIs to set up SSL connections to
 JNDI API. APIs to set up SSL connections to
directory servers.

c. JMS
i. 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.
ii. JMS is also known as a messaging service.
iii. JMS is mainly used to send and receive message from one application to another.
iv. Requirement of JMS
i. Generally, user sends message to application. But, if we want to send message
from one application to another, we need to use JMS API.
ii. 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.
v. Messaging Domains: There are two types of messaging domains in JMS.
Point-to-Point (PTP) Messaging In PTP model, one message is delivered to one
Domain receiver only.
Here, Queue is used as a message oriented
middleware (MOM). The Queue is responsible to
hold the message until receiver is ready.

Publisher/Subscriber (Pub/Sub) Publisher/Subscriber (Pub/Sub) Messaging Domain.

Messaging Domain It is like broadcasting.
Here, Topic is used as a message oriented
middleware that is responsible to hold and deliver
messages.

vi. Advantage of JMS

i. Asynchronous: To receive the message, client is not required to send request.
Message will arrive automatically to the client.
ii. Reliable: It provides assurance that message is delivered.

d. RMI
i. The RMI (Remote Method Invocation) is an API that provides a mechanism that allows
an object residing in one system (JVM) to access/invoke an object running on another
JVM.
ii. RMI is used to build distributed applications; it provides remote communication
between Java programs. It is provided in the package java.rmi.
iii. 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).
The following diagram shows the architecture of an RMI application,
 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 It is the layer which manages the references made by the client to
Reference Layer) the remote object.
iv. Difference between RMI and EJB
RMI EJB
In RMI, middleware services such as security, In EJB, middleware services are
transaction management, object pooling etc. need provided by EJB Container
to be done by the java programmer. automatically.
RMI is not a server-side component. It is not EJB is a server-side
required to be deployed on the server. component, it is required to be
deployed on the server.
RMI is built on the top of socket programming. EJB technology is built on the
top of RMI.

e. CORBA
i. Common Object Request Broker Architecture (CORBA) is a standard developed by
the Object Management Group to provide interoperability among distributed objects.
It is the world’s leading middleware solution. It enables the exchange of information,
independent hardware platforms, programming languages and operating systems. It
is often defined as “software bus” because it is a software based communication
interface through which the objects are located and accessed
ii. The CORBA Interface Definition Language, or IDL, allows the development of
language and location-independent interfaces to distributed objects.
iii. Using CORBA, application components can communicate with one another no matter
where they are located
iv. The illustration below identifies the primary components seen within a CORBA
implementation,
 8. Role of UML in software architecture
a. UML, which stands for Unified Modeling Language, is a way to visually represent the
architecture, design, and implementation of complex software systems. When you’re
writing code, there are thousands of lines in an application, and it’s difficult to keep track of
the relationships and hierarchies within a software system. UML diagrams divide that
software system into components and subcomponents.
b. Why should you use UML diagrams?
UML is a standardized modeling language that can be used across different programming
languages and development processes, so the majority of software developers will
understand it and be able to apply it to their work.
c. UML diagrams can help engineering teams:
i. Bring new team members or developers switching teams up to speed quickly.
ii. Navigate source code.
iii. Plan out new features before any programming takes place.
iv. Communicate with technical and non-technical audiences more easily.
d. UML standards identify 13 types of diagrams that are divided into two groups:
i. Structural UML diagrams
ii. Behavioural UML diagrams
e. UML notation:

UNIT - 4

1. Software Architecture analysis and design: Requirements for architecture

a. Architectures exist to build systems that satisfy requirements. That’s obvious. What may be
less obvious is that, to an architect, not all requirements are created equal. Some have a
much more profound effect on the architecture than others. An architecturally significant
requirement (ASR) is a requirement that will have a profound effect on the architecture—
that is, the architecture might well be dramatically different in the absence of such a
requirement.
b. You cannot hope to design a successful architecture if you do not know the ASRs. Architects
have to identify ASRs, usually after doing a significant bit of work to uncover candidate
 have to identify ASRs, usually after doing a significant bit of work to uncover candidate
ASRs.
c. Some systematic means for identifying the ASRs:
i. Gathering ASRs from Requirements Documents: Although requirements documents
won’t tell an architect the whole story, they are an important source of ASRs. Of
course, ASRs aren’t going to be conveniently labeled as such; the architect is going to
have to perform a bit of excavation and archaeology to ferret them out.
ii. Gathering ASRs by Interviewing Stakeholders: Interviewing the relevant stakeholders
is the surest way to learn what they know and need.
iii. Gathering ASRs by Understanding the Business Goals: Business goals are worth
capturing because they can hold the key to discovering ASRs that emerge in no other
context.

2. Life-cycle view of architecture design and analysis methods

Many architecture-centric analysis and design methods have been created in the past 10 years,
beginning with the Software Architecture Analysis Method (SAAM), which inspired the creation of
other methods. The first such method that we created at the Software Engineering Institute (SEI)
was the Architecture Tradeoff Analysis Method (ATAM). As we gained experience from the
ATAM, we expanded our repertoire into more phases of the life cycle with the following methods:
a. Cost Benefit Analysis Method (CBAM)
b. Active Reviews for Intermediate Designs (ARID)
c. Attribute-Driven Design (ADD) method
These methods share not only a common heritage, but also a common set of characteristics,
aside from being architecture-centric.
a. First, they all are scenario driven, with the scenarios serving as the “engine” for directing
and focusing the methods’ activities.
b. Second, they all are directed by operationalized quality attribute models

Architecture-based economic analysis:

The quality attributes achieved by architecture decisions have economic implications in terms of
the benefits (utility) that can be derived from those decisions.This interplay between the costs
and the benefits of architectural decisions guides (and torments) the architect.Knowing the costs
and benefits associated with particular decisions enables reasoned selection from among
competing alternatives.
a. Cost Benefit Analysis Method (CBAM)
i. CBAM is an analytical framework used to access the benefits and costs of policy
proposals
ii. CBAM focuses on economic efficiency
iii. The CBAM guides you through the process of identifying the costs and benefits of
architectural decisions that result in system qualities. Then you can consider the
information you compiled and choose from multiple proposed architecture options
iv. For example, you could decide whether to use redundant hardware, checkpointing, or
some other method to address concerns about the system’s reliability. Or you could
choose to invest the organization’s resources in some other quality attribute, such as
higher performance.
v. Why is useful
i. forces stakeholder to make scenario clear in advance
ii. allows benefits and costs to be compared overtime
iii. allows the consideration of a range of policy options
iv. determines which policy maximises net benefits to the community
b. Architecture Tradeoff Analysis Method (ATAM)
i. The Architecture Tradeoff Analysis Method (ATAM) is a method for evaluating
software architectures relative to quality attribute goals.
ii. ATAM evaluations expose architectural risks that potentially inhibit the achievement
of an organization's business goals.
iii. The ATAM is the leading method in the area of software architecture evaluation. An
evaluation using the ATAM typically takes three to four days.
iv. Challenges: Most complex software systems are required to be modifiable and have
good performance. They may also need to be secure, interoperable, portable, and
reliable.
v. Benefits:
 identified risks early in the life cycle
 increased communication among stakeholders
 clarified quality attribute requirements
 improved architecture documentation
 documented basis for architectural decisions

c. Active Reviews for Intermediate Design (ARID)

i. Methods for reviewing preliminary software designs (such as for a component or a
subsystem) for suitability in its intended usage context and environment.
ii. ARID is best suited for evaluating a partial design in its early stages.
iii. Goal: expose design to allow early feedback
iv. Designers want:
i. To know if the design is tenable
ii. To unveil the design to the community of software writers
v. The following are the major steps of ARID:
i. The designer and ARID facilitator identify the best reviewers, typically the
software engineers who will use the design.
ii. The designer explains the design to the facilitator and reviewers and walks
through examples of using the design.
iii. The reviewers brainstorm and prioritize scenarios for using the design to solve
problems they expect to face in each scenario. These scenarios define what it
means
iv. for the design to be usable.
v. The reviewers collaborate to write code that uses the design’s services to solve
the problem posed by each scenario.
vi. Benefits:
i. Provides valuable insight into design’s viability
ii. Allow for timely discovery of errors, inconsistencies, or inadequacies
 d. Attribute Driven Design method (ADD)
i. The Software Engineering Institute (SEI), Attribute-Driven Design (ADD) method is a
systematic step-by-step method for designing the software architecture of a software-
intensive system.
ii. It is an approach to defining software architectures by basing the design process on
the architecture's quality attribute requirements.
iii. Applying ADD results in the decomposition of the architecture, documented using
architectural views.
iv. ADD documents a software architecture in a number of views; most commonly,
module decomposition view concurrency view deployment view
v. Benefits: The ADD method enables designers to understand quality attribute
tradeoffs early in the design process and guides them in designing an architecture
that will satisfy both quality and functional requirements.

1. Architecture reuse
a. In most engineering disciplines, systems are designed by composing existing components
that have been used in other systems. Software engineering has been more focused on
original development but it is now recognized that to achieve better software, more quickly
and at lower cost, we need a design process that is based on systematic software reuse.
There has been a major switch to reuse-based development over the past 10 years.
b. Benefits of software reuse:
Accelerated Bringing a system to market as early as possible is often more
development important than overall development costs. Reusing software can
speed up system production.
Effective use of Instead of doing the same work over and over again, application
specialists specialists can develop reusable software that encapsulates their
knowledge.
Increased Reused software, which has been tried and tested in working systems,
dependability should be more dependable than new software.
Lower Development costs are proportional to the size of the software being
development costs developed. Reusing software means that fewer lines of code have to
be written.
c. Problems with software reuse:
i. If the source code of a reused software system or component is not available then
maintenance costs may be higher because the reused elements of the system may
become increasingly incompatible with system changes.
ii. Some software tools do not support development with reuse. It may be difficult or
impossible to integrate these tools with a component library system.
iii. Not-invented-here syndrome: Some software engineers prefer to rewrite
components because they believe they can improve on them. This is partly to do with
trust and partly to do with the fact that writing original software is seen as more
challenging than reusing other people's software.

2. Domain-specific Software architecture

a. A domain-specific software architecture (DSSA) comprises:
i. a reference architecture, which describes a general computational framework for a
significant domain of applications;
ii. a component library, which contains reusable chunks of domain expertise; and
iii. an application configuration method for selecting and configuring components within
the architecture to meet particular application requirements.
b. 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
 (domains) are mapped into domain-specific software architectures (DSSAs) which are
specialized into application-specific architectures and then implemented.
c. The three key factors of DSSA are:
i. Domain: Must have a domain to constrain the problem space and focus development
ii. Technology: Must have a variety of technological solutions like tools, patterns,
architectures & styles, legacy systems to bring to bear on a domain
iii. 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

UNIT - 5

1. Principles of sound documentation

Architecture documentation is much like the documentation we write in other facets of our
software development projects. As such, it obeys the same fundamental rules for what
distinguishes good, usable documentation from poor, ignored documentation.
a. Rule 1: Write Documentation 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.
b. Rule 2: Avoid Unnecessary Repetition
Follow DRY(don’t repeaet yourself) principle
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
c. Rule 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.
i. Rule 3a: Explain Your Notation
Make it as easy as possible for your reader to determine the meaning of the notation.
 Make it as easy as possible for your reader to determine the meaning of the notation.
The best way to do this is always to include a key in your diagrams.
d. Rule 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.
e. Rule 5: Record 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.
f. Rule 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. Why? 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.
g. Rule 7: Review Documentation for Fitness of Purpose
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.

2. Refinement
Refinement is the process of gradually disclosing information across a series of descriptions.
Architects need a way to carry out their designs and present information in a view in manageable
chunks. Refinement allows the architect to present information in separate, digestible pieces. A
refinement elaborates on (adds information to) an existing representation. Refinement allows the
architect to capture and present information with more or less detail. Less detail is useful in early
stages of design, and excellent for introductions, overviews, and early conceptualizing.
There are two important kinds of refinement:
a. Decomposition refinement is a refinement in which a single element is elaborated to reveal
its internal structure. Each member of that internal structure may be recursively refined.
Using decomposition refinements in a view carries an obligation to maintain consistency
with respect to the relation(s) native to that view. For example, suppose that the relation
shown in Figure 6.1(a) is send-data-to. Because element B is shown as both receiving and
sending data, the refinement of B in Figure 6.1(b) must show where data can enter and
leave B: in this case, via B1.

b. Implementation refinement is a refinement in which some or all of the elements and

relations are replaced by other, more implementation-specific, elements and relations.
For example, imagine two views of a publish-subscribe system, as shown in Figure 6.3. In
one view, components are connected by a single event bus. In the refined view, the bus is
 one view, components are connected by a single event bus. In the refined view, the bus is
replaced by an event dispatcher to which the components make explicit calls to achieve
their event announcements.

3. Context diagrams
1. The Context Diagram shows the system under consideration as a single high-level process
and then shows the relationship that the system has with other external entities (systems,
organizational groups, external data stores, etc.).
2. A top-level context diagram is a context diagram in which the scope is the entire system.
Entities in the environment may be humans, other computer systems, or physical objects,
such as sensors or controlled devices.
3. Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0
Data Flow Diagram.
4. Context Diagrams were created for systems analysis and design. But like many analysis
tools they have been leveraged for other purposes. For example, they can also be
leveraged to capture and communicate the interactions and flow of data between business
processes. So, they don’t have to be restricted to systems analysis.
5. A Context Diagram provides no information about the timing, sequencing, or
synchronization of processes such as which processes occur in sequence or in parallel.
Therefore it should not be confused with a flowchart or process flow which can show these
things.
6. Some of the benefits of a Context Diagram are:
i. Shows the scope and boundaries of a system at a glance including the other systems
that interface with it
ii. No technical knowledge is assumed or required to understand the diagram
iii. Easy to draw and amend due to its limited notation
iv. Easy to expand by adding different levels of DFDs
v. Can benefit a wide audience including stakeholders, business analyst, data analysts,
developers
7. A sample Context Diagram is shown here
4. Variability
1. 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.
2. Variability not only affects functionality but also the quality of software systems. For
example, variability in quality attributes can occur due to variations in different market
segments or customer profiles (e.g., premium customers may get better performance
compared to regular customers). In this scenario, performance requirements are “variation
points”.
3. We may not be able to predict all possible variants at design time since the complexity of
today's software systems and the behavior of users makes it impossible to predict all usage
scenarios. This requires adaptation at runtime and deferring the realization of variability
from design time to runtime.
4. In embedded systems, variability can either be handled in the software or the hardware
part. The software architecture must consider the resource constraints in embedded
systems when implementing variability. For example, it may not be feasible to implement
all possible variants in the software of an embedded system due to memory constraints.
5. The software architecture documentation is organized into different models and
architecture views. Thus, architects must be able to model variability in and across different
architecture models or views (e.g., logical or process views). At the same time we must
ensure consistency and traceability of variability from requirements to architecture to
implementation.

5. Software interfaces
1. The connection and interaction between hardware, software and the user. Users "talk to"
the software. The software "talks to" the hardware and other software. Hardware "talks to"
other hardware. All this is interfacing. It has to be designed, developed, tested and
redesigned; and with each incarnation, a new specification is born that may become yet
one more de facto or regulated standard.
2. Software interfaces (programming interfaces) are the languages, codes and messages that
programs use to communicate with each other and to the hardware. Examples are the
Windows, Mac and Linux operating systems, SMTP email, IP network protocols and the
software drivers that activate the peripheral devices.
3. Hardware interfaces are the plugs, sockets, cables and electrical signals traveling through
them. Examples are USB, FireWire, Ethernet, ATA/IDE, SCSI and PCI.
4. User interfaces are the keyboards, mice, commands and menus used for communication
between you and the computer. Examples are the command lines in DOS and Unix, and the
 between you and the computer. Examples are the command lines in DOS and Unix, and the
graphical interfaces in Windows, Mac and Linux.

6. Documenting the behavior of software elements and software systems

1. Documenting behavioral aspects of an architecture provides many benefits both during
development of the architecture and during system maintenance. This information can be
used to gain understanding of a system, and it can also help stakeholders reason about how
a system built to the architecture will be able to meet many of its quality-related goals. For
example, behavior documentation can identify potential deadlocks and bottlenecks. Such
documentation clarifies to developers the steps and states involved in the operations.
2. 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.

7. Documentation package using a seven-part template

1. Primary presentation should contain the information you wish to convey about the
system.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.
2. Element catalog details at least those elements and relations depicted in the primary
presentation.
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
5. Architecture 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.
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.