GYM MANAGEMENT SYSTEM - Google Groups

GYM MANAGEMENT SYSTEM

(DESIGN DOCUMENT)

Phase # 2 GYM MANAGEMENT SYSTEM – Design Document

GMSDesignDocument.Version1.0.doc

GYM MANAGEMENT SYSTEM

DESIGN DOCUMENT

DOCUMENT SENSITIVITY: HIGH

VERSION 1.0

Dated: 12/05/2011

Team Member: Alpha Software Group Feng (Frank) Sun - 208150484

Kim Fung Lai - 206773543

Chao Jiang - 206364053

Rahul Kamtam - 211838422

Prepared for:

System Analysis and Design, Marin Litoiu, York University



Version: 1.0

Print Date: 12/5/2011 8:54 AM

Release Date: Open

Release State: Final

Approval State: Approved

Approved by: Open Martin Litoiu

Prepared by: Alpha software group

Reviewed by: Open

Path Name: Hard copy

File Name: GMSDesignDocument.Version1.0.doc

Document No: Phase2.Design document



Document Change Control

Document Sign-Off

Name (Position) Signature Date

Alpha Team 12-06-2011

YMCA 12-06-2011

YORK GYM Representative 12-06-2011

Marin Litoiu 12-06-2011

Version Date Authors Summary of Changes

Version 1 12-04-2011 Alpha Team Fine tuning

Version 2 12-02-2011 Alpha Team UML, Architecture



Contents

1 Introduction……………………………………………………………..5

1.1 Overview…………………………………………………….…5

1.2 Resources – References………………………………………..8

2 Major Design Decisions…………………………………………………8

3 Architecture……………………………………………………………...12

4 Detailed Class Diagrams………………………………………………..16

4.1 UML Class Diagrams………………………………………….16

4.2 Method Details………………………………………………...38

5 Open Issues……………………………………………………………...40

6 Domain Dictionary (optional)…………………………………………41

6.1 Terms and Abbreviations……………………………………..41



1. Introduction

1.1 Overview Resources - Reference

This section will include references to technologies that will be applying to the system design. e.g. Multi Tier Architecture, MVC.

Major Design Decisions

This section will examine significant design goals, which include (1) User Friendliness in which our system will target on ease of use for beginners in technology; (2) High Performance in which our system should target on concurrency, response time and throughput; (3) Low Cost for Clients in which the system-to-be will minimize cost for development, maintenance and administration; and (4) Easy Maintenance for developers in which the system will achieve flexibility, component reusability , testability, adaptability, modifiability, understandability, portability, and good documentation . This section will also examine design criteria. E.g. Coupling, Cohesion. Furthermore, we will discuss how the system will achieve all these goals and criteria.

Architecture This section will discuss subsystem diagrams, deployment diagrams, nested

Diagrams, explanations on the functionality of each subsystem, and comments on the architecture style that will be applying to the new system. This section will also explain what the design goals are and how the goals will be achieved. Subsystem diagrams show the structural relationships between the components of a system. Components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Deployment diagrams will depict a static view of the run-time configuration of Processing nodes and the components that run on those nodes. In other word, deployment diagrams will show hardware of the system-to-be, software that runs on the system, and middleware used to connect disparate machines to one another. The diagrams will explain functionality of each subsystem and comment which specific architecture style the system-to-be will adopt.



Detailed Class Diagrams

UML Class Diagrams

This section will detail class diagram for each subsystem. This section separates the class diagram per module that appears in presentation, application, and data logic. It will expand the class diagram from analysis phase by adding new classes and relationships. Detailed database diagrams will also be included to explain how the entity classes and relationships are mapped into tables. This section will also indicate the design pattern the system to-be will adopt. (e.g.Facade, MVC) This section will use Object Constraint Language to constrain the diagram. This section will define the subsystem interfaces and class APIs at the detail level that Allows developers to represent method details in the next section.

Method Details

Two sequence diagrams will be provided for two use cases that capture the business essence. It will include method details such as signature, parameters and return values. The methods should have pre and post condition in class diagram.

State diagram will be provided for one class in the above use cases.

Open Issues This section will include open or unresolved issues on the system to-be if any.

Domain Dictionary Terms and Abbreviations

This section will list terms and abbreviations in Domain Dictionary. It will also Make reference to URL, book, and website to help readers better understand The terms.



1.2 Resources References

Reference 1: http://www.agilemodeling.com/artifacts/deploymentDiagram.htm Reference 2: http://www.enode.com/x/markup/tutorial/mvc.html Reference 3: http://java.sun.com/blueprints/patterns/MVC-detailed.html Reference4: http://stackoverflow.com/questions/2675980/mvc-pros-and-cons-in-terms-of-web- application-development

