Architectural Representation
This document details the architecture using the views defined in the “4+1” model [KRU41] which are applicable for World Village project. For the names of views RUP naming convention is used. Here is the list of views used to document the World Village Project.
Use Case view
Audience: whole project team and stakeholders
Area: describes the set of use cases that represent some significant, central functionality of the system
Related Artifacts: Use-Case document
Logical view
Audience: designers
Area: defines overall candidate architecture, describes the most important use-case realizations.
Related Artifacts: design model
Implementation view
Audience: programmers
Area: software components: describes the layers and subsystems of the application.
Related Artifacts: implementation model, software components
Deployment view
Audience: deployment managers
Area: describes the mapping of the software onto the hardware
Related Artifacts: deployment model
Architectural Goals and Constraints
This section describes the software requirements and objectives that have some significant impact on the architecture.
Technical Platform
The World Village project will be deployed onto a J2EE application server and MySql server for database. We will use following programming language tools and data bases:
Struts 2, JSP, AJAX, HTML, and CSS Presentation layer
Hibernate Data access layer
MySql Data base layer
Security
World Village system must protect information and data, so that unauthorized users or systems cannot read or modify them. For logging in to the website, users need to register first then system will check authentication with username and password whenever users want to log in. It must be handles that all the user information is highly secure as possible.
Usability
The World Village system features should be considered in a way to be easy to use. Users just need to log in, and use website features. Website will also contain user manual to help users. The language of site should be international because the users are from different countries.
Availability
The World Village website must be up and running 24/7/365 and it must be available when accessed by diverse browsers.
Accessibility
The World Village website must be easy to access by as many users as possible.
Capacity
System will give limited space to users for upload their files (movies, sounds, pictures, workshop materials and so on). System will not have limited number for online users.
Suitability
The suitability for World Village system is the capability to provide an appropriate set of functions for specified system goals and user needs.
Scalability
The World Village website should provide enough scalability to deal with thousands or millions of activities performing at the same time by several users. It must be prepared to grow quickly both in terms of number of users serviced and in terms of functions offered.
Operability
The system should have capability to enable the users to operate and control it. The website should not place undue burdens on users, for example, requiring special browser versions.
Fault tolerance
The World Village system should be fault tolerant to maintain a specified level of performance in cases of happening faults and do not let the crash of whole system.
Recoverability
To support the recoverability the World Village system should be able to re-establish a specified level of performance and recover the data directly affected in the case of a failure.
Changeability
The changeability for World Village system is the capability to enable a specified modification to be implemented.
Stability
The World Village system design should provide the maintainability that is the capability of a product to be modified, and to avoid unexpected effects from modifications.Modifications may include corrections, improvements, or adaptation of the website to changes in requirements and functional specifications.
Use-Case View
For World village project three groups of users are defined:
Casual user (any user surfing the internet)
Registered user (registered member of the system)
Administrator (administrator of the system)
In the use case diagrams below some more roles can be appeared according to different scenarios, but the system will know only about the main three roles.
The diagram below shows interconnections between different sets of features of the system. Lines indicate that one subset of features users another
