In this paper, we describe the software architecture for system which supports non traditional form of assessment named e-portfolio. The architecture model is described through three views: use case view, logical view and implementation view. Based on these three views software system was designed and developed. Some implementation issues are discussed

Aleksieva-Petrova, Adelina

Petrov, Milen

English

Research at Sofia University

Three view model of e-portfolio assessment system   Milen Petrov, Adelina Aleksieva-Petrova  Sofia University, Sofia, Bulgaria email: milenp@fmi.uni-sofia.bg, adelina@fmi.uni-sofia.bg    Abstract In this paper, we describe the software architecture for system which supports non traditional form of assessment named e-portfolio. The architecture model is described through three views: use case view, logical view and im-plementation view. Based on these three views software system was designed and developed. Some implementation issues are discussed. Keywords Use case view, logical view, implementation view, assess-ment model, e-portfolio, eclipse RCP, java  INTRODUCTION Some new forms of assessment, various from ex-isting traditional forms, as examinations and tests emerge with the development in the area of hu-man abilities evaluation. These new forms have showed that they are only helpful to estimate the competences of the given human, because they affect aspects, which more sharply as well fully encompass the human competence. For example assessment of e-portfolio, 360 degrees feedback, peers assessment and so on.  The present work shows one of the new non-traditional forms of assessment (e-portfolio) which can be gained with software instrumentali-ties as well to be integrated in the entire process of assessment. The integration must cross as well with the existing standards and specifications as IMS [1].  There are many definition of e-portfolio and one of them is that an electronic portfolio is collection of electronic evidence assembled and managed by user, usually on the Web. E-portfolios are both demonstrations of the user's abilities and plat-forms for self-expression. [2]  According to IMS definition the assessment ePortfolios are used to demonstrate achievement to some authority by relating evidence within the ePortfolio to performance standards defined by that authority [3].  Therefore the main goal of the paper is to de-scribe software architecture of the system which support assessment e-portfolio and have to dem-onstrate user’s abilities, interests and achieve-ments in a certain area through relating evidence.  The additional focus of current paper is software architecture description of model by following different viewpoints:  • Use case view: shows the main process as use cases.  These use cases typifies the primary use cases that will be implemented and thus shows the most important process of the sys-tem.  • Logical view: gives the high-level system view from a user’s viewpoint, by providing descriptions, pictures and diagrams of the functionality. • Implementation view: shows the system’s main components from a developer’s point of view, by providing descriptions of frame-works and descriptions of significant classes. USE CASES VIEW OF THE SYSTEM  In fig. 1 is showed all activities of the user and what he or she has to do when makes assessment of portfolio with designed software tools.   Figure 1. Use cases of the process of e-portfolio. The main user is portfolio assessor who has access to the candidate’s portfolio. According the selected portfolio the system support performed assessment or export the portfolio. The use case “Perform assessment” includes the process of given score to each assessment item which is corresponded to the user’s abilities and interests.   LOGICAL VIEW OF THE SYSTEM The logical view in the architecture of the model shows system from stand of its users. It holds fig-ures that illustrate function of the system.  The Perform Assessment Use Case and Browse Portfolio Use Case are used to create an analysis class diagram, and to show the concepts using boundary classes (the user interface), controller classes (business logic) and entity classes (data storage).  The resulting diagram can be seen as a translation from user concepts to system con-cepts.   The analysis class diagram for representation on business-logic, made is on Fig. 2, showed of the base of the main use cases for the system, as well that demonstrates the basic concepts. This dia-gram gives a conceptual overview of the system’s parts and is consequently helpful to both devel-opers and software architects. The analysis classes give conception view on the parts of the system and help for understanding its architec-ture.  Figure 2. Analysis class diagram of the functionality of the system.   The main activity of the user of the system is as-sessment of portfolio. It is developed with As-sessment GUI and Portfolio GUI. Under those two directions there is control logic (Assessment Logic and Portfolio Logic) and logic to manage of system and activities (System Control). On the other hand main classes (Assessment Model and Portfolio) corresponding for persistency data.      Figure 3. Package diagram of the system’s functionality  On fig.3 is showed a package diagram of the sys-tem. The main aim of that diagram is to describe all functionality of the application according the logical group. Package diagrams organize ele-ments of a system into related groups to minimize dependencies between packages. The main pack-ages are: assessment model, package represented GUI and business logic of the system.  The other package holds Eclipse environment for development of the graphic interface (wizards, views and editors) and API for SWT and JFace.  IMPLEMENTATION VIEW OF THE SYSTEM The application is disposed in the form of several packages [4]. In each of them there are classes with defined functionality.  On figure 4 is presented package structure of the main package. These packages contain implementation of model evaluation in the form of Java classes and the names and structure of these classes are as de-fined in the XML schedule file copies of the model.  Figure 4. Package structure of the application  There are both classes that are part of the busi-ness logic of the application, and purely technical classes environment (framework) of the Eclipse RCP. Such a purely technical classes are: • Activator (extends AbstractUIPlugin) – Ec-lipse plug-in has such class in the package which connect project with the environment of the Eclipse. It sets the context of the appli-cation as plug-in in the Eclipse environment, and provides methods hook, which may rede-fine the application to have access to specific events and resources of this environment. Typical methods are those who call upon loading and unloading of software in plug-in from the Eclipse environment. • Application – the java class which controls the life cycle of the application. There is simi-lar function of this of Activator but it only guarantee access to different type resources, such in terms of the overall project as feasible implementation. • The following three classes: ApplicationAc-tionBarAdvisor, ApplicationWorkbenchAdvi-sor and ApplicationWorkbenchWindowAdvi-sor, are used for access to the resources and event of workbench in Eclipse. These classes are conducted to manage different parts of this environment, like events, contextual me-nus, toolbars and others. Classes, part of the pattern of application, are grouped in three different directions:  • Comprehensive data models of the system – it is implemented through class Model, which represents the model part of the logical organ-ization of the system using the template de-sign Model-View-Controller.  • Model Portfolio - implemented through classes PortfolioSection and PortfolioSubsection. They set the structure of the portfolio as arranged set of files. The class PortfolioDAO, which represents the realiza-tion of Java template design DAO, is used to extract portfolio database.  • Model of state of assessment - the different conditions in which the application passes in run-time by the user. It represents the realiza-tion of design templates State and Observer. It includes classes PerformAssessmentSession, ISessionListener and enumeration type Ses-sionState.  CONCLUSIONS, LIMITATIONS AND BENEFITS On base of these three views the system is de-signed and implemented. In fig. 5 is shown the screenshot of the system.    Figure 5: A screenshot from the proof-of-concept assess-ment player tool  The system has capability to import and parse xml file which is constructed according assess-ment specification.  It offers to user to perform assessment activities and assigned to user role. After assessment activities is performed – it of-fers to the user to store results also in format, which is compliant to the assessment specifica-tion. This tool also can load already performed assessment activities, and to preview or to eva-luate results from the activities, performed in previous assessment run. The evaluation of the system is carried out with the black box testing on the basis of preparation of specific examples of evaluation (a copy of a XML format) and gamble in the system. There are numerous unit tests itself to copy the model for evaluation. Estimates for the system were satisfactory. There is much that could be developed, but overall it provides the necessary functionality to carry out the evaluation, which is based on the model of TENCompetence Assessment Model. In the process of developing the system it were made following key activities: • Research and analysis of problem areas • Defining the requirements of the system - cer-tain portion of outstanding service and func-tional requirements of the system. • Create a copy of the model evaluation - De-tailed analysis of the model and clarification of its components and concepts enshrined in it. It was development XML scheme which presents copies of the model. The items in this scheme satisfy the concept of model evaluation, together with elements for model-ing activities, roles and additional input for the evaluation. It was created a module for developing and storing copies of the model. It includes the scheme itself, the source code generated by the scheme through JAXB tech-nology, unit tests of the instance. • Choice of technology for development – It was selected Eclipse RCP, as a target plat-form for development and JAXB technology for automatic code generation. MySQL was choosing as a supporting database.  • Design, development and testing of the sys-tem – It was identified and developed indi-vidual components of the system topic on the architecture of Eclipse plugins for software and the necessary testing to ensure fairness of the system.  As conclusion we can say that developed tool(s) is based only on one type of non-traditional as-sessment, and conclusions therefore can be li-mited, nevertheless current research is very im-portant step of assessment model and specifica-tion validation activities. Future work will in-clude more widely adoption of other different me-thods of non-traditional assessment approaches. ACKNOWLEDGMENTS The work reported in this paper is partially sup-ported by the SISTER project, funded by the Eu-ropean Commission in FP7-SP4 Capacities via agreement no.: 205030. REFERENCES [1] IMS Global Learning Consortium, IMS Ques-tion & Test Interoperability Specification, 2006 [2] Hebert, Elizabeth A., The Power of Portfolios - What children can teach us about Learning and Assessment, San Francisco: Jossey-Bass, 2001 [3] IMS Global Learning Consortium, IMS ePort-folio Specification [4] Borovska P., M. Lazarova, Methodology for Parallel Application Development, Vth International Conference “Challenges in Higher Education and Research in the 21st Century”, Sozopol, Bulgaria, 5-9 June, 2007  

Three view model of e-portfolio assessment system

https://research.uni-sofia.bg/bitstream/10506/98/1/Petrov_eProtfolioAssessmentSystem_final.pdf

Three view model of e-portfolio assessment system

Abstract

Similar works

Full text

Available Versions

Research at Sofia University