SOFTWARE

ARCHITECTURE
 Module 1: Introduction to software architecture and software
product life cycle.

🠶Evolution of software development

🠶Fundamentals of software engineering
🠶Elements of software architecture
🠶Management view
🠶Software engineering view
🠶Engineering design view
🠶Architectural view
 Course Objective:
🠶 To understand the importance of software architecture in
building effective, efficient & competitive software product by
applying principal design decisions governing the system &
designing applications from architectural perspective by
identifying different functional and non-functional properties
of complex software system.
 Sr.
Course Outcome: Cognitive levels    
Course Outcomes of attainment as PO PSO
No. per Bloom’s
Taxonomy

    Levels    

1 Understand & gain knowledge of various L1,L2 CO1- CO1

approaches to document a software system PO1,2,5,10 -
PSO
1,2
 What Is Software Architecture?

🠶 Software architecture is, simply, the organization of a system. this

organization includes all components, how they interact with each other,
the environment in which they operate, and the principles used to design
the software. in many cases, it can also include the evolution of the
software into the future.
 Evolution of software development

🠶 software evolution is a term which refers to the process of developing

software initially, then timely updating it for various reasons, i.e., to add
new features or to remove obsolete functionalities, etc. the evolution
process includes fundamental activities of change analysis, release
planning, system implementation and releasing a system to customers. 
🠶 A design is then made on which changes to implement in the next version of the system.
the process of change implementation is an iteration of the development process where
the revisions to the system are designed, implemented, and tested. 
🠶 Necessity of software evolution: software evaluation is necessary just because of the
following reasons:

a) change in requirement with time: with the passing of time, the organization’s needs
and modus operandi of working could substantially be changed so in this frequently
changing time the tools(software) that they are using need to change for maximizing the
performance.

b) environment change: as the working environment changes the things(tools) that enable
us to work in that environment also change proportionally same happens in the software
world as the working environment changes then, the organizations need to reintroduction of
old software with updated features and functionality to adapt the new environment.
c) errors and bugs: as the age of the deployed software within an organization increases their preciseness or
impeccability decreases and the efficiency to bear the increasing complexity workload also continually
degrades. so, in that case, it becomes necessary to avoid the use of obsolete and aged software. all such
obsolete softwares need to undergo the evolution process in order to become robust as per the workload
complexity of the current environment.  

d) security risks: using outdated software within an organization may lead you to at the verge of various
software-based cyberattacks and could expose your confidential data illegally associated with the software that
is in use. so, it becomes necessary to avoid such security breaches through regular assessment of the security
patches/modules are used within the software. if the software isn’t robust enough to bear the current occurring
cyberattacks so it must be changed (updated).

e) for having new functionality and features: in order to increase the performance and fast data processing
and other functionalities, an organization needs to continuously evolute the software throughout its life cycle
so that stakeholders & clients of the product could work efficiently.
🠶Laws used for software evolution: 
1. Law of continuing change: 
this law states that any software system that represents some real-world reality undergoes continuous
change or becomes progressively less useful in that environment.
2. Laws of increasing complexity: 
as an evolving program changes, its structure becomes more complex unless effective efforts are made to
avoid this phenomenon.
3. Law of conservation of organization stability: 
over the lifetime of a program, the rate of development of that program is approximately constant and
independent of the resource devoted to system development.
4. Law of conservation of familiarity: 
this law states that during the active lifetime of the program, changes made in the successive release are
almost constant.
 Software Architecture:
The 5 Patterns You Need to Know
🠶 Layered Pattern
🠶 The layered pattern is probably one of the most well-known software architecture
patterns. Many developers use it, without really knowing its name. The idea is to split up
your code into “layers”, where each layer has a certain responsibility and provides a
service to a higher layer.

🠶 There isn’t a predefined number of layers, but these are the ones you see most often:

🠶 Presentation or UI layer
🠶 Application layer
🠶 Business or domain layer
🠶 Persistence or data access layer
🠶 Database layer
🠶 Layer Responsibility
🠶 As mentioned, each layer has its own responsibility. The presentation layer contains the graphical
design of the application, as well as any code to handle user interaction. You shouldn’t add logic that is
not specific to the user interface in this layer.

🠶 The application layer sits between the presentation layer and the business layer. On the one hand, it
provides an abstraction so that the presentation layer doesn’t need to know the business layer. In
theory, you could change the technology stack of the presentation layer without changing anything else
in your application (e.g. change from WinForms to WPF). On the other hand, the application layer
provides a place to put certain coordination logic that doesn’t fit in the business or presentation layer.

🠶 The business layer is where you put the models and logic that is specific to the business problem you
are trying to solve.

🠶 Finally, the persistence layer contains the code to access the database layer. The database layer is the
underlying database technology (e.g. SQL Server, MongoDB). The persistence layer is the set of code
to manipulate the database: SQL statements, connection details, etc.
 Advantages
🠶 It is possible to understand and satisfy the requirements of customers through
architecture.

🠶 Once a developer knows the architecture and its development fully, the
organization’s market position is improved because who will say no to a supplier that
understands customers very well.

