Pemakaian Ulang Antarmuka Berbasis
Form: Survey
Oleh
Uung Ungkawa
33212020
Sekolah Teknik Elektro dan Informatika
Institut Teknologi Bandung
1 Pendahuluan
Software reuse (SR) atau pemakaian ulang software adalah proses pembuatan sistem software dari sistem software yang ada ketimbang membuatnya dari awal. Konsep SR pertama kali dicetuskan pada tahun 1968 dalam konferensi NATO oleh Dougles McIlroy. Asalnya
konferensi itu dicanangkan untuk fokus pada Krisis Software (software crisis); yang diartikan sebagai masalah yang dijumpai dalam pengembangan software yang besar dan handal dengan cara yang efektif. Dalam konferensi itu disampaikan suatu laporan cikal bakal SR: Mass Produced Components oleh Dougles McIlroy dari Bell Laboratories. Dia mengusulkan Pustaka komponen Software atau juga disebut sebagai Pustaka Pemakaian Ulang Software yang dapat dipakai berulang-ulang dan teknik otomatis untuk menyesuaikan (customized) komponen sampai pada tingkat ketepatan dan keandalan tertentu. McIlroy merasa bahwa pustaka komponen dapat diterapkan sacara efektif pada komputasi numerik, konversi i/o pengolahan teks dan alokasi penyimpanan (storage) secara dinamik [1].
Umumnya kakas dan sistem yang dikembangkan untuk SR hanya menyediakan bantuan dalam memungut (retrieve) entitas software seperti kelas-kelas, fungsi dan spesifikasi dari repositori (tempat penyimpanan pustaka). Sebenarnya SR juga membutuhkan adaptasi pengetahuan yang didapat untuk sistem yang sedang dikembangkan, yang biasanya dilakukan sepenuhnya oleh disainer karena memang ini pekerjaan yang rumit dan membutuhkan banyak hal untuk dipertimbangkan. Penalaran analogi (analogical reasoning) tampil sebagai teknik yang dapat digunakan untuk mengatasi beberapa masalah adaptasi dari SR, karena hal ini melibatkan alih gagasan dan solusi dari satu bidang ke bidang lainnya. Ini tidak hanya memberikan jalan keluar untuk mendapatkan solusi tetapi juga memberikan peluang untuk membentuk solusi baru dan kadang solusi yang kreatif. Ini juga dapat memberikan gagasan dan pilihan terhadap disainer yang membantu untuk mengeksplorasi ruang solusi dengan cara yang lebih baik [4].
bahasa pemodelan antarmuka atau lebih dikenal sebagai bahasa spesifikasi atau bahasa deskripsi.
2 Software Reuse (SR)
Hampir 20 tahun kemudian setelah ide SR muncul, ilmuwan komputer masih memandang pemakaian ulang software sebagai cara potensial yang ampuh untuk meningkatkan
pelaksanaan rekayasa software. Keuntungan yang makin nyata terhadap usaha pengembangan software melalui pemakaian ulang makin mendapat pengkauan meskipun kakas (tool), metoda, bahasa dan pemahaman menyeluruh terhadap rekayasa software telah banyak berubah sejak 1968. Di samping menjanjikan, SR belum berhasil menjadi standar penerapan dalam pembangunan software. Melihat kegagalan ini, masyarakat ilmuwan komputer telah memperbaharui ketertarikannya terhadap pemahaman bagaimana dan di mana pemakaian ulang bisa efektif dan mengapa terbukti sulit membawa gagasan yang tampak sederhana ini ke ranah teknologi pengembangan software [1].
Krueger [1] melakukan survey tentang SR dari empat dimensi yakni abstraksi, seleksi, spesialisasi dan integrasi. Abstraksi suatu artifak software adalah deskripsi ringkas yang menyampingkan rincian yang kurang penting kepada pengembang software dan menonjolkan informasi yang penting.
Dalam menentukan efektifitas penerapan SR, Krueger mendefinisikan konsep jarak kognisi (cognitive distance) yakni jumlah usaha intelektual yang harus dibayarkan oleh pengembang software untuk membawa sistem software dari satu tahapan pengembangan ke tahapan lainnya. Jarak kognitif ini bukn ukuran formal yang dapat dinyatakan dengan angka dan satuan, tetapi merupakan gagasan informal berdasarkan intuisi berkenaan dengan usaha relatif yang diperlukan untuk melaksanakan berbagai tugas pengembangan software. Bagi yang menerapkan SR, tujuannya adalah untuk meminimalkan jarak kognisi melalui:
1. Menerapkan abstraksi yang tetap dan variabel yang ringkas dan jelas (ekspresif) 2. Memaksimalkan bagian yang tersembunyi dari abstraksi
3. Menggunakan pemetaan otomatis dari abstraksi spesifikasi ke abstraksi realisasi
Meskipun Krueger mengemukakan SR dalam pemulungan disain dan kode program, namun sedikit sekali membicarakan disain. Umumnya programer mengadopsi SR dalam pemulungan disain dan kode dilakukan secara ad hoc, tidak sistematis, meskipun memang efektif. Mereka mendapat fragmen kode dari sistem yang ada dan menggunakannya sebagai bagian dari pengembangan sistem yang baru. Pengembang yang berpengalaman diketahui banyak mendapatkan manfaat dari pemakaian ulang disain. Tujuan dari pemungutan disain dan kode adalah untuk mengurangi usaha kognitif, jumlah tombol yang ditekan dan tentunya jumlah waktu yang diperlukan untuk disain, implmentasi dan debug sistem software yang baru. Pemulung menyalin sebanyak-banyaknya dari sistem yang mirip yang telah didisain, diimplementasikan dan didebug sebelumnya.
2.1 Keuntungan dan Kerugian SR
Kaur dan Goyal [7] mencatat beberapa keuntungan dan kerugian SR. Keuntungannya adalah:
- Meningkatkan Keandalan: SR menyebabkan komponen SR terus diuji lagi dan lagi yang akan mengurangi dijumpainya error dan meningkatkan keandalan komponen, karena makin sering dipakai, makin sering diuji dan peluang dijumpai error lagi akan makin kecil.
- Mengurangi Resiko Proses: Jika software sudah ada, maka sedikit ketidakpastian biaya dalam penggunaan ulang software tersebut ketimbang biaya untuk
pengembangan. Ini merupakan faktor penting dalam manajemen proyek karena mengurangi margin kesalahan dalam estimasi biaya proyek. Terlebih lagi jika software yang dipakai ulang merupakan software besar (sub sistem).
- Pemanfaatan Spesialis yang Efektif: Orang yang berpengalaman atau spesialis efektif dalam pengembangan sistem software. Karena pengalamannya, dia tahu komponen mana yang bisa dipakai lagi.
- Percepatan dalam Pengembangan: SR jelas meningkatkan produktifitas, karena komponen yang sudah dibuat dapat digunakan selagi pengembangan sistem baru. Ini akan mengurangi waktu dan biaya pengembangan.
Sedangkan kerugiannya adalah:
yang reusable, semua aplikasi menyajikan format menu yang sama ke pengguna. Memang, keandalan meningkat karena bagi pengguna akan lebih kecil kemungkinan keliru apabila disajikan menu yang sudah dikenal.
- Perlu Dokumentasi yang Baik: Karena selama pengembangan komponen SR memerlukan dokumentasi penuh, sehingga orang lain yang tidak terlibat mengerti cara kerja komponen dengan lebih mudah. Akan tetapi jika dokumentasi kurang baik, maka akan rumit untuk difahami.
- Membuat dan Memelihara Pustaka Komponen: Membuat dan memelihara pustaka SR menjadi mahal karena pemeliharaan membutuhkan beberapa orang ahli dan juga teknik untuk mengklasifikasi, mengkatalog dan memungut kembali komponen masih belum matang. Demikian pula jika ada pengembang yang kurang berpengalaman maka hasilnya akan terbalik karena kurang mengerti sistem software.
- Mendapatkan, Memahami dan Adaptasi Komponen: Komponen harus ditemukan dalam pustaka, difahami dan kadang disesuaikan (adaptasi) agar bisa jalan di sistem yang baru. Insinyur harus bertanggung jawab menemukan komponen dalam pustaka sebelum melakukan pencarian rutin.
2.2 Proses Software Reuse
Almeida et al [5] melakukan survey berkaitan dengan proses software reuse. Mereka mengidentifikasi 2 proses: domain engineering proses dan product line process. Domain engineering adalah aktifitas mengumpulkan, mengorganisasi dan menyimpan pengalaman masa lalu dalam membangun sistem atau bagian sistem dalam domain tertentu dalam bentuk aset yang dapat dipakai ulang, juga menyediakan perlengkapan yang cukup untuk memakai ulang aset tersebut ketika membangun sistem baru.
Almeida mengemukakan perkembangan penerapan pendekatan SR. Awal 80an dan 90an, beberapa usaha dalam pemakaian ulang berfokus pada domain engineering seperti Draco (Neighbors) [6], yang berbasis pada teknologi transformasi. Gagasan utama yang
diperkenalkan dalam Draco adalah domain analysis, domain specific language dan komponen sebgai sekumpulan transformasi. Usaha Neighbors memberi kontribusi penting dalam bidang domain engineering, memberikan konsep seperti pemrograman generative, sistem
dalam lingkungan industri karena kerumitan untuk melakukan aktifitas seperti membuat transformasi dan menggunakan sistem Draco itu sendiri [5].
Dalam kaitan ini, pada 1992 Software Technology Adaptable, Reliable Systems (STARS) mengembangkan the Conceptual Framework for Reuse Processes (CFRP) sebagai sarana untuk memahami dan menerapkan paradigma rekayasa software berbasis reuse dan domain-specific karya STARS. CFRP membangun framework yang menangani proses rekayasa software berbasis reuse, bagaimana interrelasinya, bagaimana hal itu dipadukan satu sama lain dan juga dengan proses yang bukan berbasis reuse untuk membentuk model proses berorientasi reuse yang dapat disesuaikan dengan kebutuhan organisasi.
Akan tetapi, FRP itu sendiri merupakan framework yang generik dan organisasi yang telah menerapkannya merasakan bahwa CFRP terlalu generik untuk sekadar melayani penyesuaian untuk membangun model siklus hidup rekayasa software berbasis reuse dan domain spesific. Karena itu, dibangunlah ROSE PM dari team Paramax STARS yang secara khusus
menjembatani kesenjangan antara framework yang generik dan high-level dengan metode yang rinci dan prskriptif.
Almeida terus menelusuri perkembangan penerapan SR berbasis domain-engineering dengan berbagai masalah dan solusinya sampai pada ODM (Organization Domain Modelling), RSEB (Reuse-driven Software Engineering Business), FeatuRSEB dan FORM (Featur Oriented Reuse Method).
Selanjutnya menurut Almeida, hingga 1998, proses SR hanya berkaitan dengan masalah domain engineering. Akan tetapi, dalam rentang waktu yang sama, mulailah ditekuni tren baru: bidang software product line (SPL). SPL dipandang sebagai kemajuan yang
menjanjikan dalam pengembangan software yang efisien. Akan tetapi, hingga akhir 90an hanya ada beberapa panduan atau metodologi untuk membangun dan menerapkan product-line yang melampaui pendekatan domain engineering yang ada. Di pihak lain, pendekatan domain engineering tidak terbukti efektif seperti yang diharapkan.
2.3 Faktor Keberhasilan dan Kegagalan SR
2.4 Pendekatan Software Reuse
Software Reuse approach is a way to create software reuse components or artefacts to recur it. Many approaches has been taken into mind while creating software reuse system such as Generator Reuse, Aspect oriented approach, Cots Integration, Framework Integration , Program Libraries , Design Patterns , application product lines , service oriented
{by-substance} {by-technique}
planned, systematic
artifacts, components ad-hoc, opportunistic with-modification, white box
procedures, skills
Bahasa Spesifikasi
aecXML
UsiXML
XIML
Teresa
UMLi
Aplikasi bahasa deskripsi misal dalam pemodelan interaksi
UIDLs Overview
DISL
Dialog and Interface Specification Language (DISL) [Error: Reference source not found] is a user interface markup language (UIML) subset that extends the language in order to enable generic and modality independent dialog descriptions. Modifications to UIML mainly concerned the description of generic widgets and improvements to the behavioral aspects. Generic widgets are introduced in order to separate the presentation from the structure and behavior, i.e., mainly to separate user- and device-specific properties and modalities from a modalityindependent
GIML
The Generalized Interface Markup Language (GIML) is used for the generalized Interface Toolkit (GITK) [Error: Reference source not found]. GIML is used in this context as an interface descriptor.
Following the OMG principles of separation of concerns GIML splits functionality and presentation. While the functionality is preserved in GIML the UI is derived from
XSL files, which come from user and system profiles. This information is merged with the functional descriptions by using XSLT to form a final interface description. The profile data could come directly from a file−system or from a remote profile server. GIML avoids the use of concepts such as "push-button", "scrollbar", whereas GIML uses terms such as "action", "data-entry/value- choice/single/limited". The goal is to use interface patterns in the future. These media neutral identifiers are the foundation for an interface object hierarchy.
ISML
Interface Specification Meta-Language (ISML) [Error: Reference source not found] was developed with the intention that methaphors (shared concepts between the user and the computer) be made explicit in design. ISML de-couples that metaphor model from any particular implementation, and express mappings between the concepts shared between the user and the system. It provides a framework that supports mappings between both user-oriented models (such a task descriptions) and software architecture concerns (interactor definitions). The ISML framework composites these concepts within five layers (devices, components, meta-objects, metaphor, interactors), using a variety of mappings to link them together.
RIML
directives in case pagination needs to be done, in this sense it was possible to specify how to display a sequence of elements of the UI.
SeescoaXML
Software Engineering for Embedded Systems using a Component-Oriented Approach (SeescoaXML) [Error: Reference source not found] consists of a suite of models and a
mechanism to automatically produce different final UIs at runtime for different computing platforms, possibly equipped with different input/output devices offering various modalities (e.g. a joystick). This system is context-sensitive as it is expressed first in a modality-independent way, and then connected to a
specialization for each specific platform. The contextsensitivity of the UI is here focusing on computing platforms variations. An abstract UI is maintained that contains specifications for the different rendering mechanisms (presentation aspects) and their related behavior (dialog aspects). These specifications are written in a XMLcompliant UIDL that is then transformed into platformspecific specifications using XSLT transformations. These specifications are then connected to a high-level description of input/output devices. The entry point of this forward engineering approach is therefore located at the level of Abstract UIs.
SunML
Simple Unified Natural Markup Language (SunML) [Error: Reference source not found] is an XML language to specify concrete user interfaces that can be mapped to different devices (PC, PDA, voice). The innovation of this language is the capacity to specify dynamically components. In SunML it is also possible to encapsulate the style and the content of each widget independent of the others. Two different files are used for that purpose. Another interesting feature offered in SunML is widget
composition. Some operators have been defined for that purpose: union (semantically-common widgets), intersection, subtraction, substitution, inclusion. Widgets Merging Language (WML) is the extension used for that purpose. SunML presents a reduced set of elements that seems to be not enough, but the composition of widgets is used to specify more complex widgets.
TeresaXML
static structure (the presentation model) and dynamic behavior (the dialog model): such abstract specifications are exploited to drive the implementation. This time, the translation from one context of use to another is operated at the highest level: task and concepts. This allows maximal flexibility, to later support multiple variations of the task depending on constraints imposed by the context of use. Here again, the context of use is limited to computing platforms only. The whole process is defined for design time and not for runtime. For instance, there is no embarked model that will be used during the execution of the interactive system, contrarily to the SEESCOA approach [Error: Reference source not found]. At the AUI level, the tool provides designers with some assistance in refining the specifications for the different computing platforms considered. The AUI is described in terms of interactors that are in turn transformed into Concrete Interaction Objects (CIOs) once a specific target has been selected.
UIML
User Interface Markup Language (UIML) [Error: Reference source not found] is an XML-based language that provides: (1) a device-independent method to describe a UI, (2) a modality-independent method to specify a UI. UIML allows describing the appearance, the interaction and the connection of the UI with the application logic. The following concepts underlie UIML:
1. UIML is a meta-language: UIML defines a small set of tags (e.g., used to describe a part of a UI) that are modality-independent, target platform-independent (e.g., PC, phone) and target language-independent (e.g., Java, VoiceXML). The specification of a UI is done through a toolkit vocabulary that specifies a set of classes of parts and properties of the classes. Different groups of people can define different vocabularies: one group might define a vocabulary whose classes have a 1-to-1 correspondence to UI widgets in a particular language (e.g., Java Swing API), whereas another group might define a vocabulary whose classes match abstractions used by a UI designer
2. UIML separates the elements of a UI and identifies: (a) which parts are composing the UI and the presentation style, (b) the content of each part (e.g., text, sounds, images) and binding of content to external resources, (c) the behavior of parts expressed as a set of rules with conditions and actions and (d) the definition of the vocabulary of part classes.
3. UIML groups logically the UI in a tree of UI parts that changes over the lifetime of the interface. During the lifetime of a UI the initial tree of parts may dynamically change shape by adding or deleting parts. UIML provides elements to describe the initial tree structure and to dynamically modify the structure.
UsiXML
USer Interface eXtensible Markup Language (UsiXML) [Error: Reference source not found] is structured according to different levels of abstraction defined by the Cameleon reference framework [Error: Reference source not found]. The framework represents a reference for classifying UIs supporting a target platform and a context of use, and enables to structure the development life cycle into four levels of abstraction: task and concepts, abstract UI (AUI), concrete UI (CUI) and final UI (FUI). Thus, the Task and Concepts level is computational-independent, the AUI level is modality-independent (In the cockpit it can be several physical, Vocal, GUI, Tactile) and the CUI level is toolkitindependent. UsiXML relies on a
transformational approach that progressively moves among levels to the FUI. The transformational methodology of UsiXML allows the modification of the
development steps, thus ensuring various alternatives for the existing sub-steps to be explored and/or expanded with new sub-sub-steps. UsiXML has a unique underlying abstract formalism represented under the form of a graph-based syntax.
WSXL
Web Service eXperience Language (WSXL) [Error: Reference source not found] [Error: Reference source not found] is designed to represent data, presentation and control. WSXL relies on existing standards; in particular, XML based standards such as XPath, XML Events, DOM, XForms and XLink as well as Web Services standards such as SOAP, WSDL and WSFL. WSXL includes an extensible Adaptation Description Language where explicit locations of adaptation points, the permissible
operations on adaptation points (e.g. insert, delete, modify), and the constraints on the contents of adaptation (e.g. via an XML Schema) can be specified. The Adaptation Description Language can be used during a post-processing step where the output of a WSXL component can be adapted independently without invoking the component. Finally, a WSXL collection provides an execution and management environment for WSXL components. It calls the lifecycle operations on WSXL components it instantiates, and implements a set of interfaces and a processing model for use by WSXL components and objects external to the collection. An object implementing the WSXL collection interface need not be a WSXL component. The developer can create new and more abstract UI
XICL
The eXtensible user-Interface Markup Language (XICL) [Error: Reference source not found] is an easy way to develop User Interface Components to Browser-based software. New UI components are created from HTML components and others XICL components. The XICL description is translated into DHTML code. An XICL documents is
composed by a UI description composed by HTML or XICL elements and several components (Structure, Properties, Events and Methods. XICL is a language to UI development by specifying its structure and behavior in an abstract level than using only DHTML. It also promotes reuse and extensibility of user interface components.
XIML
Sistem from based:
Mecano (Puerta)
Trident (Vanderdonckt)
Maria XML
Revangie
MB-IDEs
ITS
Humanoid
UIDE
Digbe
DIGBE automatically provides a well-designed, user specialized interface for each user. It also adapts
dynamically as it supports the collaboration between the user and the system, by:
automatically designing an appropriate application shell and required task interactions,
dynamically specializing this interface based on the current user and domain situation, and
interactively presenting the user interface for the interactions that are required on the user's selected device (CRT or handheld).
Each active DIGBE system automatically designs and presents itself, dynamically responds to changes in
application objects, and tunes itself to the role and security properties of the user, the selected device, and the tasks that are active. The basis of these capabilities is the knowledge that DIGBE possesses about dynamic interaction generation
XSFORM
amount of repetitive development efforts on formbased GUI is still not avoidable when the user needs
to deal with XML documents of different schemas. To address this problem, this research has developed a form-based XML information processing
application, called XsForm, that is driven by the userinput XML schema to automatically generate
appropriate Windows forms and associated functions. This paper discusses the development of XsForm and its application to promote e-business in the
construction industry.
The system should build an appropriate formbased GUI automatically based on the user-input XML schema to facilitate the gathering, editing, and management of XML information associated with the schema. In addition, the system should allow input of a new schema at any time and rebuild its form-based GUI accordingly and automatically.
� The system should provide some flexibility for the user to adjust the appearance of GUI.
� The system should provide functions for saving the information into an XML file that is wellformed and valid with respect to the user-input
XML schema as well as for searching and querying XML information in the XML files managed by the system.
According to the requirements discussed above, the architecture of XsForm is designed as shown in Fig. 1. The arrows in Fig. 1 show the data flow between the user, the XsForm functional components (in the business logic tier and UI tier), and the XsForm functional components (in the data tier). XsForm takes an XML schema as input and uses the
XsForm can also take a valid XML file as input. In this case, the system finds and loads the
corresponding XML schema automatically. The automatically generated Windows forms are then filled with the data of the XML file. XsForm produces XML files as output. All of the XML files produced are not only well-formed but also valid with respect to the user-input schema.
UIML 3.0 Language Specification 1. Define an XML schema to describe the structures, contents, and semantics of the set of forms. Although this step requires some fair amount of efforts, the resulted XML schema is the key document for sharing and exchange of the information in the set of forms with collaborative parties in the e-business process. 2. Execute XsForm and read the XML schema into XsForm.
3. XsForm automatically and quickly generates appropriate Windows forms for the user to digitalize and edit data in the forms. It also allows the user to save the data in the XML files that is well-formed and valid with respect to the given XML schema.
Liquid-Interface
INTRODUCTION
Dynamic composition is a new way for creating software applications. Rather than manual coding the new application, the application is generated automatically by reusing existing software services according to the user’s requirements [3],
[7]. The method has several advantages: it answers an instantaneous request of the user, and the application is flexible:
the application can change instantly, reacting to changes in the underlying services (e.g. failures, price change, quality of service etc). While dynamic composition promises an exciting vision for software development, it raises several questions regarding the way users interact with the generated application. Specifically, it raises a challenge for usability, which is defined as the effectiveness, efficiency and satisfaction in which users perform tasks using a given system [1].
In traditional software development processes, the userinterface is derived from the requirements and desired functionality of the application model. It can be carefully designed and tested in order to insure its usability. In contrast, in dynamically composed applications, the functionality is not set during the design of the system. Therefore, it the userinterface cannot be designed, let alone tested for usability.
The conclusion is that the user-interface should be generated dynamically as well, reflecting the temporary functionality of the application.
The field of automatic generation of user-interfaces attempts to formally define the elements of user-interface, including presentation and interaction, and use the formal model in order to generate user-interfaces [5], [4], [6]. While modelbased user-interfaces provide the foundations for automatic
generation of user-interfaces, they do not deal with usability optimization as they presume the models are already usable. However, this approach will not suffice for dynamic compositions, as these compositions are not optimized for usability
Method
The input to the generation process is a model of
dynamically-composed application, written in OWL-S [2],
which is a widespread language used to define dynamic compositions using rich semantic models. The parts of the OWLS
GuiGen
GuiGen is a comprehensive set of tools for creating customized graphical user interfaces (GUIs). It draws from the concept of computing portals, which are here seen as interfaces to application-specific computing services for user communities. While GuiGen was originally designed for the use in computational grids, it can be used in client/server environments as well.
Compared to other GUI generators, GuiGen is more versatile and more portable. It can be employed in many different application domains and on different target platforms. With GuiGen, application experts (rather than computer scientists) are able to create their own individually tailored GUIs.
Mesca
Mesca [15] merupakan implementasi dari disain menu berbasis kasus (case-based). Pustaka kasus terdiri dari berbagai menu dari berbagai aplikasi yang ada pada berbagai sistem operasi dan berbagai bidang. Sistem mengambil jenis aplikasi yang akan dikembangkan dari layar dialog, sistem operasinya apa dan bidang apa. Kemudian algoritma pemadanan (matching algorithm) melakukan pemadanan secara cerdas. Berikutnya pengguna diberi kesempatan untuk memilih menu terbaik dari kasus yang diperoleh. Hasilnya, berupa solusi, kemudian digunakan langsung dalam aplikasi yang dibangun.
These are features of a case :
Function of the menu : e.g. File, Edit, Format, Help etc.
Type of application of the software : e.g. Word Processing, Spreadsheet, Communication etc. Operating system on which the software is supposed to run : e.g. Windows95, DOS,
Macintosh, UNIX etc.
If the application is tailored to a specific field : e.g. Statistics, Mathematics, Chemistry etc. The degree to which the application is graphics oriented, on scale of 1 to 3.
The level of computer literacy expected from the user of the software developed, on scale of 1 to 3.
CbaUI (Case Based Adaptive User Interface) Widget
Adaptation is referred to the notion of changing something to meet some specific requirements or purposes [1]. Adaptive systems are described as tools which develop new information about how to do the task better by analysing past experience and relating it to performance criteria set by humans [2]. It is also stated that an adaptive system adapts its behaviour to individual users based on information about them which is either implicitly collected during the user-system interaction or users are explicitly asked for it, and the adaptive system performs the adaptation using some form of learning, inference or decision making [3].
Prinsip
Metode/pendekatannya
Contoh output
3 Referensi
1. Krueger, C.W.; Software Reuse; 1992.
4. Gomes, P.; A Case-Based Approach to Software Design; disertasi PhD; 2003. 5. Almeida, E.S. et.al., A Survey on Software Reuse Processes, 2004
6. Neighbors, J.M.; Software Construction Using Components, 1980 7. Kaur, A., Goyal, R.; Software Reuse Library; 2012.
8. Prieto-Díaz, R.; Status Report: Software Reusability, 1993 9.
10. Hsieh S-H.; Lin, H-T.; XSFORM: A SCHEMA-DRIVEN FORM-BASED XML INFORMATION PROCESSOR; 2004
11. Toch, E., Reinhartz-Berger, I, Dori, D; Liquid-Interface: Automatically Generating and Optimizing User-Interfaces for Dynamic Compositions, 2008
12. Penner, R, Steinmetz, E.S; DIGBE: Adaptive User Interface Automation; 1999.
13. Reinefelda, A., Stuben, H., Florian Schintke, F., Din, G.; GuiGen: A Toolset for Creating Customized Interfaces for Grid User Communities, 2002
14. Savidis, A., Antona, M., Stephanidis C.: A Decision-Making Specification Language for Automatic Interface Adaptation, 2005
15. Joshi, S.R., McMillan, W.W.; Case Based Reasoning Approach to Creating User Interface Components, 1996.
16. Marir, F.; Case Based Reasoning for an Adaptive Web User Interface; 2012 17. m