Reference 5: http://channukambalyal.tripod.com/NTierArchitecture.pdf

Reference 6: http://www.tutorialspoint.com/uml/uml_deployment_diagram.htm Reference 7: http://www.agilemodeling.com/artifacts/deploymentDiagram.htm Reference 8: http://www.barringer1.com/mil_files/MIL-HDBK-470A.pdf Reference9: http://www.google.ca/url?sa=t&rct=j&q=system%20design%20goals%20cost&source=web&cd=4&ved=0CDsQFjAD&url=http%3A%2F%2Fembedded.eecs.berkeley.edu%2Fasves%2Fembedded%2Fplatform_based%2Fpapers%2Ficcd99.doc&ei=q2bRTqzTF6jn0QGY3Ji8Dw&usg=AFQjCNEvwvCxCr8PfT5QLO9VfBNiITTrJA&sig2=iw6rqUvYsVtWkIxyScD1PA

Reference10: 10: http://www.google.ca/url?sa=t&rct=j&q=system%20response%20time%20and%20user%20satisfaction%3Aan%20experimental%20study%20of%20browser-based%20applications&source=web&cd=1&ved=0CCEQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.99.2770%26rep%3Drep1%26type%3Dpdf&ei=Eo7STpfKF-Lq0gGJ_YjNBg&usg=AFQjCNGkHvmtlhtDObUQjtmqGPYjllAaLA&sig2=b3Jia5USoZYZNY_Qjrczpw&cad=rja

Reference 11: http://c2.com/cgi/wiki?CouplingAndCohesion

2. Major Design Decisions

Design Goals should target to address the following four aspects:

1. User Friendliness Our system should support multiple types of users. (e.g. Anonymous User, Registered User, Clerk) When developing non-enterprise information systems, a single view system that depends on a single model would be adequate. “Although the system cannot prevent business logic and data from interacting with User Interface, such an approach is inadequate when applied to enterprise systems that need to support multiple types of systems.” (Reference 3) In our system design, we will need to implement different views that depend on a single model, and thus, to address different needs from different users. “Different applications need to be developed, one to support each type of client interface.” (Reference 3)

2. Easy Maintenance for Developers The system to-be is an enterprise system. Therefore, component reusability is extremely important. To achieve component reusability, we need to build a system that allows developers to reuse already built components if needed. Furthermore, the system has to be maintainable in a way that “the relative ease and economy of time and resources” (Reference 8) can be achieved. In addition, the system needs to be testable. “Testability, an important subset of maintainability, is a design characteristic that allows the status (operable, inoperable or degraded) of an item to be determined, and faults within the item to



be isolated in a timely and efficient manner.” (Reference 8) In order to shorten the time and mitigate resources spent in development cycles, the system has to be tested and verified before pushing to the market. “Not doing so leads to greater costs in the development of manufacturing and field tests” (Reference 8) the system has to be adaptable such that it will be able to adapt itself fast enough to the changed circumstances. In addition, the system has to be portable to achieve a proper way for system recovery in case of server downtime. Hardware and software components should be portable from one environment to another. System has to be modifiable such that new technologies can be adopted and integrated into the system with no problem. Also, as the system continues to grow, new classes and components should be easily added onto the existing system. At last, codes have to be readable and well documented in order to minimize efforts and resourced put in development cycles.

3. Low Cost for Clients The cost for development, maintenance, and administration has to be low in order for the project to be feasible economically. The system has to achieve ease of learning, ease of remembering, upgrade, maintenance and administration to minimize costs in resources and time spent. The overall design goal is to balance production costs with development time and cost in view of performance. Minimizing the cost for development life cycle is not easy. It is mainly associated with the cost for testing and the degree of component reuse. We will address how the system is to achieve this design goal in the next section.

4. High Performance Since hardware speed and data communication bandwidth have significantly increased over the past decade, issues of response time, throughput, memory and concurrency in system design are not as noticeable as before. In our system-to-be, however, performance is an important part that will receive a relatively large allocation of time and resources due to the fact that the system will provide real-time service for end users. The system-to-be has to aim at minimizing customer frustration by supporting concurrency, reducing response time, and maximizing throughput. As stated by Hoxmeier, “Lowered user satisfaction is significant because it may lead to discontinued use of an application or force the user to find alternative sources of information, especially in discretionary applications such as those found on the Internet.” (Reference 10) As Hoxmeir concluded in his research, “as the response time increased between each group, so did the "ease of reading characters on the screen”, “clearness in sequence of screens”, and “learning to operate the system”.” (Reference 10)

