0% found this document useful (0 votes)
28 views64 pages

Welcome and Intro To SW Architecture

Uploaded by

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

Welcome and Intro To SW Architecture

Uploaded by

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

Introduction to

Software
Architecture
CSPC 464 Fall 2022
Prof. Son Nguyen
Welcome
 Roll Call

 Introduction
◦ Instructor
◦ Students

 Syllabus

 Introduction to SW Architecture (Chapter 1)


 Process of Architecting (Chapter 2)

 Coming Next

 Q&A
About myself…
 Been working in the computer industry since 1980 – for several
companies including Shared Medical Systems, NCR, Hughes Aircraft,
TRW/Northrop, Digital/Compaq/HP, TrendMicro, Raytheon
◦ OS/SW Developer, Computer/Sales Support Consultant, Technical Marketing
Manager, Principal SW/Systems Engineer, SW Engineering Manager/team
leadership

◦ Involved in several large SW development projects, DoD C2/C4I


architecture/design for DoD and NATO projects, IT management, SW
benchmarking/testing, systems/software engineering management, etc.

 Been teaching part-time for several years at CSUF


◦ focus on software engineering courses (undergraduate and graduate) - SW
Architecture, SW Testing, SW Maintenance, Ethics, SW Advanced Process,
Modern SW Management, System/Software Standards and Requirements

 My intention in teaching this course is to share my industry


working experience and to make it more practical using real-world
application, rather than academic study in SW architecture
About you…
 Assignment: Introduce Yourself to Your Classmates and
Professor by Friday Sep 02, 5PM

 Have you heard of software architecture?

 Is anyone having working experience with


software architecture?

 What are you hoping to gain/your


expectations from this course?

4
The Text Book
The Class Portal
References
1. Software Architecture for Developers,
Simon Brown
2. An Introduction to Software
Architecture, David Garlan and Mary
Shaw
3. Software Architecture, A. Bijlsma, B.J.
Heerendr., E.E. Roubtovair, S. Stuurman
4. Software Architecture in Practice, Len
Bass, Paul Clements, Rick Kazman

7
Inspiration
Course Description and
Objectives
 This course provides an introduction to basic
principles and practices of software design and
architecture

 It will cover high-level design, software architecture,


documenting software architecture, software
architecture evaluation, software product lines, and
some considerations beyond software architecture

 Each student will participate in a group project


intended to aid in the student’s understanding and
retention of the material.
Class Goals
 To guide you through the tasks (defining requirements, creating logical
architecture, etc.) and associated best practices (establish/govern architecture
patterns/standards, simple design, etc.) that are applied in architecting a
software system

 To provide tools and techniques (tool to manage requirements, to create


architecture, scrum methodologies) that can be applied immediately to
today’s challenges

 To create a “toolbox” that can be used for tomorrow’s challenges

 To stimulate thinking about the future of software engineering

 To ensure that we are all better engineers by semester’s end

 To promote individuals & interactions and teamwork

10
The Plan
 See the syllabus – Lecture topics

Syllabus CPSC 464


Fall 2022

11
The Project
 Each student will participate in a team project

 Teams will create a software architecture for a


fictitious but realistic software product

 The project will help


◦ Develop interactions and teamwork skills
◦ Put course material into context and practice
◦ Demonstrate your mastery of materials

12
Motivation
 “Our civilization runs on software” (Bjarne Stroustrup,
C++ programming creator)

 Software touches many aspects of our everyday


lives – found in something simple and in very
complex systems

 Software needs to
◦ Provide the required capacity
◦ Be of sufficient quality
◦ Be available when needed
◦ Get delivered at acceptable price

 These characteristics are directly influenced by the


architecture of the software
13
Software Engineer – one of the
best jobs in America?
 Below are the 10 best jobs* in America
for 2021 from Glassdoor’s survey, with
their annual median base salary.
*These jobs are ranked based on salary, a job satisfaction
score on a scale of one to five, and number of job openings
on Glassdoor’s platform.
1. Java Developer: $90,830 10,103 Job Openings 4.2/5
2. Data Scientist: $113,736 5, 971 Job Openings 4.1/5
3. Product Manager : $121,107 14,515 Job Openings 3.9/5
4. Enterprise Architect: $131,361 10,069 Job Openings 4.0/5
5. DevOps Engineer: $110,003 6,904 Job Openings 4.0/5
6. Information Security Engineer: $110,000 5,621 Job Openings 4.0/5
7. Business Development Manager: $82,182 8,827 Job Openings 4.1/5
8. Mobile Engineer: $94,301 4,631 Job Openings 4.1/5
9. Software Engineer: $110,245 40,564 Job Openings 3.8/5
10. Dentist: $134,122 4,315 Job Openings 4.0/5

