INF4057

SOFTWARE Architecture

2023/2024 Session

Course Lecturer: Dr. KIMBI Xaveria

 COURSE CONTENT
● (1) Motivating Example and Basic Terminologies
● (2) Why Software Architecture: An illustrative Example
● (3) The Main Concepts in Software Architecture
● (4) Architectural Design Principles
● (5) Software Architectural Styles
● (6) Event-driven Micro-service Architecture
● (7) Clean Architecture
● (7) Study of Frameworks and Deployment Architectures
● (8) Cloud-based Architectures
● (9) Deployment of Mircroservice Architecture
● References:
● Software Architecture for developers - Simon Brown
● Software Architecture Cesare Pautasso
● Software Architecture In Pratice Fourth Edition - Len Bass,
Paul Clements,
● Software Architecture Patterns - Mark Richards
Course Objective and Development Attitude
Course Description:
To provide a sound technical exposure to the concepts, principles, techniques, architectural styles,
and best practices in software architecture and software design.
Course Objectives: Upon successful completion of this course, the students will be able to:
● Develop skills with several software architectural principles and techniques to design a well
structured system architecture for large-scale systems.
● Develop skills for designing and deploying mircroservice architecture in large
organizations. Conceptualize and coordinate designs, addressing technological aspects
of architecture.
● Practicals: Designing Event-Driven Mircro-service Applications Using Apache Kafka/Apache
Flume Ecosystem
● Translate architectural designs to mathematical models.
● Acquire techniques and practices suitable for designing complex and large- scale systems.
● Choose an architectural models for a real life project.
● Development attitude: A collaborative research-oriented approach in groups of 5
 Evaluation Method
A three-phased evaluation method will be adopted:
● CC evaluation at the end of first five lessons (Quiz1/Practicals) = CC1
● CC evaluation in the form of class discussion = CC2
● CC1 + CC2 = CC
● TP evaluation of two real live projects:
● General Examination:
● CC = 20% TP = 30% EE = 50%
 Today's Lecture
● Problem Solving for the Big Picture (Software Development)
● In the beginning of Software Development Versus Today’s Software
Development
● Introduction to Software Architecture
● What is Software Architecture?
● The Goal of Software Architecture
● Principles of Software Architectural Design
● Architectural Drivers
● Architectural Structures and Views.
● System Analysis Versus System Design
● Design Strategies for Software Architecture
 Problem Solving for the Big Picture -
(Motivating Example and Basic Terminologies)
● Suppose you're planning a trip from Yaounde to Bamenda. There are two major
aspects that you need to keep in mind:
● What do you need to do before starting the trip?
● What do you need to do during the trip to ensure that you stay on the right track?
● Generally, there are two extreme options in planning for such a trip:
● (1) Take your car and start driving. Figure things out along the way without any
preconceived plan.
● (2) Make a very detail plan for your journey: Service your care, make a well
structure plan including - figure out the route, note down the directions at every
junction, plan for contingencies such as a flat tire, plan where you're going to stop,
and so on.
● The first scenario allows you to execute fast. The problem is that, more likely than
not, your trip will be very adventurous. Most likely, your route will not be optimal.
 ● An example of a
● Client-Server architectural
Are the above architectures identical?

● Every system has its own architecture and they are not identical.
● Discuss
●
 In the beginning of Software Development
Versus
Today’s Software Development

● Let us access software developmental changes w.r.t. to our society

● Apache Kafka Ecosystem: Event-driven Architecture for distributed
system, one of the most popular messaging systems for distributed
applications. It provides fault tolerance, scalability, and high availability
for efficient data streaming and messaging in large-scale applications.
(Producer API, Consumer API, Streams API, Connector API, ...)
● Apache Flume Ecosystem: Event-driven Architecture for distributed
system
Our Society Highly Depends on Software
● Are the above systems
software controlled?
Our Society Depends Highly on Software

● .
● Question: Software development has evolved drastically such that our society highly
depends on software. Despite this advancement, is there a single software that can be used
in all sectors?
● In the beginning software, software was small both physically and in scope. e.g FORTRAN a
language for scientific computing, COBOL, BASIC, PASCAL
● As software started to grow up;
● Languages like C introduce file linking -Enables organization of code and reuse of code.
● SIMULA-67, Smalltalk introduce objects -Enables organization of code into focused units that
work with other objects to perform larger tasks.
● And Today – We have more object-oriented programming languages like Java, Python, etc
● Frameworks, Containers, etc
● All that above have different software architectures on which they were constructed
- Our Society Highly Depends on Software