Design Criteria:

On the other hand, design criteria should achieve low coupling and high cohesion as much as possible. The system-to-be will need to achieve the goal that a failure in one subsystem does not affect the other so that failures can be easily isolated; and the change in one subsystem does not cause undesirable affects on the other subsystem. Thus the time and resources for development can be cut down. The system-to-be has to be built in a way such that understandability is easily achieved. In the coming section, we will discuss how the system is going to achieve all these goals

How we achieve all the goals and criteria discussed above:

● User Friendliness To achieve the goal of user friendliness, we need a system that supports multiple types of users. (E.g. Anonymous User, Registered User, Clerk) We need our presentation logic separated from business logic and controller to make developing, deploying, and testing different views easier. As explained in our class diagram for presentation logic, different applications are developed to support different types



of users. (e.g. usersUI to support End Users; equipmentsUI and ordersUI to support Clerk) Data is passed to controller and then model. Then views get updated accordingly after Business Logic is successfully applied. By applying to this MVC design architecture, we separate business logic from presentation and controller logic. “Such an approach allows multiple views “to share the same enterprise data model, which makes supporting multiple clients easier to implement, test, and maintain.” (Reference 3). Also, new views or controllers do not have to exist in the interface with the model and do not enforce any change in the model. In addition, referring to our deployment diagram, we have web browser component that represents client-side and JSP that represents server-side. JSP and controller Servlets are separated from EJB model and rmi to EJB model whenever requests are passed from web browser. Multiple views and controllers can interact with the same model, and therefore, new views and controllers can be easily developed and integrated into our enterprise system. Lastly, in our system, if the user changes data in one view, all other views of data will get updated automatically. For instance, if the user successfully makes a reservation, view for facility (facilitiesUI) will get updated and reflect the real-time inventory list for clerks to review.

● Easy Maintenance for Developers To achieve the goal of easy maintenance, we have to address a few different aspects including component reusability, maintainability, testability, adaptability, portability, modifiability, good documentation and understandability. Since presentation logic is more likely to be changed, we separate this logic from Business Logic. For example, the layout for End Users could be adjusted and new calendar views could be used or new check out system could be deployed for the use by Clerks. To address this requirement, we separate presentation from business logic and decompose presentation into smaller components. For instance, referring to our class diagram, if we will want to create a new view for another type of end user, we can simply reuse usersUI (presentation) and users (controller) subsystem and make some little modification. If business logic on End Users has to be changed, we can just work this change on the users’ model subsystem. This separation not only enables component reusability, but it also enables maintainability and testability. By separating this different logic, the model can be tested independently of the presentation. Note that in our class diagram and deployment diagram, views and controllers depend on model, but not the other way around. This is one major advantages of MVC architecture that allows model to be built and tested independently. In addition, the system-to-be has to be adaptable. In the system design, new subsystems and classes can be easily added or extended in case of changing circumstances. Since model can support as many presentation and controller as possible, we can easily expand the system in order to adapt the new business requirements. In our deployment diagram, in case of new business requirements, we can simply just add new subsystems or classed onto the Web Server without making change to Application Server. As for portability, the system is portable in a way that in case any emergency, application server and database server can be portable from Unix Red Hat to HP-UX. Since MVC model enables separation of business and presentation logic, such change is not a problem. Lastly, good documentation and understandability can be achieved through the use of MVC because components are frequently reused. Similar to Java API, the more you use it, the more understandability you achieve towards it. Moreover, by applying closed architecture to our system where layers can access only operations from the immediate layer below, we further consolidate the contribution to maintainability and flexibility. As in our class diagram, presentation layer can access operations from controller layer, and controller layer can access operations from domain and as such.

● Low Cost for Clients The system is to achieve this goal by applying component reusability and testability. “As the complexity of the products under design increases, the development efforts increase exponentially. Hence to keep these efforts in check a design methodology that favors re-use and early error detection is essential.” (Reference 9) Adaptability is another factor that plays the role for Development Cost. If a system is adaptable enough to integrate new classes, subsystems into the system, it will cut down resources and time spent in system integration testing, and thus, minimizes development costs for clients. As explained by our deployment diagram, the system is flexible enough to add as many



controllers and views as possible without making change to the model. Such an approach can reduce costs for not only testing, but also documentation, and ramp-up times for developers. According to some research, “the consequences of poor testability are higher manufacturing costs, higher support costs, and lower customer satisfaction”. (Reference 8) Besides that, thanks to separation, parallel development is made possible. Therefore, development time is significantly shortened.