Source: https://www.glassdoor.com/List/Best-Jobs-in-America-
14
LST_KQ0,20.htm
What is Architecture?
 The word “architecture” means many different things to
many different people and there are many different
definitions floating around:
◦ Systems, subsystems, interactions and interfaces
◦ Design with the bigger picture in mind
◦ The blueprint
◦ The skeleton/backbone of the product

 What is your definition?

 As a noun, architecture is about the complex or


carefully designed structure of something

 As a verb, architecture is about


◦ understanding what you need to build,
◦ creating a vision for building it
◦ making the appropriate design decisions.
15
Core Concepts

Activities of
defining,
documenting
,
maintaining,
improving,
and
certifying
proper
implementati
on of an
architecture
(IEEE
1471.2000)

16
Type of Architecture
 There are many different types of architecture
and architects within the computer industry:
◦ Data, hardware, enterprise, system, security
◦ Software, information, application, etc.

 What do they all in common?


◦ Structure
◦ Vision

 Regardless of whether you’re building a software system,


a network or a database; a successful solution requires:
◦ to understand the problem
◦ create a vision that can be communicated to everybody
involved with the construction of the end-product.

17
What is Software
Architecture
 It’s about more than just the architecture of
a piece of software.

 It’s anything and everything related to the


significant elements of a software system:
◦ from the structure and foundations of the code
◦ through to the successful deployment of that code
into a live environment.

Software Architecture for Developers, Simon Brown

18
Software Architecture
 A combination of
◦ Application architecture:
 aspects of software design and the
organization of the code
 usually only concerned with a
single technology stack – a list of
technologies to provide a SW
solution/application (e.g., LAMP –
Linux, Apache, MySQL, PHP)

 The building blocks include


programming languages and constructs,
libraries, frameworks, APIs, etc.

 It’s described in terms of classes,


components, modules, functions, https://hackernoon.com/

design patterns, etc.

Software Architecture for Developers, Simon Brown


19
Software Architecture
 A combination of
◦ and System
architecture:
 composed of multiple
applications across a
number of different tiers
and technologies

 The building blocks are:


 a mix of software and
hardware,
 Including programming
languages, software frameworks
through to servers and
infrastructure

20
Software Architecture
 Software architecture is also about making
◦ fundamental structural choices
◦ engineering decisions
◦ These are costly to change once implemented

◦ Example – a reservation system has the requirements of being


responsive and reliable.

 Responsiveness – the choice could be made to develop application is


highly distributed with multitier architecture

 To satisfy the need for reliability/availability, the choice could be made


to have redundant system (seamless application failover using Oracle
DB, RAID, redundant network, etc.)
RAID - Redundant Array of Inexpensive Disks

21
Why do we need Software
Architecture?
“Why should we care about software architecture anyway?
Sometimes a developer just wants to jump right in and
start coding. Software architecture is the foundation of a
software system. The foundation has a profound effect on
the quality of what is built on top of it. “Joseph Ingeno

 Applications are becoming larger, more


integrated, and are implemented using a
wide variety of technologies [2]

 The various technologies and disciplines


need to be orchestrated to ensure
product quality.

 Quality attributes like availability, reliability


or usability cannot be analyzed at the code
level, but they can be analyzed at the
software architectural level
22
Software Architect

 Individual responsible for the creation and


rework of a software architecture
throughout the product’s lifecycle

 Software architect does not work alone!


◦ Leads an architecture team
◦ Works with requirements engineers and functional
designers to ensure the orderly transition of
processes, artifacts, and information

23
Software Architect
 Must have
◦ Technology knowledge - Can he/she do without?
◦ Understandings of Software Development Process
◦ Design knowledge and programming skills
◦ Ability to make decisions
 Under pressure
 When not popular
◦ Ability to mediate and negotiate between and
with “stakeholder” groups
◦ Aware of organizational politics

24
Software Architecting
 The activities of defining, documenting, maintaining,
improving, and certifying proper implementation of an
architecture. (IEEE 1471.2000)

 The art and science of defining and reworking software


