Survey Form 2a Kegiatan terbaru situs unk1546 Survey Form 2a
Pemakaian Ulang Antarmuka Berbasis
Form: Survey
Oleh
Uung Ungkawa
33212020
Sekolah Teknik Elektro dan Informatika
Institut Teknologi Bandung
2013
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].
Untuk dapat melakukan komputasi, penalaran, dibutuhkan suatu pemodelan yang
membutuhkan bahasa pemodelan. Dalam hal antarmuka berbasis form, dibutuhkan
pemodelan antarmuka menggunakan bahasa pemodelan. Telah banyak diteliti dan dibuat
bahasa pemodelan antarmuka. Dalam tulisan ini dibahas perkembangan mutakhir (state-ofthe-art) SR, case-base reasoning sebagai saudara kembar dari analogical reasoning dan
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
Supaya teknik SR efektif, haruslah mengurangi jarak kognisi antara konsep awal sistem dengan
implementasi final yang dapat dieksekusi. [1].
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:
-
Standar Pemenuhan: Beberapa standar seperti standar antarmuka pengguna (User
Interfase, UI) dapat diimplementasikan sebagai kumpulan komponen standar yang
dapat dipakai ulang. Sebagai contoh, apabila menu dalam UI dibuat dari komponen
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
transformasi dan komponen. Meskipun demikian, pendekatan ini sangat sulit diterapkan
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 domainspecific 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 productline yang melampaui pendekatan domain engineering yang ada. Di pihak lain, pendekatan
domain engineering tidak terbukti efektif seperti yang diharapkan.
Almeida mencatat beberapa usaha penerapan SR berbasis reuse dengan motivasi dan
solusinya: PuLSE (Product Line Software Engineering), KobrA, CoPAM (ComponentOriented Platform Architecting Method) dan PECOS (Pervasive Components System).
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
procedures, skills
Bahasa Spesifikasi
aecXML
UIML
with-modification, white box
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
presentation. The use of generic widget attribute enables to assign each widget to
a particular type of functionality it ensures (e.g., command, variable field, text
field, etc.). Further, a DISL rendering engine can use this information to create
interface components appropriated to the interaction modality (i.e., graphical,
vocal) in which the widget will operate. The global DISL structure consists of an
optional head element for Meta information and a collection of templates and
interfaces from which one interface is considered to be active at one time.
Interfaces are used to describe the dialog structure, style, and behavior, whereas
templates only describe structure and style in order to be reusable by other
dialog components.
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
Renderer-Independent Markup Language (RIML) [Error: Reference source not found] is a markup
language based on W3C standards that allows document authoring in a device
independent fashion. RIML is based on standards such as: XHMTL 2.0 and
XFORMS. Special row and column structures are used in RIML to specify content
adaptation. Their semantics is enhanced to cover pagination and layout directives
in case pagination needs to be done. Due to the use of XForms, RIML is device
independent and can be mapped into a XHTML specification according to the
target device. RIML semantics is enhanced to cover pagination and layout
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
TeresaXML [Error: Reference source not found] is a UIDL for producing multiple final UIs for
multiple computing platforms at design time. They suggest starting with the task
model of the system, then identifying the abstract UI specifications in terms of its
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.
4. UIML allows UI parts and part-trees to be packaged in templates: these templates may then be
reused in various interface designs.
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 sub-steps, thus ensuring various alternatives for the existing substeps to be explored and/or expanded with new 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
components.
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
The eXtensible Interface Markup Language (XIML) [Error: Reference source not found] [Error:
Reference source not found], is a language developed by Redwhale Software,
derived from XML and able to store the models developed in MIMIC [Error:
Reference source not found]. MIMIC is a meta-language that structures and
organizes interface models. It divides the interface into model components: usertask, presentation, domain, dialog, user, and design models. The design model
contains all the mappings between elements belonging to the other models. The
XIML is thus the updated XML version of this previous language. The XIML
language is mainly composed of four types of components: models, elements,
attributes, and relations between the elements. The presentation model is
composed of several embedded elements, which correspond to the widgets of
the UI, and attributes of these elements representing their characteristics (color,
size…). The relations at the presentation level are mainly the links between labels
and the widgets that these labels describe. XIML supports design, operation,
organization, and evaluation functions; it is able to relate the abstract and
concrete data elements of an interface; and it enables knowledge-based systems
to exploit the captured data.
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
Although the aforementioned efforts have provided
useful tools to ease the task of building form-based
XML information processing applications, fair
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
Schema2UIML component to parse and transform the
XML schema into the corresponding UIML file.
UIML (User Interface Markup language) [9], an
XML language for defining user interfaces, is
employed in this work to describe and record detailed
information about the required GUI. The recorded
information is then used by the UIML2GUI
component to create Windows forms and associated
functions. The above process from the input of XML
schema to the creation of corresponding Windows
forms is performed automatically by XsForm.
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.
4. The XML files and the XML schema can then be
used in the e-business process for information
sharing and exchange.
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
model which are relevant to this research are the process
model, which defines the execution order of the processes, and
the process specification, which defines the input and output
parameters of processes using ontological concepts. In order to
exemplify our approach we use a simple composition, depicted
in Figure (a), describing a book buying application. The
application is composed of three sub-processes, represented
by the ellipses and ordered as a sequence. The square objects
represent input and output parameters of the processes.
The user-interface generation process creates a Web-form
for each sub-process, generating the form’s fields from the
input and output parameters. Figure (b) contains a screenshot
of such a form, generated for the process model in Figure (a).
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.
GuiGen helps application experts to design customized GUIs for different application
domains. In GuiGen, the user interface is split into two parts: a platform independent GUI
that can be easily tailored to the specific needs of a user community, and the machine specific
back-ends, one for each potential target system. The GUIs (called Forms) and the back-ends
(called JobTemplates) can be maintained in repositories for later re-use.
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.
CASE BASED REASONING APPROACH TO CREATING USER IN...
http://www.sigchi.org/chi96/proceedings/intpost/Joshi/js_txt.html
2
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
Masukan dan keluarannya
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
18.
Form: Survey
Oleh
Uung Ungkawa
33212020
Sekolah Teknik Elektro dan Informatika
Institut Teknologi Bandung
2013
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].
Untuk dapat melakukan komputasi, penalaran, dibutuhkan suatu pemodelan yang
membutuhkan bahasa pemodelan. Dalam hal antarmuka berbasis form, dibutuhkan
pemodelan antarmuka menggunakan bahasa pemodelan. Telah banyak diteliti dan dibuat
bahasa pemodelan antarmuka. Dalam tulisan ini dibahas perkembangan mutakhir (state-ofthe-art) SR, case-base reasoning sebagai saudara kembar dari analogical reasoning dan
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
Supaya teknik SR efektif, haruslah mengurangi jarak kognisi antara konsep awal sistem dengan
implementasi final yang dapat dieksekusi. [1].
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:
-
Standar Pemenuhan: Beberapa standar seperti standar antarmuka pengguna (User
Interfase, UI) dapat diimplementasikan sebagai kumpulan komponen standar yang
dapat dipakai ulang. Sebagai contoh, apabila menu dalam UI dibuat dari komponen
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
transformasi dan komponen. Meskipun demikian, pendekatan ini sangat sulit diterapkan
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 domainspecific 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 productline yang melampaui pendekatan domain engineering yang ada. Di pihak lain, pendekatan
domain engineering tidak terbukti efektif seperti yang diharapkan.
Almeida mencatat beberapa usaha penerapan SR berbasis reuse dengan motivasi dan
solusinya: PuLSE (Product Line Software Engineering), KobrA, CoPAM (ComponentOriented Platform Architecting Method) dan PECOS (Pervasive Components System).
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
procedures, skills
Bahasa Spesifikasi
aecXML
UIML
with-modification, white box
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
presentation. The use of generic widget attribute enables to assign each widget to
a particular type of functionality it ensures (e.g., command, variable field, text
field, etc.). Further, a DISL rendering engine can use this information to create
interface components appropriated to the interaction modality (i.e., graphical,
vocal) in which the widget will operate. The global DISL structure consists of an
optional head element for Meta information and a collection of templates and
interfaces from which one interface is considered to be active at one time.
Interfaces are used to describe the dialog structure, style, and behavior, whereas
templates only describe structure and style in order to be reusable by other
dialog components.
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
Renderer-Independent Markup Language (RIML) [Error: Reference source not found] is a markup
language based on W3C standards that allows document authoring in a device
independent fashion. RIML is based on standards such as: XHMTL 2.0 and
XFORMS. Special row and column structures are used in RIML to specify content
adaptation. Their semantics is enhanced to cover pagination and layout directives
in case pagination needs to be done. Due to the use of XForms, RIML is device
independent and can be mapped into a XHTML specification according to the
target device. RIML semantics is enhanced to cover pagination and layout
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
TeresaXML [Error: Reference source not found] is a UIDL for producing multiple final UIs for
multiple computing platforms at design time. They suggest starting with the task
model of the system, then identifying the abstract UI specifications in terms of its
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.
4. UIML allows UI parts and part-trees to be packaged in templates: these templates may then be
reused in various interface designs.
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 sub-steps, thus ensuring various alternatives for the existing substeps to be explored and/or expanded with new 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
components.
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
The eXtensible Interface Markup Language (XIML) [Error: Reference source not found] [Error:
Reference source not found], is a language developed by Redwhale Software,
derived from XML and able to store the models developed in MIMIC [Error:
Reference source not found]. MIMIC is a meta-language that structures and
organizes interface models. It divides the interface into model components: usertask, presentation, domain, dialog, user, and design models. The design model
contains all the mappings between elements belonging to the other models. The
XIML is thus the updated XML version of this previous language. The XIML
language is mainly composed of four types of components: models, elements,
attributes, and relations between the elements. The presentation model is
composed of several embedded elements, which correspond to the widgets of
the UI, and attributes of these elements representing their characteristics (color,
size…). The relations at the presentation level are mainly the links between labels
and the widgets that these labels describe. XIML supports design, operation,
organization, and evaluation functions; it is able to relate the abstract and
concrete data elements of an interface; and it enables knowledge-based systems
to exploit the captured data.
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
Although the aforementioned efforts have provided
useful tools to ease the task of building form-based
XML information processing applications, fair
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
Schema2UIML component to parse and transform the
XML schema into the corresponding UIML file.
UIML (User Interface Markup language) [9], an
XML language for defining user interfaces, is
employed in this work to describe and record detailed
information about the required GUI. The recorded
information is then used by the UIML2GUI
component to create Windows forms and associated
functions. The above process from the input of XML
schema to the creation of corresponding Windows
forms is performed automatically by XsForm.
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.
4. The XML files and the XML schema can then be
used in the e-business process for information
sharing and exchange.
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
model which are relevant to this research are the process
model, which defines the execution order of the processes, and
the process specification, which defines the input and output
parameters of processes using ontological concepts. In order to
exemplify our approach we use a simple composition, depicted
in Figure (a), describing a book buying application. The
application is composed of three sub-processes, represented
by the ellipses and ordered as a sequence. The square objects
represent input and output parameters of the processes.
The user-interface generation process creates a Web-form
for each sub-process, generating the form’s fields from the
input and output parameters. Figure (b) contains a screenshot
of such a form, generated for the process model in Figure (a).
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.
GuiGen helps application experts to design customized GUIs for different application
domains. In GuiGen, the user interface is split into two parts: a platform independent GUI
that can be easily tailored to the specific needs of a user community, and the machine specific
back-ends, one for each potential target system. The GUIs (called Forms) and the back-ends
(called JobTemplates) can be maintained in repositories for later re-use.
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.
CASE BASED REASONING APPROACH TO CREATING USER IN...
http://www.sigchi.org/chi96/proceedings/intpost/Joshi/js_txt.html
2
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
Masukan dan keluarannya
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
18.