Software Architecture
for Conference Management Portal
Group-36
Ankur Goel,
Chandrakanth Reddy,
Rajesh Chowdary,
Shivangi Singh,
Ranjeet Singh
Conference Management Portal
(CMP) - Introduction
To handle conferences, which are held very frequently.
A customizable portal which can be configured to
manage:
Information dissemination,
Registration,
Paper submission,
Parts on demand.
Architectural Drivers
Scalability : As it might be used by various number of
users, from across the globe.
Security : As it includes financial transactions and also
because of the confidentiality of a particular user’s
papers.
Modularity : Since web components should be
configurable and customizable.
Reliability : The rate of failure should be very small
and any changes by the user should be immediately
reflected.
Assumptions
Assumptions:
All conferences have almost the same mode of
functioning.
All components required are web based.
All users trust PayPal, as a platform for financial
transaction.
The project has a scope of further development.
Constraints
Constraints:
Compatibility of different components on various
browsers
[End-use environment].
Adhering to different bank protocols during financial
transactions
[Interface/protocol requirements].
Any financial transaction should take place in a fixed
duration of time – 3 minutes
[Performance requirements].
Other non-technical constraints like budget.
Architectural Strategies
Object Oriented paradigm for programming.
As it would enable data encapsulation, abstraction etc.
[Software interface paradigm]
Modularity
An external backup database.
In order to deal with database crashes (if any). Data
copied to backup at random intervals of time.
[Data storage management]
Reliability
Architectural Strategies
Use of third party components like PayPal for financial
transactions.
Enable a secured and trustworthy platform.
Tested and trusted by users.
[Reuse of existing software components]
Security + Reliability
Maintain two servers to handle user’s requests
Increases scalability factor of the portal.
[Concurrency]
Scalability
Architectural Strategies
Hybrid Style of design architecture
3-Tier architecture.
Provides modular software with well defined interfaces.
Any of the three tiers can be upgraded or replaced
independently.
More scalable and maintainable style of architecture.
Representational State Transfer (REST)
Used in the application layer of the 3-tier architecture.
Enables increased scalability.
Independent deployment of components
Intermediary components reduce latency and enforce
CONCEPTUAL VIEW
Presentation Tier (HTML/CSS/Javascript)
Registration Third
Party
User Authentication Clients
Information Dissemination Financial Transactions PayPal
Paper Submission
Admin
Reports
Admin E-mail Updates
Paper Reviews Reports
Review
E-Mail Updates Mail
Database Controller
Client
Application Tier (PHP)
Data Tier (MySQL)
LOGICAL VIEW
User Interface
User Paper
Registration HTTP
Authentication Submission PayPal
HTTP HTTPS HTTPS
HTTPS
Information HTTPS Financial FTP
HTTP
Dissemination Transactions MAIL
Reports SMTP
Admin E-mail Updates
Review
Database Controller
Database Backup Database
Component Responsibilities
Presentation Tier:
Topmost level of the application.
Displays information related to services provided by the
portal (like conference details, paper submission etc.).
Communicates with other tiers by outputting results to the
application tier.
Application Tier:
Controls the application’s functionality by performing
detailed processing.
Data Tier:
Consists of database servers.
Information is stored and retrieved.
Design Principles
Decomposition Conference
Management
Portal
All the
requirements/tasks of User Module Admin Module
the portal have been
decomposed into sub- Authentication Updates
components/modules
like Information
Dissemination
Reviews
Registration
Information Financial
Transaction
E-Mails
Dissemination
Paper Submission etc. Paper
Submission
Design Principles
Information Hiding
Any data manipulated or required by any particular
module is completely hidden from other modules.
Only the module’s output is communicated to other
modules.
Also since, we’d be using Object Oriented paradigm of
programming, it would enable us with inbuilt
Information Hiding capability at the Data-Structure
level.
Design Principles
Modularity
The architecture includes modules or components
which do independent tasks, for example:
User Module
[Registration, Authentication, Information Dissemination,
Financial Transaction, Paper Submission].
Does tasks pertaining to user requirements.
Admin Module
[Admin, e-mails, Reviews, Reports].
Does tasks pertaining to administrative hold.
Design Principles
Cohesion
Components belonging to one layer are cohesively related.
High Cohesion.
For example the User Module has the following types of cohesion
Communication Cohesion
All modules need to communicate with one another, regarding user
information
Sequential Cohesion
The modules are executed in a sequence
Registration -> User Authentication -> Information Dissemination ->
Financial Transaction -> Paper Submission
In case of Admin Module
Procedural Cohesion
e-mails for updates as well as reviews
Design Principles
Coupling
Coupling should ideally be zero
Both the proposed modules hardly have anything to do with
each other.
But practically it is unavoidable, like in this case:
Common Coupling
Both the modules use the user submitted paper and other such
user related information from a global source (DB).
Low Coupling.
Architectural Styles (Not Suitable)
Pipes and Filters
Turns system less interactive.
Not desirable as we expect the system to be more interactive.
Lead to batch organization of processing.
Would decrease the overall performance.
Difficult to maintain synchronization.
Would make handling two concurrently running servers (an
architectural strategy proposed earlier) difficult.
Architectural Styles (Not Suitable)
Event-Based, Implicit Invocation
Order of events processed is unknown.
Will create confusion, as there are multiple sequences of event
invocation.
Reasoning about correctness becomes difficult, because
context of invocation has a major role to play.
Reliability and security are one of our prior architectural
drivers, hence cannot compromise.
Difficult to trace without debugging tools.
Will make development process too cumbersome.
NOTE: Time and budget constraint.
Architectural Styles (Suitable)
Model-View-Controller
Allows independent development and maintenance of
presentation and application.
Project workload gets reduced.
Supports multiple views.
Portal’s interface can be changed for every conference without
disturbing the application and data controller parts.
Accommodates change.
Since the project is assumed to be developed further, this
architecture would enable, incorporation of future modules
easier.
References:
http://en.wikipedia.org/wiki/Multitier_architecture
http://en.wikipedia.org/wiki/Representational_State_Tr
ansfer
Solutions of Case Study – 02.
THANK YOU
