systems architecture use case diagram, system overview, class diagram design patterns (weve used)...

17

Upload: chloe-schmitt

Post on 26-Mar-2015

225 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents
Page 2: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

System’s ArchitectureUse Case Diagram, System Overview, Class

Diagram Design Patterns (we’ve used) Refactorings (we’ve used)

Table of Contents

Page 3: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

Use Case Diagram

Page 4: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

System Overview

Page 5: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

Class Diagram

Page 6: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

Design Patterns used in WsepForum Façade

Adapter

Factory Method

Singleton

Proxy

Page 7: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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.

Page 8: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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 design-pattern for this purpose was the Adapter design-pattern.

Page 9: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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.

Page 10: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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 application-wide. Given that, the Singleton DP was a reasonable choice.

Page 11: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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.

Page 12: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

Refactorings used in WsepForum

Extract Class

Renaming

Extract Method

Pull up method

Page 13: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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();}

}

Page 14: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

Renaming: Throughout the development of the project class names, variable names, etc, were refined and adjusted to better describe the program elements.

Page 15: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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; }}

Page 16: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents

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) { …… } … }

Page 17: Systems Architecture Use Case Diagram, System Overview, Class Diagram Design Patterns (weve used) Refactorings (weve used) Table of Contents