● High Performance The design goal of high performance is mainly achieved by using multiple views and controllers and running them concurrently for requests from different users. Referring to class diagram, response time is shortening by letting multiple views and controller interact with the single model concurrently. According to our deployment diagram, Web Server which consists of view and controller is separated from Application Server which consists of EJB model. With this separation, we can add as many views and controllers as possible and let them interact with the single model concurrently. Such an approach reduces times and efforts spent in waiting for response from controllers to views. On the other hand, throughput can be maximized through concurrency control and by delivering different messages among model, views and controllers simultaneously. According to Hoxmeier, “lengthy system response times may cause lower satisfaction and poor productivity among users and lowered user satisfaction may lead to discontinued use of an application”. (Reference 10)

Low Coupling and High Cohesion:

In order to achieve low coupling and high cohesion in the system-to-be, we will reduce dependencies between subsystems in our system and foster similarities among classes inside subsystems. To achieve this, we introduced in our class diagram a FrontController between subsystems in presentation logic and controller logic. With this approach, if we will need to change subsystems in the bottom (controller), we will not have to change subsystems in the top (presentation). To achieve high cohesion, we introduced functional cohesion in which classes share the same operation in subsystems, and logical cohesion in which “elements perform similar activities as selected from outside module”. (Reference 11) In class diagram, equipmentsCtrl subsystem has two classes (InventoryControl and EquipmentMgrControl) that do exactly the same operations. Meanwhile, we also introduced logical cohesion in our class diagram in which “elements perform similar activities as selected from outside module”. (Reference 11) For example, in usersUI subsystem in presentation logic, different classes are invoked according to the user type. If an anonymous user wants to register, RegistrationForm class will be invoked. If a regular user wants to log in, LoginForm class will be invoked. “Body of function is one huge if-else/switch on operation flag”. (Reference 11) Such approach for high cohesion allows us the ability to document works in a structured way, and thus, enables good documentation. Also, it contributes to understandability and readability for developers because APIs can be widely shared.



3. Architecture

3.1 Subsystem (component) diagram



Presentation

1. UsersUI: this contains boundary classes for user related interface.

2. EquipmentsUI: this contains boundary classes for equipment related interface.

3. FacilitiesUI: this contains boundary classes that represent interface for facilities.

4. ReservationsUI: this contains boundary classes for reservation user interface

5. OrdersUI: this contains boundary classes for order related interface

6. ReportsUI: this contains boundary classes that create report user interface.

Control

1. usersCtrl: this subsystem contains controller classes for usersUI subsystem and users subsystem in domain.

2. equipmentsCtrl: this subsystem contains controller classes for equipmentsUI subsystem and equipment subsystem in domain.

3. facilitesCtrl: this subsystem contains controller classes for facilitiesCtrl subsystem and facilities subsystem in domain.

4. reportsCtrl: this subsystem contains controller classes for reportsCtrl subsystem and reports subsystem in domain.

5. reservationCtrl: this subsystem contains controller classes for reservationCtrl subsystem and reservation subsystem in domain.

6. ordersCtrl: this subsystem contains controller classes for orderCtrl subsystem and orders in domain.

Domain

1. users: this subsystem contains user model classes that process all user related business logic

2. equipment: this subsystem contains equipment model classes that process all equipment related business logic

3. facilities: this subsystem contains facilities model classes that process all facility related business logic

4. reports: this subsystem contains reports model classes that process all report related business logic

5. reservations: this subsystem contains reservation model classes that process all reservation related business logic

6. orders this subsystem contains order model classes that process all order related business logic.



DAO

1. usersDao: this subsystem contains abstract interface and data access classes for accessing user, group, member and employee tables in database.

2. equipmentsDao: this subsystem contains abstract interface and data access classes for accessing equipmenttype, equipment, rentalInventory and retailinventory tables in database.

3. facilitesDao: this subsystem contains abstract interface and data access classes for accessing facilityType and facility tables in database.

4. ReservationsDao: this subsystem contains abstract interface classes and data access classes for accessing schedule table in database.

5. OrdresDao: this subsystem contains abstract interface and data access classes for accessing order, orderItem, payment, creditcard, debitcard and paypal tables in database.

Entity

1. users: this subsystem contains entity classes for users domain.

2. Equipments: this subsystem contains entity classes for equipment domain.

3. Facilities: this subsystem contains entity classes for facilities domain

4. Reservations: this subsystem contains entity classes for reservation domain

5. Orders: this subsystem contains entity classes for order domain.



3.2 Deployment Diagrams



4. Detailed Class Diagram

