The course builder architecture & project planning presented by: Bahareh Agha Jafari

Project Plan Making most general project architecture 1. Divide the big component between the local groups, under that they can divide the tasks by themselves, at end each local group can be responsible for testing the other local group work 2. Two group work together - divide different task between different people in group, in The way that we have specific group being responsible for some special task, some people for designing some people for coding … Benefits: -making communication easy for each local group drawbacks: -possibility of incompatibility between the local members abilities and tasks Benefits: -dividing the task between people base on their abilities, gets more advantage drawbacks: -possibility of miscommunication

Project Steps Requirement definition by whole group Use Case defining by whole group Designing mostly complete project which we have in mind to implement base on the design patterns by design group Mark the more general requirement for the system which we want to implement Managing the project in the eliterate way: planning to implement the most general task in project first, test it then go to the next requirements and implement other requirements, we can have 3 steps to do whole project.

The most general architecture GUI Course Builder Classes Postgre SQL IIS As web server Communication C# Data Base AJAX ASP.NET dll C# The general architecture based on the Façade pattern

The course builder architecture The idea is to divide the pieces into layers. At top is the GUI, which in this case is the ASP.NET pages. At the second layer is the application and to communicate between layer 1 and 2 there is an interface – usually called the FAÇADE. At the third and the bottom layer is the database. GUI Business Logic By this approach the business logic is separated from the GUI in a component style. Also there is the possibility to let the database be decoupled from the application in the same style and by that freely pick what ever database that is suitable for the moment or use one at a separate location.

How it works: The GUI (ASP.NET pages) are defined independent of the business logic such as all communication to that layer goes by the interface (FAÇADE) in form of system calls. The FAÇADE represents the system of business logic in a way that is totally independent of the GUI. By that the definition of components are fulfilled. Such as both the GUI and the business logic can be refined, changed, written in any language or run on different machines/platforms. The GUI can be replaced by any else GUI and the business logic can be changed to any else kind of internal architecture as long as it does what is defined by the interface.

Course builder architecture parts: GUI: The GUI should by being represented by ASP.NET, only consist of a visual dialog with the user and have none so ever business logic by its own. Only system calls is to be done from the “code behind” and of course it should also be dynamic by scripts, asp-web-components and so on. FAÇADE: This is an interface in its pure form. It hides the system from the user (GUI) and just provides services. This by implementation means that it wraps the system. Business logic: This should be designed by some or several patterns. It provides the FAÇADE with system calls. The business logic it self should be designed by singleton pattern manner so that only one instance per session are to be created. The logic it self should be defined by some suitable pattern that is found from the use-case analysis and it could consists of internal components as well. But a general (implementation) approach it is typically a bunch of classes compiled down to a.dll Database: In the simplest form it could be a static solution that is hard implemented in the business logic. That is good enough in an initially state but it would also be good to use some kind of design to make it extendable and independent. Could be by use of abstract layers to retrieve dynamic choice of database, and / or use of web services to use databases at other locations.