the course builder architecture project planning presented by n.
Skip this Video
Loading SlideShow in 5 Seconds..
The course builder architecture & project planning presented by: PowerPoint Presentation
Download Presentation
The course builder architecture & project planning presented by:

Loading in 2 Seconds...

play fullscreen
1 / 7
Download Presentation

The course builder architecture & project planning presented by: - PowerPoint PPT Presentation

Download Presentation

The course builder architecture & project planning presented by:

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

  2. Making most general project architecture Project Plan 2. Two group work together- divide different task betweendifferent 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 … 1. Divide the big componentbetween the local groups,under that they can divide the tasks by themselves,at end each local group can be responsible for testingthe other local group work Benefits:-making communication easy for each local groupdrawbacks:-possibility of incompatibilitybetween the local members abilities and tasks Benefits:-dividing the task between peoplebase on their abilities, gets more advantage drawbacks:-possibility of miscommunication

  3. 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.

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

  5. GUI Business Logic 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. • 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.

  6. 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.

  7. 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.