● Software development has been the fastest-growing technology in human history. Despite the
advancement, there is not single software that can be used in all sectors.
● Why?
● Answer: Software requirements varies from one system to another, therefore, there is no
architecture that encompasses the entire spectrum of software design and development
possibilities, hence no single software that can function in all sectors for different purposes.
 What is Software Architecture?
● The word “architecture” means many different things to
many different people, and there are many different
definitions published on the Internet.
● If you look at most software systems, they’re actually
composed of multiple deployable units (e.g. applications
or datastores), each of which might be built using different
technologies.
 What is Software Architecture?
● Software architecture (SA) defines (describes):
● The components of the software system and how the components use each other’s
functionality and data.
● I.e The major components of SUT and how well these components communicate
● A software architecture is a creative activity that describes the various software
components and their relationships based on customers’ requirements.
● An example: client-server Architecture
● Servers provide some kind of service; clients request and consume services
applications are located with clients
● E.g. running on PCs and workstations;

● Data storage is treated as a server:

● Software architecture is a
critical bridge between
software requirements and
implementation
● Software architecture =
● Software Components +
● The Relationship among
them
● The network is part of the architecture
● The database is part of the architecture
● The X framework is part of the architecture
● Architecture is more than just a list of
● products that are used in a project
● Technology shapes an architecture, but an architecture
should not only be bound tothe technologies that form it
(technology changes too fast)
 The benefits of software architecture

● Does your software system have a well-defined structure?

● Is everybody on the team implementing features in a
consistent way?
● Is there a consistent level of quality across the codebase?
● Do team members share the same vision for how the
software will be
● built?
 What is Architectural-Based Development
and
how can the complexity of large software be managed?
Why Architectural-based development
Application architecture style help define the basic characteristics and behavior of an application at a glance.

For example, some architecture pattern naturally lend themselves toward highly scalable applications, whereas
other architecture naturally lend themselves toward applications that are highly agile.

Though systematic way, knowing the design principle, characteristics, strengths, and weaknesses of each
architecture style is necessary in order to choose the one that meets the specific business needs and goals.
Architecture styles are templates for concrete software architectures. They specific the system-wide structure
properties of an application, and have an impact on the architecture level of its sub system. To choose the right
architectural style, architect have to rely on business goals and quality attributes.

The selection of an architectural style is therefore a fundamental design decision when developing a software
system.

The easiest way to describe the methodology of your research, is through the used of a well structured
architecture.
 Why Architectural-based development

● Are you looking for means to communicate between

stakeholder and others parties in the development team?
● Representations of software architecture (SA) are an
enabler for communication between all parties
(stakeholders) interested in the development of a
computer-based system. (A big picture) – I.e SA is a
blueprint with which you construct your software; SA
dispicts the structure of the system but hide the
implementation details
Why Software Architecture?
The role of the Software Architect:
● A Software Architect presents an overview of the (system)
architecture including:
● - technical constraints such as an OS, hardware, API
gateways, or middle-ware prescribed for use
● - other systems with which the system must interact
● - architectural approaches used to meet quality attribute
requirements
Why Software Architecture?
The role of the Software Architect:
● It outlines the elements needed for making and
executing a blueprint for a successful software
product.
● Why will project owners wish to incorporate
architectural design in their projects?
● Software architecture is an art - meaning there are
various ways of representing the same architecture based
on the view point of the system analyst.
 Analysis in the Design Process
● Recall the following concepts in Software Engineering:
● System Analysis Versus System Design
● Is there any difference between System Analysis and System Design?

● Is there any difference between Architecture and Design

● All architecture is design but not all design is
architecture.
● Why: Because all architectures are based on design
principles.
● Architecture represents the significant design decisions
that shape a system, where significance is measured by
the cost of change.
● System Analysis is a process of collecting and analyzing
the requirements of the system whereas System Design is
a process of creating a design for the system to meet the
requirements.
● Design is the process of making decisions; analysis is the
process of understanding those decisions, so that the
design may be evaluated.
 System Analysis Vs System Design
