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 Pendekatan-Pendekatan Software Reuse
Prieto-Diaz [8] mengidentifikasi pendekatan-pendekatan SR melalui 6 dimensi/perspektif yang disebut facet: substance, scope, mode, technique, intention dan by-product seperti pada tabel di bawah:
{by-substance} {by-technique}
ideas, concepts vertical planned, systematic
compositional as-is, black box source code
artifacts,
components horizontal ad-hoc, opportunistic generative with-modification,white box design
procedures, skills specifications
objects
text
architectures
Menurut Lucredio et al [9], ada tiga pendekatan utama dalam SR: Component-Based Development (CBD), Domain Engineering (DE) dan Software Product Line (SPL).
Ketiganya merupakan perkembangan SR yang bergerak menuju cara yang lebih sistematik untuk mempromosikan SR. Kebanyakan pendekatan SR berdasar pada CBD yang merupakan gagasan lama. Pada tahun 1968, McIlroy menggagas bahwa sistem software harus
mengabstraksikan yang umum ada (common) pada kebanyakan komponen. Proses ini menjadi dasar pendekatan yang disebut Domain Engineering (DE).
DE terdiri dari pengumpulan, pengorganisasian dan penyimpanan pengalaman selama membangun sistem domain tertentu dalam bentuk aset yang dapat dipakai ulang dan
memberikan cara pemakaian ulang yang cukup terhadap aset ini dalam pengembangan sistem yang baru. Akan tetapi pendekatan DE ini ternyata tidak seefisien yang diharapkan. Maslah utamanya adalah bahwa domain mencakup beberapa unsur yang tidak penting bagi
organisasi/instansi sehingga memaksa untuk mengimplementasikan beberapa komponen yang tudak berguna ketimbang fokus hanya pada produknya. Untuk memecahkan hal ini, trend baru mulai didekati: Software Product Line (SPL). Perbedaannya dengan DE adalah
berkaitan dengan cakupan domain: ketimbang memperhatikan semua aplikasi yang mungkin ketika membangun komponen, SPL lebih fokus pada produk (eksistensi, dalam
pengembangan dan perencanaan), sehingga domain hanya terdiri dari unsur yang penting bagi instansi. Titik-titik perbedaan antara aplikasi diketahui dengan baik, sehingga
pengembang bisa memilih di antara kombinasi fitur yang mungkin yang akan dipakai dalam produk.
Nath dan Kumar [11] menambahkan pendekatan architectur-based dalam SR. Dalam hal ini mereka mengutip pandangan Mary Shaw [12]: pemakaian ulang yang efektif tidak hanya bergantung pada cara mendapatkan dan menggunakan kembali komponen, tetapi juga pada cara bagaimana komponen itu diramu. Arsitektur sistem software terdiri dari komponen software, sifat-sifat eksternal dan hubungannya satu sama lain. Pemakaian ulang berbasis arsitektur ini memperlebar definisi aset yang dapat dipakai ulang untuk menyertakan sifat-sifat dan hubungan antar komponen.
Shaw melakukan klasifikasi arsitektur berdasarkan 4 unsur tama: komponen, konektor, struktur kontrol dan model sistem. Sistem terdiri dari berbagai jenis komponen yang dapat diidentifikasi. Komponen-komponen ini berinteraksi dengan cara berbeda dan dapat dikenali. Komponen berkaitan dengan satuan kompilasi dalam pengertian bahasa pemrograman
konvensional, hingga objek bertaraf pengguna seperti berkas. Sedangkan konektor menjadi perantara interaksi antar komponen; yang tunduk pada cara interaksi dan mekanisme yang diharuskan. Konektor tidak secara langsung berkaitan dengan satuan kompilasi tetapi menjelma sebagai tabel entri, perintah ke linker, struktur data dinamik, pemanggilan sistem, inisialisasi parameter, dan sebagainya. Struktur kontrol merupakan aturan aksekusi. Model sistem menggambarkan bagaimana semuanya dipadu.
Demikianlah tentang SR dan bab berikutnya membahas peranan case-based reasoning dalam SR dan design.
3 Case-Based Reasoning
dicoba untuk diberikan. Jika diterima, sistem CBR bisa menyimpan masalah dan solusi yang baru sebagai kasus baru. Jika solusi belum final, bisa terjadi adaptasi ulang.
Proses-proses yang merangkai penalaran berbasis kasus dapat dipandang cerminan salah satu jenis penalaran manusia. Dalam banyak situasi, masalah yang dihadapi manusia dipecahkan manusia seperti CBR. Jika seseorang menjumpai situasi atau persoalan yang belum dialami sebelmnya, dia seringkali mengacu ke persoalan serupa yang dialami sebelumnya. Persoalan serupa ini bisa pengalaman dia sendiri atau pengalaman orang lain, kasus ditambahkan dalam ingatan penalaran manusia melalui lisan atau tulisan.
3.1 Kapan menggunakan CBR?
Ada sejumlah karakteristik persoalan dan domainnya yang dapat digunakan untuk menentukan apakah CBR bisa diterapkan [13]:
1. Apakah domain memiliki model?
Jika proses penalaran bersifat acak, atau jika faktor yang membawa keberhasilan atau
kegagalan solusi tidak dapat dirumuskan dalam deskripsi kasus, penalaran dari kasus lampau mungkin sia-sia.
2. Adakah pengecualian dan kasus baru?
Domain yang tidak memiliki kasus yang baru atau pengecualian, lebih baik dimodelkan dengan aturan (rule-based), yang dapat ditentukan secara induktif dari sejumlah kasus.
3. Apakah kasusnya berulang?
Apabila suatu kasus tidak mungkin dipakai dalam persoalan berikutnya, karena kurangnya kemiripan, maka kecil, jika ada, nilainya dalam menyimpan kasus tersebut. Dalam domain demikian, jika kasus tidak cukup mirip, untuk diadaptasi, maka mungkin lebih baik
membangun model proses membentuk solusi, ketimbang model untuk domain solusi.
4. Adakah keuntungan yang berarti dalam adaptasi solusi yang lampau?
Kita harus perhatikan apakah ada perbedaan yang berarti dalam sumberdaya yang
dikeluarkan (waktu, proses, dsb) antara menciptakan suatu solusi terhadap persoalan dari awal dan menciptakan solusi dengan mengubah solusi yang mirip?
Are relevant previous cases obtainable?
It is possible to obtain the data that records the necessary characteristics of past cases? Do the recorded cases contain the features of the problem and
4 Specification Language
Bahasa Spesifikasi
aecXML
UIML
UsiXML
XIML
Teresa
UMLi
Aplikasi bahasa deskripsi misal dalam pemodelan interaksi
UIDLs Overview
DISL
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
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
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:
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 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
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 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
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.
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.
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 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.
Mesca
Mesca [20] 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
5 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, 2005
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. Lucredio, D. et al; The Draco Approach Revisited: Model-Driven Software Reuse; 2006 10. Al Hijaj, A.A., et al; Using of Software Reuse Approaches to Develop UGELIB Web
Application, 2009
11. Nath, R.; Kumar, H.; A Review of Approaches to Software Reuse, 2008.
12. Shaw, M.; Architectural Issues in Software Reuse: It’s Not Just the Functionality, It’s the Packaging; 1995.
13. Main, J., et al; A Tutorial on Case-Based Reasoning, 2001 14.
15. Hsieh S-H.; Lin, H-T.; XSFORM: A SCHEMA-DRIVEN FORM-BASED XML INFORMATION PROCESSOR; 2004
16. Toch, E., Reinhartz-Berger, I, Dori, D; Liquid-Interface: Automatically Generating and Optimizing User-Interfaces for Dynamic Compositions, 2008
17. Penner, R, Steinmetz, E.S; DIGBE: Adaptive User Interface Automation; 1999.
18. Reinefelda, A., Stuben, H., Florian Schintke, F., Din, G.; GuiGen: A Toolset for Creating Customized Interfaces for Grid User Communities, 2002
19. Savidis, A., Antona, M., Stephanidis C.: A Decision-Making Specification Language for Automatic Interface Adaptation, 2005
20. Joshi, S.R., McMillan, W.W.; Case Based Reasoning Approach to Creating User Interface Components, 1996.
21. Marir, F.; Case Based Reasoning for an Adaptive Web User Interface; 2012 22. m
