Lessons learnt from developing and changing an educational three tier system 8/17/2001 10:01 AM -1/3- OOPSLA 2001 Workshop on The Three Tier Architecture Pattern Language POSITION PAPER Lessons learnt from developing and changing an educational three tier system Letizia Jaccheri, Tor Stålhane, Marco Torchiano {letizia,stalhane,marco}@idi.ntnu.no Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim Norway Submitted to OOPSLA 2001 Workshop on The Three Tier Architecture Pattern Language Abstract In the context of a software architecture course, we have collected experience and findings related to the architectural assessment and change of a small three tier system. In this paper, we present those findings, which may be of interest to persons working in the software pattern field. 1 The eCourse system The educational project was centered on a three tier based system, called eCourse. eCourse enables its users to share documents and other information on the three tier. eCourse has been designed and implemented using the Rational Unified Process, Rational Rose, Enterprise Java Beans, and XML. eCourse provides support for document exchange, and was developed before the start of the course. Documents describing requirements, architecture, design, source code, and tests were made available to the students. eCourse is a relative small system (100 classes and 6000 lines of Java code). The students view the system eCourse from both user and developer perspective. Students use the system to access documentation distributed by the teacher, to share documentations, and to deliver project results. As developers, students assess, design, and implement changes to improve the architecture with respect to quality attributes (maintenance, performance, usability). Different groups are assigned to different quality attributes. The goals of the project were [4]: make the students acquainted with methods concerning architecture evaluation and change, software design styles and patterns, and domain specific architecture. At the same time, we want students to experiment with architecture issues, e.g., evaluate and choose alternative designs for the same system, apply patterns, and above all experience the difficulty of changing software rather than build it from scratch. The original system uses the following design patterns: Model-View-Controller (MVC), Front Component, Façade, Data Access Object, and Value Object. 2 Lessons learnt Patterns were one of the driving concepts when the system was built. The system was build mainly following the guideline provided by Sun [7]. 2.1 Model-View-Controller The MVC pattern is a way of breaking an application, or a piece of an application's interface, down into three parts: model, view, and controller. The model represents an abstraction of the data, the view takes care of the presentation, while the controller handles the input and performs updates when required. In eCourse the MVC pattern has been slightly changed compared to its original version (see Figure 2). The model does not notify views when it changes the state. This is due to the asymmetric structure of the HTTP protocol.