4.1 UML Class Diagrams -Detailed class diagrams for each subsystem. You can separate the class diagrams per module they appear in (presentation, application logic, data manipulation). Make sure you expand the class diagram from the Analysis phase by adding new classes, relationships.



4.1.1 Presentation Layer

<<userUI>> Design Classes

<<EquipmentUI>> Design Classes

<<FacilityUI>> Design Classes

<<ReservationUI>> Design Classes

<<OrderUI>> Design Classes

<<ReportUI>> Design Classes



4.1.2 Control Layer

Overview Front Controller pattern is used in the controller layer. FrontController provides a centralized entry point for handling requests. It handles all tasks that are common to the application, such as session handling, input filtering. Based on the specific request it would then call other servlet to handle the particular task required

<<userCtrl>> Design Classes

<<Equipment>> Design Classes



<<FacilityCtrl>> Design Classes

<<ReservationCtrl>> Design Classes

<<OrderCtrl>> Design Classes

<<ReportCtrl>> Design Classes

3.1.3 Business Logic Layer

Overview Facade pattern is implemented in the domain layer. It provides a simplified interface to the classes within a subsystem and reduces dependencies of outside subsystem on the inner classes within the subsystem.



<<users>> Domain Design Classes



<<equipments>> Domain Design Classes



<<facilities>> Domain Design Classes



<<reservations>> Domain Design Classes



<<orders>> Domain Design Classes



<<reports>> Domain Design Classes



4.1.4 Entity Classes <<users>> Entity Classes



<<equipment>> Entity Classes

<<facility>> Entity Classes



<<reservation>> Entity Classes



<<order>> Entity Classes



4.1.5 Data Access Layer

Overview Factory Pattern is implemented in data access layer. Factory pattern defines an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.

<<usersDao>> Design Classes



<<equipmentsDao>> Design Classes



<<facilitiesDao>> Design Classes



<<reservationsDao>> Design Classes



<<ordersDao>> Design Classes



4.2 Database diagrams

4.2.1 Detailed ER diagram

-Detailed database diagrams should also be included. Make sure you explain how you mapped the entity classes and the relationships into tables



4.2.1 Entity classes and Database tables mapping

Database Table Entity Class

users User

group Group

member Member

employee Employee

FacilityType FacilityType

Facility Facility

EquipmentType EquipmentType

Equipment Equipment

RetailInventory RetailInventory

RentalInventory RentalInventory

Schedule Schedule

Order Order

OrderItem OrderItem

Payment Payment

CreditCard CreditCard

DebitCard DebitCard

Paypal Paypal



4.2.3 Relationship mapping from class diagram to E.R diagram

The multiplicity of the association in class diagram is mapped to the cardinality of the relationship in ER diagram.

Multiplicity of association Cardinality of relationship Mapping

1:1 One-to-One User - Employee User - Member Order - Payment Payment - DebitCard Payment - CreditCard Payment - Paypal

1:* One-to-Many Group - User FacilityType - Facility EquipmentType - Equipment

1: 1..* One-to-Many Order - OrderItem



4.3 Method Details

4.3.1 Login use case sequence Diagram



4.3.2 Reserve a facility use case



4.3.3 State Diagram

For Login Use Case, User Entity class, we enclose one state machine diagram.



5. Open Issues

The following are the known issues of the system-to-be:

a. Increased complexity by applying MVC. As new levels of indirections are introduced, the system becomes more difficult to understand, and thus, increases learning curve. However, in the long run, in will contribute to achieve the goal of maintainability and flexibility.

b. Although views and model are decoupled in the system-to-be, views cannot avoid updates when model change its business logic. Sometime, views can be flooded by updates or even run behind update requests.

c. Knowledge on multiple technologies is required. d. Access control is more complex.

6. Domain Dictionary ( optional)

6.1 Terms and Abbreviations

Term Definition

FrontController Pattern The Front Controller Pattern is a software design pattern listed in several pattern catalogs. The pattern relates to the design of web applications. It "provides a centralized entry point for handling requests."

Reference http://en.wikipedia.org/wiki/Front_Controller_pattern

Facade Pattern The facade pattern is a software engineering design pattern commonly used with Object-oriented programming. A facade is an object that provides a simplified interface to a larger body of code, such as a class library.

Reference http://en.wikipedia.org/wiki/Facade_pattern

Factory Pattern The factory method pattern is an object-oriented design pattern to implement the concept of factories. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created.

Reference http://en.wikipedia.org/wiki/Factory_pattern

GYM MANAGEMENT SYSTEM - Google Groups

Documents

Transcript of GYM MANAGEMENT SYSTEM - Google Groups