0% found this document useful (0 votes)
17 views92 pages

Cours 1

Uploaded by

jordan.feujio
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views92 pages

Cours 1

Uploaded by

jordan.feujio
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 92

● 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 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
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. If you want to
update your friend in Bamenda on when you'll be reaching the destination, your estimates will
vary wildly based on your current situation.
Without a long-term plan, your trip will be devastating unlike a well planned trip.
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
● Both are distributed data systems with different architectures
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
● Software architecture has equally evolved overtime.
- 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:


● E.g. using a DBMS such as SQL, Postgres, Ingres, Sybase or Oracle
● Consistency checking is located with the 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?
●Does everybody on the team have the necessary amount of
technical
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

●Separation of Concerns: The main advantage of architectural-


based development is the architectural separation of concerns,
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.

● Inadequate requirements will lead to a vague solution


● Vague problem ---------->> vague solution
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 existing ●What is the problem?

system to identify the problem ●what happens in the current


areas. system?
●It is a process of
●Have you understood domain
understanding the system analysis
requirements and its
environment. ●what is required in the new

system?
●It involves gathering and

understanding the user’s ●Results (Outcome of Analysis

requirements. phase):SRSD
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 to satisfy the specified requirements. It
involves the design of the system architecture, components,
modules, interfaces, and data
● 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 Design Document (SDD)
-An architectural design to provide solution to the identified

problem
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.
● Scalability -----
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
As a researcher, a good understanding of your research

problem will lead to a well-structured research questions.


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
decomposition or reverse engineering by decomposing the system
into its main components based on functional requirements and
●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.
- These questions must always come in mind:
At a glance, can all the use’s requirements be met?
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
●Attribute-Driven Design (ADD) is a software

architecture design approach that focuses on quality


attributes, also known as non-functional requirements.
It ensures systems meet performance, scalability,
security, usability, and other quality goals.

●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


Key Principles of ADD:
1. Identify quality attributes: Determine critical quality
attributes (e.g., responsiveness, availability, security).
2. Define attribute-driven design goals: Establish
specific, measurable targets for each attribute.
3. Architectural decision-making: Make design decisions
based on attribute-driven goals.
4. Trade-off analysis: Balance competing attribute
requirements.

Benefits of ADD
Attribute-driven Design
Example:

Suppose you're designing an e-commerce platform. Key quality attributes might include:

- Performance: 99.9% uptime, <2s response time

- Security: compliance, encryption

- Scalability: Support 10,000 concurrent users

By applying ADD, you'd prioritize design decisions based on these attributes, ensuring your system meets critical quality goals
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 software
architecture of one system. These perspectives have been
traditionally called “architectural views”
The Software Architect has to balance all these different
Architectural Views

● Application View:
● Deployment View:
●This view describes the mapping(s) of the software onto the
hardware and reflects its distributed aspects. It looks into system
requirements like reliability and performance. It maps the various
elements identified in the above three views. These views,
combined with a 5th the view, which is “use cases or scenarios”,
represents the entire architecture.
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.
● (ii) System Analysis and System Design
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

● Explain the following concepts as used in SA


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.
- State the technology to be used for deployment with concrete reasons

- Presents a draft of the microservice architecture.


- With reference to the chosen system, attempt to deduce a mathematical description of your
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 short, the microservice architectural style is an approach to
developing a single application as a suite of small services, each
running in its own process and communicating with
●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 architecture?
●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 interfaces
resulting in some coordination, but the aim of a good microservice
architecture is to minimize these through cohesive 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 entirely
different database systems Decentralized Data Management.
(3) Evolutionary Design
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 to
achieve cohesion of service – dependences bewteen modules are
reduced.
● 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 optimizing
the
● 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 optimizing
the
● 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.

● In Harmony:
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 in the
microservice system.
- Development using a container – Docker
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 component.
●This architectural style describes a collection of distributed
components that provide and/or consume services.
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
need to be asked; for example:

• What effect will the choice of an SOA have on the business


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:


- Service-Oriented Architecture

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


view for the system and hence explain 4 software architectural design
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 founded in
2012 and acquired by Oracle Corporation in 2017.
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), Heroku etc.
●Check the website http://circleci.com and sign up with a new
account for free or login using your GitHub account.
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.

You might also like