This article presents the methodology that has been successfully used over the past seven years by an interdisciplinary team to create the International Committee for Documentation of the International Council of Museums (CIDOC) CONCEPTUAL REFERENCE MODEL (CRM), a high-level ontology to enable information integration for cultural heritage data and their correlation with library and archive information. The CIDOC CRM is now in the process to become an International Organization for Standardization (ISO) standard. This article justifies in detail the methodology and design by functional requirements and gives examples of its contents. The CIDOC CRM analyzes the common conceptualizations behind data and metadata structures to support data transformation, mediation, and merging. It is argued that such ontologies are property-centric, in contrast to terminological systems, and should be built with different methodologies. It is demonstrated that ontological and epistemological arguments are equally important for an effective design, in particular when dealing with knowledge from the past in any domain. It is assumed that the presented methodology and the upper level of the ontology are applicable in a far wider domain.

/pdf/the-cidoc-conceptual-reference-module-an-ontological-7d3tc9g18b.pdf

The CIDOC conceptual reference module: an ontological approach to semantic interoperability of metadata

There is an abundance of testing styles in the discipline of software engineering today. Over the last few decades, many of these have come to be used and adopted by the industry as solutions to address the increasing demand for assuring software quality. Since 1990 or so, perhaps as an outcome of the popularization of object orientation and models in software engineering, there has been a growth in black-box testing techniques that are collectively dubbed model-based testing. Model-based testing (MBT) is a general term that signifies an approach that bases common testing tasks such as test case generation and test result evaluation [see Jorgensen (1995) for some of these basic terms and concepts] on a model of the application under test.



This generic definition is probably the least general statement that can be made about MBT. One of the striking issues about MBT is the nonstandard lingo that reflects a diversity of philosophies and models. Another issue that one will eventually realize in studying this set of techniques is that the models and techniques have yet to travel the long course to maturity. Disregarding these concerns, model-based techniques have gained the attention of practitioners and theoreticians alike. The wealth of published work portraying case studies in both academic and industrial settings is a sign of the newfound interest in this youthful branch of testing.



Model-based techniques have substantial appeal. The first sign of potential are studies showing that testing a variety of applications has been met with success when MBT was employed. This article discussed what a model is and gives some models that have been useful for testing. Information given or choosing a module, building it, and testing it, The present and future status of model-based software testing is detailed.


Keywords:

model-based software testing (MBT);
definition;
background;
drawbacks;
language;
fundamental tasks;
model choice;
model building;
generating tests;
key concerns

/pdf/model-based-software-testing-u7lz7ikpon.pdf

Model‐Based Software Testing

Model integrated computing (MIC) is gaining increased attention as an effective and efficient method for developing, maintaining, and evolving large-scale, domain-specific software applications for computer-based systems. MIC is a model-based approach to software development, allowing the synthesis of application programs from models created using customized, domain-specific model integrated program synthesis (MIPS) environments. Until now, these MIPS environments have been handcrafted. Analysis has shown that it is possible to "model the modeling environment" by creating a metamodel that specifies both the syntactic and semantic behavior of the desired domain-specific MIPS environment (DSME). Such a metamodel could then be used to synthesize the DSME itself allowing the entire design environment to safely and efficiently evolve in the face of changing domain requirements. This paper discusses the use of the Unified Modeling Language and the Object Constraint Language to specify, such metamodels, and describes a method for incorporating these metamodels into the MultiGraph Architecture, a MIPS creation toolset.

https://www.isis.vanderbilt.edu/sites/default/files/Nordstrom_GG_4_0_1999_Metamodeli.pdf

Metamodeling-rapid design and evolution of domain-specific modeling environments

The complementary use of IDEF and UML modelling approaches

Tools and environments to aid developers in producing software have existed, in one form or another, since the early days of computer programming. They are becoming increasingly crucial as the demand for software increases, time-to-market decreases, and diversity and complexity grow beyond anything imagined a few decades ago. In this paper, we briefly review some of the history of tools and environments in software engineering, and then discuss some key challenges that we believe the field faces over the next decade.

/pdf/software-engineering-tools-and-environments-a-roadmap-134lu3jk95.pdf

Software engineering tools and environments: a roadmap

(Each chapter concludes with a Summary.) Foreword. Preface. 1. Introduction. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process. What Is Iterative and Incremental Development? The Rational Objectory Process. The Rational Rose Tool. 2. Beginning a Project. Defining the Right Project. Eastern State University (ESU) Background. Risks for the Course Registration Problem. ESU Course Registration Problem Statement. 3. Creating Use Cases. System Behavior. Actors. Use Cases. Use Case Relationships. Use Case Diagrams. 4. Finding Classes. What Is an Object? State, Behavior, and Identity. What Is a Class? Stereotypes and Classes. Discovering Classes. Documenting Classes. Packages. Objects and Classes in the ESU Course Registration Problem. Class Diagrams. 5. Discovering Object Interaction. Use Case Realization. Documenting Scenarios. Sequence Diagrams. Sequence Diagrams and Boundary Classes. Complexity and Sequence Diagrams. Collaboration Diagrams. Why Are There Two Different Diagrams? Sequence Diagram for the ESU Course Registration System. 6. Specifying Relationships. The Need for Relationships Association Relationships Aggregation Relationships Association or Aggregation? Naming Relationships. Role Names. Multiplicity Indicators. Reflexive Relationships. Finding Relationships. Relationships in the ESU Course Registration Problem. Package Relationships. Package Relationships in the Course Registration Problem. 7. Adding Behavior and Structure. Representing Behavior and Structure. Creating Operations. Documenting Operations. Relationships and Operation Signatures. Creating Attributes. Documenting Attributes. Displaying Attributes and Operations. Association Classes. 8. Discovering Inheritance. Inheritance. Generalization. Specialization. Inheritance Trees. Single Inheritance versus Multiple Inheritance. Inheritance versus Aggregation. 9. Analyzing Object Behavior. Modeling Dynamic Behavior. States. State Transitions. Special States. State Transition Details. State Details. 10. Checking the Model. Why Homogenize? Combining Classes. Splitting Classes. Eliminating Classes. Consistency Checking. Scenario Walk-Through. Event Tracing. Documentation Review. 11. Designing the System Architecture. The Need for Architecture. The Architecture Team. The "4+1" View of Architecture. The Logical View. The Component View. The Process View. The Deployment View. The Use Case View. 12. Building the Iterations. The Iteration Planning Process. Designing the User Interface. Adding Design Classes. The Emergence of Patterns. Designing Relationships. Designing Attributes and Operations. Designing for Inheritance. Coding, Testing, and Documenting the Iteration. Using Reverse Engineering to Set the Stage for the Next Iteration. Appendix A. Appendix B. Glossary. Index. 0201310163T04062001

Terry Quatrani

Papers

Visual modeling with Rational Rose and UML