🠶 All the use cases are understood and solved in the architecture by knowing the
scenarios. This helps the developers to boost their confidence and morale in and
around them. Work satisfaction and thus, the revenue of the company is improved.
The Software Product Life Cycle: Views

🠶 views are ways of categorizing different perceptions of

stakeholders using the Rational Unified Process (RUP) as a
foundation.
🠶 The views presented are:
🠶 Management
🠶 Software engineering
🠶 Engineering design
🠶 Architectural design
🠶 Each view of the development process is comprised of
phases, activities, tasks, and steps.
 What is a Rational Unified Process (RUP)?
🠶 Rational Unified Process (RUP) is an agile software
development method, in which the life cycle of a
project, or the development of software, is divided into
four phases.
🠶 Various activities take place during these phases:
modelling, analysis and design, implementation, testing
and application.
🠶 Rational unified process: time dimension
🠶 the time dimension means the dynamic organisation from the
process over time. the software’s life cycle is itself divided further
into cycles.
🠶 Each cycle corresponds to, for example, a period in which a new
generation of a product is being worked on. the rational unified
process (rup) divides development into the four consecutive
phases:
🠶 Inception phase
🠶 Elaboration phase
🠶 Construction phase
🠶 Transition phase
🠶PHASE 1: INCEPTION
🠶 During the first phase, the basic idea and structure of the project are determined. in
this phase, the team meets regularly to determine the project’s necessity, but also its
viability and suitability. viability and suitability also include the expected costs and the
means needed to complete the project after the green light has been given.

🠶 Depending on the project, the result of the first phase could be:

🠶 Problem statement
🠶 first use case (20% completed)
🠶 market research results
🠶 financial prognosis
🠶 risk assessment
🠶 project plan
🠶 corporate or business model
🠶 prototypes
🠶 Phase 2: elaboration
🠶 During the elaboration phase, the system’s requirements and its required
architecture are assessed and analyzed. This is where the project begins to take
shape. the objective of the elaboration phase is to analyze products and lay a
foundation for the future architecture. results of the elaboration phase include:
🠶 use case (80% completed)
🠶 description of the feasible architecture
🠶 project development plan
🠶 prototypes for tackling risks
🠶 user manual

🠶 criteria for the results:

🠶 is the architecture stable?
🠶 are important risks being tackled?
🠶 is the development plan sufficiently detailed and accurate?
🠶 do all interested parties agree on the current design?
🠶 are the expenditures acceptable?
Phase 3: Construction –
🠶 The project is developed and completed.
🠶 System or source code is created and then testing is done.
🠶 Coding takes place.
Phase 4: Transition –
🠶 The final project is released to the public.
🠶 Transit the project from development into production.
🠶 Update project documentation.
🠶 Beta testing is conducted.
🠶 Defects are removed from the project based on feedback from the
public.
Phase 5: Production –
🠶 the final phase of the model.
🠶 the project is maintained and updated accordingly.

Advantages:
🠶 It provides good documentation, it completes the process in itself.
🠶 It provides risk-management support.
🠶 It reuses the components, and hence total time duration is less.
🠶 Good online support is available in the form of tutorials and training.

Disadvantages:

🠶 Team of expert professional is required, as the process is complex.

🠶 Complex and not properly organized process.
🠶 More dependency on risk management.
🠶 Hard to integrate again and again.
 SOLID principles

🠶 SOLID principles of Software architecture :

🠶 Each character of the word SOLID defines one principle of software architecture.
🠶 This SOLID principle is followed to avoid product strategy mistakes. A software
architecture must adhere to SOLID principle to avoid any architectural or
developmental failure.
🠶 single responsibility – Each services should have a single objective.
🠶 open-closed principle – software modules should be independent
and expandable.
🠶 liskov substitution principle – independent services should be able
to communicate and substitute each other.
🠶 interface segregation principle – software should be divided into
such microservices there should not be any redundancies.
🠶 dependency inversion principle – higher-levels modules should not
be depending on low-lower-level modules and changes in higher
level will not affect to lower level.
 Types of Architecture
🠶 There are different types of architecture from the viewpoint of an enterprise and
collectively, these architectures are referred to as enterprise architecture.
🠶 Business architecture − defines the strategy of the business, governance,
organization, and key business processes within an enterprise and focuses on the
analysis and design of business processes.

🠶 Application (software) architecture − serves as the blueprint for individual

application systems, their interactions, and their relationships to the business
processes of the organization.

🠶 Information architecture − defines the logical and physical data assets and data
management resources.
🠶 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.
🠶UML
🠶 UML stands for Unified Modeling Language. It is a pictorial
language used to make software blueprints. UML was created by
Object Management Group (OMG).

🠶 The elements are like components which can be associated in

