<p class="Abstrak">UML sudah menjadi bahasa pemodelan baku dalam pengembangan sistem perangkat lunak. Pemodelan yang penting dalam UML, untuk menjelaskan aspek fungsionalitas sistem, adalah pemodelan <em>use case</em>. <em>Use case</em> dideskripsikan secara tekstual dalam bentuk <em>use case scenario</em> untuk menjelaskan interaksi yang terjadi antara aktor dengan sistem. Selanjutnya, <em>use case</em> diilustrasikan secara visual dalam bentuk <em>use case diagram</em> untuk menggambarkan konteks dari sistem yang dikembangkan. Dalam praktiknya, kedua model tersebut tidak sulit untuk dibuat meskipun oleh orang yang belum berpengalaman. Namun demikian, pemodelan <em>use case</em> yang dihasilkan, baik dalam konteks pembelajaran konsep pengembangan perangkat lunak di kampus maupun dalam konteks implementasi di industri perangkat lunak, tidak sedikit yang mengandung kesalahan baik secara sintaksis maupun semantik. Artikel ini bertujuan untuk melakukan evaluasi terhadap beberapa kesalahan tersebut sehingga bisa dijadikan acuan dalam membangun model yang baik dan benar sehingga mampu menjelaskan sistem yang dikembangkan secara tepat. Evaluasi dilakukan dengan mengidentifikasi dan mengklasifikasi kesalahan, serta merekomendasi perbaikan yang diperlukan berdasarkan kajian teori dan spesifikasi UML. Artikel ini telah membahas secara detil 11 jenis kesalahan dalam pembuatan <em>use case scenario</em> dan 7 jenis kesalahan dalam penggambaran <em>use case diagram</em>, masing-masing disertai dengan contoh kasus yang relevan.</p>

Abstract. Most medium to large organizations support large collections of process designs, often stored in business process repositories. These processes are often inter-dependent. Managing such large collections of processes is not a trivial task. We argue that formalizing and establishing inter-process relationships play a critical role in that task leading to a machinery approach in the process repository management. We consider and propose three kinds of such relationships, namely part-whole, inter-operation and generalization-specialization, including their formal definitions, permitting us to develop a machinery approach. Analysis of the relationships relies on the semantically effects annotated process model in BPMN. This paper presents a rigorous approach to assist the designer to establish inter-process relationships in a process repository.

Extractive Software Product Line Engineering (SPLE) puts features on the foremost aspect in domain analysis that needs to be extracted from the existing system's artifact. Feature in SPLE, which is closely related to system functionality, has been previously studied to be extracted from source code, models, and various text documents that exist along the software development process. Source code, with its concise and normative standard, has become the most focus target for feature extraction source on many kinds of research. However, in the software engineering principle, the Software Requirements Specification (SRS) document is the basis or main reference for system functionality conformance. Meanwhile, previous researches of feature extraction from text document are conducted on a list of functional requirement sentences that have been previously prepared, not literally SRS as a whole document. So, this research proposes direct processing on the SRS document that uses requirement boilerplates for requirement sentence statement. The proposed method uses Natural Language Processing (NLP) approach on the SRS document. Sequence Part-of-Speech (POS) tagging technique is used for automatic requirement sentence identification and extraction. The features are acquired afterward from extracted requirement sentences automatically using the word dependency parsing technique. Besides, mostly the previous researches about feature extraction were using non-public available SRS document that remains classified or not accessible, so this work uses selected SRS from publicly available SRS dataset to add reproducible research value. This research proves that requirement sentence extraction directly from the SRS document is viable with precision value from 64% to 100% and recall value from 64% to 89%. While features extraction from extracted requirement sentences has success rate from 65% to 88%.

No abstract