architectures
◦ A need to provide some level of creativity when dealing with novel and
unprecedented systems

 Is an ongoing, not a one-time activity


◦ Architecting begins with the customer needs – a set of requirements
◦ Architecture is reworked as necessary throughout the product’s
lifecycle
◦ The process of architecting is NOT complete until the system is
delivered
 Architect must be involved until the end of the project
 Architecture participates in the test discipline, ensuring that the
architecture is both testable and tested
25
Need for Software
Architecting
 Need to have a common understanding of
how the product is to be built
◦ As with any complex problem, there is more than
one possible solution
◦ Need to ensure that we are all working on the
same solution

 Need to have a consistent definition of the


product architecture
◦ Single version of the Truth
◦ Prevent confusion and avoidable rework

26
Need for Software Architecting
 Customers expect a high-quality for their
investment

 End-product should:
◦ do what we said it would do
◦ Behave/perform the way our customer expected
◦ be usable for the purpose for which the customer
bought it

 We cannot stay in business (very long)


delivering products that do not meet our
customer’s expectations

27
Review
What is an architecture? Choose the best answer
a) is about the complex or carefully designed structure of something
b) is about understanding what you need to build, creating a vision
for building it and making the appropriate design decisions
c) The design backbone
d) The blue print
e) a and b
What is software architecture?
f) It’s about the architecture of a piece of software
g) It’s anything and everything related to the significant elements of
a software system
h) A combination of application architecture and system architecture
i) IT infrastructure.
j) a, b, and c
Review
 What is the role of the architect? (Choose all that apply)
a) responsible for the creation and rework of a software architecture
throughout the product’s lifecycle
b) Works with requirements engineers and functional designers to
ensure the orderly transition of processes, artifacts, and
information
c) Does not need to have technology/design knowledge.
d) Ability to mediate and negotiate between and with stakeholders

 What is architecting?
a) The activities of defining, documenting, maintaining, improving,
and certifying proper implementation of an architecture
b) Is a one-time activity.
c) Architecting begins with design engineering.
d) The art and science of defining and reworking software
architectures
Review
SW Architecture - Core concepts
Is this correct?

30
Just a few more slides, let’s take a short
break!

https://www.dreamstime.com/illustration/take-break.html
Process of
Architecting
CSPC 464 Fall 2022
Prof. Son Nguyen
Process of Architecting
 Process
◦ Phase
◦ Iteration
◦ Activity

 Method Content
◦ Tasks
◦ Roles
◦ Work Products

 Types of Process
◦ Waterfall
◦ Iterative
◦ Agile
Key Method Concepts
 Use SW and Systems Process Engineering Meta-Model Specification
(SPEM) standard developed by Object Management
Group (OMG), a nonprofit technology standards
consortium.

◦ SPEM standard is influenced by and supports several existing SW


development methods (OpenUP- Unified Process, Rational Unified Process,
IBM Unified Method Framework)

 An effective SW development method should describe who


does what, how, and when
◦ Roles: The Who (architect)
◦ Work products: The What (e.g., Software Architecture Document)
◦ Tasks: The How (e.g., Building architecture proof-of-concept)
◦ Phases, iterations, and activities: The When
Key Method Concepts and Their
Relationship
Process - Phase
 A SW development project
typically moves through
several phases
◦ Traditional Phases:
Requirement, Architecture,
Development (code & unit
test/integration), and Test

◦ OpenUP defines four phases:


Inception, Elaboration, Construction,
Transition
Process – Iteration and Activity
 Each phase is divided into several iterations
 Within each iteration, there are various activities
◦ For example, Creating Logical Architecture (Chapter 8), Creating
Physical Architecture (Chapter 9) are the activities
Method Content - Task
 An activity references a group of tasks
◦ Each task
 has a clear purpose (e.g., document architecture decisions)
 performed by appropriate roles
 produces work product
◦ For example, In activity Creating Logical Architecture (Chapter 8)
consists of a number of tasks: Survey architecture assets, Define
architecture overview, Outline functional elements, etc. performed by
the architect
Task - Example
 Activity: Creating the Logical Architecture
 Task: Survey Architecture Assets
Method Content - Role
 Defines the responsibilities of an individual or a
set of individuals working together as a team

 Responsible for one or more work products and


performs a set of tasks

◦ Requirement Analyst
◦ Project manager
◦ Lead architect
◦ Application architect
◦ Infrastructure architect
◦ Data Architect
Method Content - Work
Product
 A piece of information or
