Transcript Koah_Hamachaz - Wsepforum - ac-bgu-wsep092

Table of Contents

System’s Architecture
 Use
Case Diagram, System Overview, Class
Diagram
Design Patterns (we’ve used)
 Refactorings (we’ve used)

Use Case Diagram
System Overview
Class Diagram
Design Patterns used in WsepForum

Façade

Adapter

Factory Method

Singleton

Proxy
Facade Design Pattern
The Forum System is composed of several modules. A need for a single point of
management was needed to control all modules. The Façade design-pattern
was used in order to supply a higher-level interface (SessionFacade) to a set of
modules (Logger,ForumSystem…) that makes them easier to use.
Adapter Design Pattern
At first, the forum used a search engine that was developed by our team and used
a specific interface. Later on, the team was required to use an external search
engine called Compass. Now we were supposed to stay with the original
interface and adapt it to the new implementation. The most suitable designpattern for this purpose was the Adapter design-pattern.
Factory Method Design Pattern
The core domain classes (post, forum, member, etc) contain public Factory
Methods instead of public constructors. The reason is that their creation is not
merely instantiating a new object. Primarily, there are two cases where we
need to create core objects - when the object is new to the system, and when
the object represents an entity that was already persisted to the database.
Therefore, each such core class has two methods - createNew() and
fetchBy...(). Secondly, creating a fresh object means also creating a database
record for it, and fetching an object from the database means issuing an SQL
query and constructing a new object from it.
Given the extra-work needed to create new objects, we chose to use Factory
Methods.
Singleton Design Pattern
The DBAuthority and IDAuthority are Singletons.
For IDAuthority, the motivation is that there should be only one entity in charge of
assigning unique identification strings. Otherwise, two entities might assign the
same ID to some object. In fact, we chose UUID as identification strings so even if
two "authorities" assigned IDs, they would not assign identical IDs.
For DBAuthority, the motivation is that all objects that need to, connect to the same
database. Letting each object individually decide how to connect to the database
and which database to connect to results in duplicated code and inconsistencies.
Also, the mechanism to connect to the database should be available applicationwide. Given that, the Singleton DP was a reasonable choice.
Proxy Design Pattern
The Proxy design-pattern was used to control access to the Facade remotely. The
"problem" was that the client cannot hold a real facade object since the facade
objects are created in the server process and are tied to other objects in the server's
memory space. The solution was to create a remote-proxy in the client and a stub in
the server process. The two interact over a protocol we defined (over TCP) and the
stub passes the requests to the real facade in the server process.
The remote proxy, as well as the façade itself, implements the SessionFaçade
interface.
Refactorings used in WsepForum

Extract Class

Renaming

Extract Method

Pull up method
Extract Class: At first, almost each class in the domain layer contained a
field which held the next ID that will be given to a new instance. This
functionality could be done by a new class so it was extracted into a new
class called IDAuthority that gave each domain layer class a unique ID.
Before:
Class Member {
private static int nextID = 1;
private int ID;
…
public Member() {
this.ID = nextID++;
}
…
}
After:
public class IDAuthority {
private IDAuthority() { }
public static synchronized String newID() {
UUID id = UUID.randomUUID();
return id.toString();
}
}
Renaming: Throughout the development of the project class names,
variable names, etc, were refined and adjusted to better describe the
program elements.
Extract Method: Some class methods contained the same code pieces. This code
duplication was handled by extracting the same code pieces into one method.
Before:
public class ShowStatButton {
…
public void onClick (Map pageData) {
…
String [] ymd = s.split("/");
int year = Integer.parseInt(ymd[0]);
int month = Integer.parseInt(ymd[1]) - 1;
int date = Integer.parseInt(ymd[2]);
Calendar calendar = Calendar.getInstance();
calendar.set(year, month, date);
Date ans = calendar.getTime();
…
}}
After:
public class ShowStatButton {
public void onClick (Map pageData) {
…
Date ans = stringToDate(someRelevantString);
…
}
private Date stringToDate(String s){
String [] ymd = s.split("/");
int year = Integer.parseInt(ymd[0]);
int month = Integer.parseInt(ymd[1]) - 1;
int date = Integer.parseInt(ymd[2]);
Calendar calendar = Calendar.getInstance();
calendar.set(year, month, date);
Date ans = calendar.getTime();
return ans; }}
Pull Up Method: Methods that were used by several siblings of the same hierarchy
were moved to the superclass (“pulled up” the hierarchy).
Before:
public class PostView extends WSEPPage {
…
String getURLParameters(String param) { …… }
String getForumID() {
return getURLParameters(“fid”);
}
…
}
After:
public class WSEPPage {
…
String getURLParameters(String param) { …… }
…
}