=====
CS 328 - Week 1 Lecture "2" - 2025-01-22
=====
TODAY WE WILL:
* introductions/see who's here
* intro CS 328's "big idea"
* a FEW course highlights...
* where to various course resources
* basic course structure
* clickers!
* emergency preparedness note
* intro to n-tier architecture for interactive applications
* prep for next class
====
current reading:
====
* read through the COURSE SYLLABUS (posted from several locations
on both the course Canvas site and the public course web site)
* be prepared to answer Canvas questions about it as part
of Homework 1
* WHEN the first zyBooks assignment link is posted to the course
Canvas site, CLICK on that assignment link to subscribe to the
course zyBooks text!
* (do NOT go to the zyBooks website and create a new account!)
* I will send a class e-mail when the first zyBooks assignment
link is posted
====
software architecture
====
* from Jalote, "A Concise Intro to Software Engineering", p. 95:
software architecture:
"...the subsystems that should compose [a complex software]
system, the interfaces of these subsystems, and the rules for
interaction between the subsystems"
* An n-tier architecture is ONE of several common options for
the software architecture for web applications that involve a
relational DBMS
====
n-tier architectures for interactive applications
====
* leading up to these:
* traditional (even pre-web...!) components of an
interactive application using a database:
1. Presentation component - what the user sees and
interacts with
2. Application component - the business logic; the software
components that implement a scenario's business rules
3. Database component - usually/typically provided by a
DBMS <-- database management system, systems such
as MySQL, Oracle, MongoDB, POSTGRE-SQL, etc.
* 1-tier architecture for such an application:
all of these components are
combined, perhaps without clear separation,
typically "in one place"
* 2-tier architecture for such an application:
classic client-server architecture!
* in general, a client-server architecture has a
client tier and a server tier --
where the server is frequently providing some
service useful to be shared
(a print server, a file server, a database server,
a web server, etc.!)
* a process on the client tier may want and request a service
by sending a request to the server tier
* and a process on the server tier responds to
that request, and performs desired action(s)
as a result
* so: consider a 2-tier, client-server architecture
approach to an interactive application that
happens to use a database...
for classic client-server,
* typically put the presentation components on
the client tier
* typically put the database components -- for example,
a DBMS -- on its own tier, as the server tier
* ...but where do the application components go,
if you use a classic 2-tier client-server architecture
for an interactive application involving a database?
...not as neat and obvious a choice for these!
client server
---------------- ------------------
| presentation | <---> | database |
| components | | components |
---------------- ------------------
^ ^ ^
| | |
application component??
...could be on either tier, could be on both...!
...not as neat and obvious a choice for where these
should go, using a 2-tier/client-server software
architecture;
SO...
* n-tier architecture for an interactive application involving a database,
* or 3-tier, or 3+-tier
* ...came about as a possible improvement!
client tier application tier(s) data tier
---------------- ------------------ ----------------
| presentation | <---> | application | <---> | database |
| component | | component(s) | | component |
---------------- ------------------ ----------------
* client tier - has the presentation component
* receives user events
* controls the user interface
* application tier(s) - has the application component(s)
* application logic/business rules reside here
* (so might software components that monage that logic
and manage the interaction between the tiers)
* data tier - has the database component
* your DBMS is here
* over time and experience, the actual software architecture
might not be QUITE so neat/clear-cut;
* might be security or performance or other reasons that
SOME application logic might still creep onto the
client tier,
or that SOME application logic might still creep onto
the data tier,
as we'll discuss as the semester proceeds.