physical entity that is
produced/used during
execution of the process

 The SPEM defines three types:

◦ Artifact: document, model, source


code, executable

◦ Deliverable: content packaged for


delivery to a stakeholder (e.g., a SW build
package)

◦ Outcome: a result or state as the


result of task execution (e.g., an email
notification to customer after an order is
placed/received)
The Process
 A series of actions or steps
taken in order to achieve a
particular result (e.g., architecture)

 Specifically, the application of


the method content (i.e., tasks,
roles, work products, etc.) in terms
of sequence in which they are
applied

 Three types of process:


◦ Waterfall
◦ Iterative
◦ Agile
Polls

 Polls

◦ Poll 1:Are you familiar with the waterfall model?


◦ Poll 2:Have you ever heard of Agile Manifesto?
◦ Poll 3: Have you been practicing/using Scrum
methodology?

44
Waterfall Process
 Each discipline is deemed to be complete when
all the appropriate work products for that
discipline have been created and signed off
 For example, the requirements discipline considered to be
complete when :
◦ all the requirements have been identified in detail, reviewed, and
documented in the system/software requirements spec (SRS)
◦ then the output (e.g., SRS) from requirements flows into the architecture
discipline
Classic Waterfall Model
Phases Work
Products

Requirements SRS

Design SAD

Code & Unit Test .EXE

Integration Prelim
Build
Test (Validation & Verification) Final Build

Release
Deployment d
Product
Hotfixes
Maintenance Patches
Minor
Release

46
Waterfall Process
 This approach is widely used in:
◦ the development of a system involves a relative
small amount of risk
◦ projects represent minor enhancements of an
existing system

 This approach can be problematic for


◦ Greenfield projects where architect starts from a
scratch
◦ Projects are changing extensively
Waterfall Process –Major
Problems
 What are the major problems with waterfall process?
◦ Project progress cannot be measured accurately
 Focus on creation of work products, not achievement of results
 Completing requirements without doing any architecture, development, or testing will
NOT give you an accurate indication of how long project would take
 Projects that follow a waterfall approach are prone to schedule
slippage (ripple effect phenomenon)

◦ User feedback cannot be obtained until late in the project –


when the system is available for use

◦ Resolution of certain risks (e.g., activity identifies flaws in design or


requirements) is deferred until late in the project – after the
system is built, integrated, and tested
Waterfall Process – Major
Problems
◦ Changes are not welcome in the middle of project

◦ Cost - Finding and fixing a software problem after


delivery costs 100 times more than finding and
fixing the problem in early design phases (Boehm
curve)
Iterative Process
 Rational Unified Process (RUP) 2003 - the
granddaddy of all the agile methods

 Iteration:
◦ A short and set duration of a project
◦ Allow to demonstrate incremental value
◦ Obtain early and continuous feedback

 A pass is made through each of disciplines


◦ Size of boxes = relative time spent performing
activities/tasks within discipline

 Each iteration results in


◦ Better understanding of requirements
◦ A more robust architecture
◦ A more experienced development org
◦ A more complete implementation

 More productive and successful


Iterative Process
 Phases – OpenUP defines four sequential phases:
◦ Inception Phase:
 Where the business case and objectives for project is established
 Where the focus is on requirement definitions
◦ Elaboration phase:
 Where the architecture is established
 Where the architect expends the most effort
◦ Construction Phase:
 Where the remaining requirements are clarified
 Where development of the system is completed on the baselined
architecture
◦ Transition Phase:
 Where the system is deployed in user’s environment for
acceptance testing
 Where project should be to close out by the end
Iterative Process
 Phases and iterations together provide foundation for an
iterative development process
 Objectives of each phase are achieved by executing one or
more iterations within the phase
 Each phase concludes with a major milestone and an
assessment
◦ Example: Inception – milestone: System Requirement Review (SRR), Elaboration- milestone:
Critical Design Review (CDR)

 Successful assessment allows the project to move to the next


phase
Waterfall vs. Iterative
 An iterative development
process is result-driven (vs.
work-product driven), providing
more accurate measures of
project progress

 An iterative approach:
◦ Allows early user feedback through
execution of incremental releases

◦ Integration and testing occur within


each iteration and executable
release is produced

◦ Risks are detected early on


Agile Process - Agile Manifesto
 The Four Values of The Agile Manifesto (2009)
Agile Manifesto
 1. Individuals and Interactions Over Processes and Tools