● System Analysis ● I.e
● It is the study of the ● What is the problem?
existing system to ● what happens in the
identify the problem current system?
areas.
● Have you understood
● It is a process of domain analysis
understanding the
system requirements ● what is required in the new
and its environment. system?
● Results (Outcome of
 System Analysis Vs System Design
● Software Design
● Software design is a creative activity in which you
identify software components and their relationships,
based on a customer’s requirements.

● System Design is the process of creating a design for

the system to meet the requirements. System design
is the process of designing the architecture,
components, modules, interfaces, and data for a
● System design Investigates “how to build a solution”
● How will the new system work?
● How can we solve the problem that the analysis phase
identified?
● Results in a solution to the problem. I.E The purpose
of Design phase in the Software Development Life
Cycle is to produce a solution to a problem given in
the SRS(Software Requirement Specification)
document. The output of the design phase is Software
 Architectural Design Concepts: Cohesion
and Coupling
● Coupling and cohesion are methods to measure the
relationship between and within modules. A software
system is divided into multiple modules, where each and
every module are capable of performing a function
independently. This technique is known as Modularization
● Coupling is the degree of inter-dependencies between
software modules.
● Cohesion is the degree of intra-dependencies within
the functionalities in a software component.
Cohesion and Coupling
● Software Architecture seeks to establish the following:
● (1) Which kind of components and connectors are used?
● (2) How is data communicated through the system
Quality Attributes in Software Architecture
(Architectural Drivers)
● Interoperability: Ability of a system or different systems
to operate successfully by communicating and exchanging
information with other external systems written and run by
external parties. I.e The degree to which two or more systems
(components) can usefully exchange information
● Maintainability: Ability of the system to undergo changes
with a degree of ease
● Correctness: Accountability for satisfying all requirements
of the system.
 Principles of Architectural Design Process

● This technique consists of five steps that are performed

iteratively
● The following are the main principles of software architectural
design process:-
● 1- Understand the research problem
● 2- Identify design elements and their relationships
● 3- Evaluate the architectural design
● 4- Transform the architecture design
Principles of Architectural Design Process
● (1) Understand the Research Problem:
● This is the most crucial step because it affects the quality
of the design that follows.
● Without a clear understanding of the problem, it is not
possible to create an effective solution.
● Many software projects are considered failures because
they did not actually solve a valid business problem.
● Architectural requirement analysis is a principal indicator
to bridge the gab between the problem domain and
solution domain
Principles of Architectural Design Process
● (2) Identify Key Design Elements and their
Relationships (Candidate Architecture):
● In this phase, the Software Architecture builds a baseline
for defining the system boundaries and the context of the
system (scope).
● This step is divided into the following set of activities:
● (a) Start by identifying architectural components,
relationships between the components and define
high level-business objectives – Use Cases.
● The Software Architect carries out the process of system
● Candidate architectures include an application type,
deployment architecture, architectural style, technology
choices, quality attributes, and crosscutting concerns. If a
candidate architecture satisfies the requirements and
issues, then it becomes a baseline architecture and is
refined in further iterations.
 Principles of Architectural Design Process
● (3) Evaluate the architectural design:
● - The architecture is evaluated with respect to quality
attributes.
● - The Software Architect evaluates the architectural
design to see if it is good enough to be implemented.
● *Evaluate Architecture with stakeholders
● - It involves evaluating the architecture for conformance to
architectural quality attributes requirements.
● - If the observed quality attribute does not meet its user’s
requirements, then a new design must be created.
Principles of Architectural Design Process

● (4) Transform the Architectural Design:

● Revisit requirements
● This step performed after an evaluation of the architectural
design.
● The architectural design must be revisited until it
completely satisfies the quality attributes.
● This candidate architecture is further refined through a
series of iterations until it is deemed acceptable after an
evaluation is performed.
Attribute-driven Design

● Attributes driven design (ADD) is an approach to defining

software architectures by basing the design process on the
architecture’s quality attribute requirements.
● In ADD, architectural design follows a recursive
decomposition process where at each state in the
decomposition architectural tactics and patterns are
chosen to satisfy a set of quality attribute scenarios .
● The architecture designed using the ADD method
represents the high-level design choices documented as
containers for functionality and interactions among the
Attribute-driven Design
1. Choose the module to decompose. The module to start with is usually the whole system. All required inputs for this module should be available (constraints,
functional requirements, quality requirements)

2. Refine the modules according to these steps:

a. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this
decomposition.

b. Choose an architectural style/pattern that satisfies the drivers. Create (or select) the style/pattern based on the tactics that can be used to achieve the drivers.
Identify child modules required to implement the tactics.

c. Instantiate modules and allocate functionality from use cases, and represent the results using multiple views.

d. Define interfaces of the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in
the interface document of each module.

e. Verify and refine the use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten
and prepares the child modules for further decomposition or implementation.

3. Repeat the steps 2 and 3 for every module that needs further decomposition.
Architectural Views

● Software architecture is about components, connectors

and connections.
● An important goal is to correctly identify the essential
components of the system under consideration.
● Once the components are correctly identified, the next aim
is to identify how different components (subparts) gel with
each other, how they communicate, what are the
dependability and what are the connections. When the
subparts and the dependencies are put together, we
should have successfully assembled the required system
Architectural Viewpoints
● When a software system needs to be developed, there are
many external components (people, other software
systems, other hardware systems, etc) that have to
interface with the system under study (SUT).
● Different stakeholders have different interests in the
system, and so their perspectives of viewing the same
system are different.
● The stakeholders’ requirements may overlap or may be
different from each other.
● This “stakeholder” influence on architecture makes it clear
that there can be different perspectives of viewing the
● Different authors have proposed a different set of
architectural views as the most suitable ones. The most
popular among them is the “4+1” view model proposed
by Phillipe Kruchten. The four main views according to this
model are:
● (1) Logical View (Module View)
● (2) Process View
● (3) Deployment View
● (4) Physical View
● Logical View (Module View)
● The logical view is concerned about the output(s) of the
system and how it will affect the end users. For this
purpose the logical view attempts to defragment the
system into a set of modules or abstractions. This
decomposition serves two purposes; it enables functional
analysis, and it also helps in identification of common
mechanisms and design elements that are common
across the system.
● Development View (Allocation View)
● This view describes the static organization of the software
in its development environment. It deals with modules,
work allocation, costs and planning. It also involves
monitoring of project progress, software reuse, and
security.

● Physical View (Deployment View):

● This view describes the mapping(s) of the software onto
 Exercise/TD
● What are those indicators that could show that your
software has a good architecture?
● Explain the following concepts as used in SA
● (I) Functionality Based Architectural Design.
● (II) Attribute-driven Design
● What are them major differences between:
● (i) Monolithic Architecture and Micro-service
Architecture.
 Answers to Exercise/TD
● What are those indicators that could show that your
software has a good architecture?
● A good architecture:
● (I) Adopts Functionality Based Architectural Design
approach
● (II) Adopts Attribute-driven Design approach
● (III) Minimizes coupling between modules
● (iv) Maximizes cohesion of each modules
Exercise/TD 1
● (A) You have been recruited newly as a Senior DevOps Software Architect of a large Software Firm.
The Enterprise software architecture design of this firm was a Monolithic Architecture. You are tasked
with improving the operational processes of this firm by enhancing the existing software.
● List five (5) drawbacks that the organization might be facing by using a monolithic software
architecture.
● Propose to the management of this firm five (5) advantages a Microservice architecture will
bring to the organization.
● Assuming your proposal of a Microservice architecture has been accepted by the
management and you are now faced with the task of building of a Microservice architecture.
What are your expectations?
● Hints:
● - Choose any open source application of your choice.
● - Identify sub components and their corresponding communication gateways, explain the
concept of attribute driven-design, state architectural drivers for the system with concrete
reasons, explain the principles of good Architectural Design Process.
 Software Architecture Styles

● How can we archived a goal-oriented/purpose driven

architecture for an IS?
A SOA for Fire Disaster Management
A layered Architecture for LMS
 What is a Software Architecture Style?
● An architectural style defines:
● the components of the software system
● how the components use each other’s functionality and data
● How control is managed between the components
● - An architectural style describes how Software
elements/components interconnect together in order to share
data.
● a family of systems or a class of architectures in terms of a pattern of
structural organization
● Architectural style seeks to establish the following:
● (1) Which kind of components and connectors are used?
● (2) How is data communicated through the system?
Software Architectural Styles
● Microservice Architecture
● Service-Oriented Architecture
● Layered/Hierarchical Architecture
● Client-Server Architecture
● Model View Controller (MVC)
● Object-Oriented Architecture
● Broker Architecture
● N-Tier Architecture
● 2-Tier Architecture
● Why will project owners wish to incorporate architectural
design in their projects?
● What are the various Software Elements/Components/
or Design Elements that a Project owner needs to include
into his projects?
Microservice Architecture
Objectives:
● Microservice Architecture
● Today’s lecture gives the brief introduction on the evolution on
microservices (monolithic to mircoservice way), concept of
microservice with its benefits and how to define a microservice.
● To understand the model-driven and design-driven approaches for
developing applications of a microservices system.
 Microservice Architecture
● Microservice Architecture is an architectural style for
distributed systems " has sprung up over the last few
years to describe a particular way of designing software
applications as suites of independently deployable
services. While there is no precise definition of this
architectural style, there are certain common
characteristics around organization around business
capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and
data.
● In a monolithic application, functions are woven directly
into the individual components that make up the
application, rather than separated into independent units
of functional logic.
● When a monolithic application is componentized, it's
possible to spread a feature across multiple components.
That means that those components are now tightly
coupled, and that, in turn, limits how well they exploit the
benefits of cloud-native microservices
● These frustrations have led to the microservice
architectural style: building applications as suites of
services. As well as the fact that services are
independently deployable and scalable, each service also
provides a firm module boundary, even allowing for
different services to be written in different programming
languages. They can also be managed by different teams
.
● Is there any difference between a distributed
monolithic architecture and a mircoservice
● This diagram could potentially represent two contrasting
design styles. Some architects, for example, could use
this to illustrate a cloud-native microservices application.
Others, however, would call it a perfect example of the
functional relationships within a distributed monolith. The
difference between these two perspectives lies not in the
component or workflow design, but in how the
components actually map to specific features and the
functional logic behind them.
 Drawbacks of Monolithic Architecture

● Less Scalability
● Less reusability
● Tight coupling between components
● Maintenance cost is high
● Slow deployment
Characteristics of a Microservice Architecture

● (1) Componentization via Services

● One main reason for using services as components
(rather than libraries) is that services are independently
deployable. If you have an application [4] that consists of a
multiple libraries in a single process, a change to any
single component results in having to redeploy the entire
application. But if that application is decomposed into
multiple services, you can expect many single service
changes to only require that service to be redeployed.
That's not an absolute, some changes will change service
● (2) Decentralized Data Management
● Decentralization of data management presents in a
number of different ways.
● As well as decentralizing decisions about conceptual
models, microservices also decentralize data storage
decisions. While monolithic applications prefer a single
logical database for persistant data, enterprises often
prefer a single database across a range of applications -
many of these decisions driven through vendor's
commercial models around licensing. Microservices prefer
letting each service manage its own database, either
different instances of the same database technology, or
Advantages of Microservice Architecture

● Highly Scalable
● Highly maintainable
● Rapid deployment
● Reusability of services
● Fault tolerant in case one service goes down, the other
service keep working.
The Microservice Way
● Speed and safety are the two key aspect of the
microservices.
● These two keys are affected with the every single decision
made about the software.
● The microservices way is about finding the balance
between these two key aspect at scale:

● Speed and Safety at Scale and in Harmony.

● The Microservices Way
● The complexity of the software system increases as it
scales in the form of functional scope, operational
magnitude and change frequency.

● The Speed of Change:

● - The desire of speed is the desire of immediately
releasing the changes in the software into the production
environment.
● - Microservice architecture must be modularized, in order
● The Speed of Change:
● - The desire of speed is the desire of immediately
releasing the changes in the software into the production
environment.

● The Safety of Change:

● - The risk of damage can be minimize by restricting the
rate of change
● to those releases in the production environments. Thus
● The Speed of Change:
● - The desire of speed is the desire of immediately
releasing the changes in the software into the production
environment.

● The Safety of Change:

● - The risk of damage can be minimize by restricting the
rate of change
● to those releases in the production environments. Thus
● At Scale:
● - The software should be build to work when demand
grows beyond the initial expectation .This is know as
building the system at scale.
● - Systems that work at scale don’t break when under
pressure.
● - Built-in mechanisms are incorporated in the systems to
increase capacity in a safe way.
Designing Microservice Architecture and
Establishing Foundations
● A microservice design model consist of five parts: Service,
Solution, Process and Tools, Organization and Culture
● The very first step of a service design process is to
design the process itself.
● Processes and Tools: The behaviour of the system
depends on the process and tools used to build the
microservice system.
● Tools and processes are related to software development,
code deployment, maintenance, and product management
 Service-Oriented Architecture (SOA)
● A service-oriented architecture is an architectural
style/approach (framework) for building systems or
applications that use a set of services over a network. A
service is an implementation of a well-defined piece of
business functionality.
● SOA is an architectural style that supports integration of
business processes as linked services that may be accessed
when needed over a network.
● SOA is a software architectural style or design paradigm
that uses services over a network as the main building
The choice to use an SOA approach in the development of
an architecture depends on several factors including the
architecture’s ultimate ability to meet functional and quality
attribute requirements. Usually, an architecture needs to
satisfy many quality attribute requirements in order to
achieve the organization’s business goals. In almost all
cases, trade-offs have to be made between these
requirements. In some cases, satisfying these requirements
may be easier using an SOA; on others, it may be more
difficult. If an SOA is being considered, several questions
A diagrammatic view of a general
purpose SOA
 Client-Server Architecture
● Client-server architecture is one of the two prevailing models
for network programming, the other being peer-to-peer. Almost
every application that requires some sort of communication
between clients uses one of these two of theses architectures.
Layered Architecture
 Layered Architecture /Hierarchical Architecture
● Organizes the system into a set of layers (or abstract
machines) each of which provide a set of services.
● Organizes the system into layers with related functionality
associated with each layer. A layer provides services to
the layer above it so the lowest-level layers represent core
services that are likely to be used through out the system
Team Presentation/TD
● Project 1: Design and Implementation of a Real Time Embedded System for
the Identification and Retrieval of Missing Documents.
● Project 2: Distributed Service-Oriented Architecture for Fire Disaster
Management
● (A) With respect to your the above TP projects: (In class)
● - Identify the research problem
● - Choose an architectural style with concrete reasons (Start by identifying
design elements/components and their relationship)
● - Produce the first draft of your chosen architectural style

● (B) Explain in details, the following architectural styles:

 TD/Exercises
● You have been asked to conduct a research on two projects given below:
● Project 1: Design and Implementation of a Microservice-oriented System for
the Identification and Retrieval of Missing Documents.
● Project 2: Design and Implementation of a Microservice-oriented System for
Disaster Management
● Project 3: Domain-Driven Microservice Architecture for Educational
Management System
● (a) Identify your research problem for any of the above projects
● (b) Clearly state the requirements for the system
● (c) Identify five architectural drivers for the system
● (d) Describe hierarchical architecture in detail, depicting the architectural
DEPLOYMENT OF MICROSERVICE ARCHITECTURE
 DEPLOYMENT OF MICROSERVICE ARCHITECTURE

● Deployment of microservice architecture to a Private Cloud, Public

Cloud or Data Center.

● N/B: Use any deployment technology of your choice

● Wercker is a Docker based continuous delivery platform
which is used by software developers to build and deploy
their applications and Microservices.
● Using Wercker developers can create Docker containers
on their desktop, automate their build and deploy
processes, testing them on their desktop, and then deploy
them to various cloud platforms like Heroku, AWS and
Rackspace.
● The command-line interface of Wercker is open-sourced.
The business behind Wercker, also called Wercker, was
 Continuous Integration with
Circleci Platform
● CircleCI is a modern platform used for continuous
integration (CI) and continuous delivery (CD) i.e. CI/CD
platform. The CircleCI Enterprise solution is installable
inside a private cloud or a data center and is free to try
for a limited time.
● CircleCI automates build, test, and deployment of
software.
● CircleCI can also be configured to deploy code to various
environments like AWS CodeDeploy, AWS EC2 Container
Service (ECS), AWS S3, Google Container Engine (GKE),
Figure 5.20 below depicts the code for circle.yml file.
Figure 5.21 shows the CircleCI dashboard for the application
Architectural evaluation.
● According to the software architectural design, software
quality attributes will be evaluated, the students in their
various groups performs software architecture design
evaluation activities.
● Source code analysis: Source code will be analyzed of the
selected project at the module level, students will
exchange their group work and API and other relating
systems will be verified for proper integration with respect
to the software architectural design.