A framework for object identification and refinement process in object-oriented analysis and design

Wahono, Romi Satria; Far, Behrouz H.

doi:10.1109/coginf.2002.1039317

Cited by 9 publications

(20 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…After eliminating duplicates, 361 papers remained to be further investigated. After filtering the results (361 papers) of the electronic search by applying the inclusion/exclusion criteria, we identified 11 papers [6,14,19,21,24,25,36,40,48,51,54] to include. The manual search of journals and conference proceedings yielded an additional six primary studies (i.e., [10,17,18,20,47,49]), and two of them (i.e., [18,49]) are more recent discussions and therefore replaced two of the 11 papers identified from the electronic search (i.e., [19,48]).…”

Section: Statistics From Included Primary Studiesmentioning

confidence: 99%

“…From a user's perspective, a generated analysis model is expected to be as complete as possible so that it can be a useful starting point of an iterative analysis refinement process. Various types of analysis models can be generated by the approaches proposed in the primary studies, such as UML models [54] and MSCs [17]. Though it is difficult to compare different types of analysis models, their common modeling capabilities can be extracted and used as the basis for comparison.…”

Section: Evaluation Criterion For Analysis Modelsmentioning

confidence: 99%

“…Configuration 3 needs requirements to be documented using the OBFS template, a customized document template that the transformation technique of the approach [54] relies on. This configuration does not need any DSI or restricted NL.…”

Section: Requirements Configurationsmentioning

confidence: 99%

“…However, the extent of restrictions varies across approaches and a balance should be struck between the applicability of restriction rules and facilitating analysis. We summarize the restriction rules applied in the primary studies (i.e., [47,49,52,54]) in Table 3. These rules are classified into three categories: sentence restrictions, sentence structure restrictions, and wording restrictions (Sect.…”

Section: Requirements Configurationsmentioning

confidence: 99%

“…Though configuration 2 [6] does not rely on restricted NL and does not require any specific requirement representation, the difficulty of documenting requirements is still high as users are Is a kind of, is specialization of, is generalization of Inheritance sentences Identify generalization between subject and object [54] Drive, work for, maintain, manage, own, execute, serve, use Action sentences Identify objects and associations [54] Talk to, communicate with, refer to Communication sentences Identify objects and associations [54] Next to, goto Location sentences Identify objects and associations [54] Has (a capability of), has (a capacity for), can, able to has not (a capability of), has not (a capacity for), cannot, not able to Behavioral sentences Identify behaviors [54] a A simple sentence is composed of one subject and one predicate required to manually specify glossary and a significant number of definitions in a specific form. Configuration 3 [54] implies requirements to be manually documented in a non-standard modeling language (OBFS) and the use of restricted NL. Configuration 6 [34,52] needs a glossary, and use cases are required to be written in restricted NL.…”

Section: Requirements Configurationsmentioning

confidence: 99%

See 4 more Smart Citations

A systematic review of transformation approaches between user requirements and analysis models

2010

View full text Add to dashboard Cite

Model transformation is one of the basic principles of Model Driven Architecture. To build a software system, a sequence of transformations is performed, starting from requirements and ending with implementation. However, requirements are mostly in the form of text, but not a model that can be easily understood by computers; therefore, automated transformations from requirements to analysis models are not easy to achieve. The overall objective of this systematic review is to examine existing literature works that transform textual requirements into analysis models, highlight open issues, and provide suggestions on potential directions of future research. The systematic review led to the analysis of 20 primary studies (16 approaches) obtained after a carefully designed procedure for selecting papers published in journals and conferences from 1996 to 2008 and Software Engineering textbooks. A conceptual framework is designed to provide common concepts and terminology and to define a unified transformation process. This facilitates the comparison and evaluation of the reviewed papers.One of the basic principles of Model Driven Architecture (MDA) [29] is model transformation. To build a software system, a series of transformations is performed: transformation from requirements to Platform Independent Model (PIM) (the analysis model), transformation from PIM to Platform Specific Model (PSM) (the design model), and transformation from PSM to code. However, the transformation from requirements to an analysis model is not part of the MDA lifecycle, which starts from an analysis model and ends with deployed code [29]. The reason of this exclusion is perhaps that requirements are mostly in a textual form, which is not a model formal enough to be understood by computers. As a result, requirements are not suitable for automated transformations, and only manual heuristics, such as Abbott's heuristics [4], are in general followed [9,32]. However, if a (semi-) automated transformation technology from requirements to an analysis model were devised, it would help fill an important gap in the MDA software development lifecycle.If these transformations can be automated, full traceability from requirements (through PIM and PSM) to the ultimate software code can be obtained at the same time. Traceability is the ability to link requirements to corresponding analysis and design models, code, test cases, and other software artifacts. Traceability is important during software development because it enables engineers to understand the connections between various artifacts of a software system, and it is also used to determine whether

show abstract