◦ Valuing people more highly than processes or tools
◦ It is the people who respond to business needs and drive the development
process
◦ If the process or the tools drive development, the team is less responsive to
change and less likely to meet customer needs
◦ In the case of individuals, communication is fluid and happens when a need
arises (interactions)
◦ In the case of process, communication is scheduled and requires specific
content

 2. Working Software Over Comprehensive Documentation


◦ The Agile Manifesto values documentation, but it values working software
more.
◦ Historically, enormous amounts of time were spent on documenting the
product for development causing a long delay in product delivery
◦ Agile does not eliminate documentation, but it streamlines it in a form that
gives the developer what is needed to do the work without getting bogged
down in development.
 Agile documents requirements as user stories, which are sufficient for a software
developer to begin the task of building a new function.
https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto
Agile Manifesto
 3. Customer Collaboration Over Contract Negotiation
◦ The Agile Manifesto values customer collaboration more than contract
negotiation
◦ It advocates customer engagement and collaboration throughout the
development process.
 This is to ensure the end-product meets the business needs of the customer
◦ Negotiation is the period when the customer and the product management
work out:
 the requirements for the product, prior to any work starting
 the details of a delivery where they may be renegotiated

 4. Responding to Change Over Following a Plan


◦ Traditional software development regarded change as an expense, so it was to
be avoided. Why?
◦ Plan is usually done prior to starting of the project and quite often not realistic
◦ With Agile, the shortness of an iteration means priorities can be shifted from
iteration to iteration and new features/changes can be added into the next
iteration.
◦ Agile’s view is that changes always improve a project; changes provide
additional value.
Agile Methodologies
 There are over a dozen agile methodologies
 No single right way
 Can be tailored once a team is experienced
 Most common

◦ Scrum
◦ Extreme Programming (XP)
Agile Process - Scrum
 Scrum is one of the framework under the Agile software development
◦ Scrum emphasizes taking a short step of development, inspecting the resulting product Did it
meet expectations?
◦ and the efficacy of current practices How can we work better or make the product better?
◦ and then adapting the product goals and process practices Is this still the most valuable
feature to deliver at this time?
◦ Repeat forever!!!!!

 Scrum focuses on:


◦ Content of an iteration (Sprint)
◦ Prioritized requirements to be considered in iteration (Sprint Backlog)
◦ A Short daily meeting (a Scrum meeting)

 Scrum methodology will be discussed in more detail in the next lecture

Design
Coding
Test
Extreme Programming
(XP)
Characteristics
◦ Focuses on productivity and software quality
◦ Quick releases, with a recommended two-week iteration
◦ Each iteration results in production-ready code
◦ Highly productive, self-organized teams

 XP Core Practices
◦ Small releases – smaller increments mean rapid deployments
◦ Pair programming: two programmers- one enters code, the other ensures that code is
accurate, periodically switch roles
◦ Test-driven Development (TDD) – writes acceptance tests prior to developing code
◦ Customer tests – customer describes test criteria
◦ Continuous integration – check code into a build several times a day
◦ Simple design – adapt as necessary/revisit as needed

 The main difference between Scrum and XP is that XP contains


many practices that are specifically for programming (TDD,
continuous integration, and pair programming)

The End
Summary
 Process of Architecting
◦ Process: Ph…., It…., Act…..
◦ Method Content:
 Work P…..
 Ta….
 Ro…..
◦ Types of Process
 Waterfall
 Iterative
 Phases: In…., Ela…., Cons…., Trans….
 Iterations
 Agile
 Agile Manifesto
 Scrum
Summary
 Agile
 Agile Manifesto – The four values:
1. Individuals and Interactions Over P_______ and T____
2. Working S_______ Over Comprehensive Documentation
3. Customer C___________ Over Contract Negotiation
4. Responding to Change Over Following a P_____

 Agile Methodologies:
◦ Scrum
◦ Extreme Programming
Coming Next…

 Next week (Week 2), we will take a look at


elements of software architecture and
design process

62
Assignments
 Assignment: Introduce Yourself to Your Classmates
and Professor by Friday Sept 02, 5PM

 Homework assignments this week


◦ Review chapter 1 & 2
◦ Read the “4+1” View Model of Software Architecture
paper by Philippe Kruchten
http://www.cs.ubc.ca/~gregor/teaching/papers/4+1vi
ew-architecture.pdf

63
Q&A
 Any questions?

You might also like