different ways to make a complete UML picture, which is known
as a diagram. So, it is very important to understand the different
diagrams to implement the knowledge in real-life systems. We
have two broad categories of diagrams and they are further
divided into sub-categories i.e. Structural Diagrams and
Behavioral Diagrams.
🠶 Structural Diagrams
🠶 Structural diagrams represent the static aspects of a system. These
static aspects represent those parts of a diagram which forms the
main structure and is therefore stable.
🠶 Class
🠶 Represents the object orientation of a system. Shows how classes
are statically related
🠶 Object
🠶 Represents a set of objects and their relationships at runtime and
also represent the static view of the system.
🠶 Component
🠶 Describes all the components, their interrelationship, interactions
and interface of the system.
🠶 Behavioral Diagrams
🠶 Behavioral diagrams basically capture the dynamic aspect of a
system.
🠶 Dynamic aspects are basically the changing/moving parts of a
system. UML has the following types of behavioral diagrams −

🠶 Use case diagram

🠶 Sequence diagram
🠶 Communication diagram
🠶 State chart diagram
🠶 Activity diagram
🠶 Interaction overview
🠶 Time sequence diagram
🠶 Use case
🠶 Describes the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.
🠶 Activity
🠶 Describes the flow of control in a system. It consists of activities
and links. The flow can be sequential, concurrent, or branched.
🠶 Communication
🠶 Same as sequence diagram, except that it focuses on the object’s
role. Each communication is associated with a sequence order,
number plus the past messages.
 Architectural Structures and Views
🠶 Definition
1. View
🠶 A representation of a set of elements and the relations among
them.
2. Structure
🠶 The set of elements itself, as they exist in software or hardware
🠶 Restrict our attention at any one moment to one (or a small
number) of the software system’s structures.
🠶 To communicate meaningfully about an architecture, we must
make clear which structure or structures we are discussing at the
moment.
SOFTWARE STRUCTURES
Module structures
🠶 Elements are modules, which are units of implementation.
🠶 * What is the primary functional responsibility assigned to each module?
🠶 * What other software elements is a module allowed to use?
🠶 * What other software does it actually use?
Decomposition
🠶 * shows how larger modules are decomposed into smaller ones recursively
Uses
* The units are: modules, procedures or resources on the interfaces of modules
* The units are related by the uses relation
Layered
* "uses relations" structured into layers
Class, or generalization
* shows the “inherits-from” or “is-an-instance-of” relations among the modules
Component-and-connector structures
🠶 Elements are runtime components (units of computation) and connectors
(communication vehicles among components)
🠶 The relation is attachment, showing how the components and connectors
are hooked together
🠶 * What are the major executing components and how do they interact?
🠶 * What are the major shared data stores?
🠶 * Which parts of the system are replicated?
🠶 * How does data progress through the system?
🠶 * What parts of the system can run in parallel?
🠶 * How can the system’s structure change as it executes?
Process, or communicating processes
🠶 * units are processes or threads that are connected with each other by
communication, synchronization, and/or exclusion operations
Concurrency
🠶 * The units are components and the connectors are “logical
threads”
🠶 * A logical thread is a sequence of computation that can be
allocated to a separate physical thread
Shared data, or repository
🠶 * This structure comprises components and connectors that
create, store, and access persistent data
Client-server
🠶 * The components are the clients and servers, and the
connectors are protocols and messages
Allocation structures
🠶 the relationship between the software elements and the elements in one or more external
environments
🠶 * What processor does each software element execute on?
🠶 * In what files is each element stored during development, testing, and system building?
🠶 * What is the assignment of software elements to development teams?
Deployment
🠶 * Shows how software (usually a process from a component-and-connector view) is
assigned to hardware-processing and communication elements
🠶 * Relations are “allocated-to” and “migrates-to” if the allocation is dynamic
Implementation
🠶 * how software elements (usually modules) are mapped to the file structure(s)
Work assignment
🠶 * assigns responsibility for implementing and integrating the modules to development
team
The Scope of Design
🠶 Tasks and Activities of Design

🠶 Any design activity can be seen from many points of view: Psychological
🠶 Systematic
🠶 Organizational

🠶 From the psychological view, design is a creative process that requires knowledge in the appropriate
disciplines such as software engineering, computer science, logic, cognitive science, linguistics,
programming languages, and software design methodologies as well as application domain-specific
knowledge. HCI approaches software development and use from the psychological aspect.

🠶 From the systematic view, design is seen as an architecting or engineering activity that involves finding
optimized solutions to a set of objectives or problems while balancing competing obstacles or forces.

🠶 The organizational view considers essential elements of the application or system life cycle. Application
development begins with a market need or a new product idea. Application design (or, more generally,
product design) starts with planning and ends when the product reaches its end of life (in software this
means executing an end-of-life strategy and implies that a product is no longer maintained or
supported). There may be some recycling of software elements to be reused in other products.
Takeaway Questions:
1. Define Software Architecture
2. Distinguish Between software architecture and software engineering
3. Differentiate between component and deployment diagram.
4. challenges in Software Architectural Design.
5. Advantages and Disadvantages of Software Architecture and Software Engineering
6. Explain the n need and significance of Software Architecture in detail
7. Draw Activity diagram on Banking System
8. Draw Usecase diagram Airline Booking System
9. Explain SDLC phases
10. Explain the Rational Unified Process model with its phases in detail.
11. State the Scope of design
12. List types of software architecture