57,197 research outputs found

    On modeling system-centric information for role engineering

    Get PDF
    In this paper we present an approach to modeling system-centric information in order to facilitate role engineering (RE). In particular, we first discuss the general character-istics of the information required in RE. Afterwards, we discuss two informational flow types among authorities in-volved in RE process, forward information flow (FIF) and backward information flow (BIF), together with the intro-duction of an information model which is greatly suitable for use in the backward information flow. System-centric information is incorporated in the information model and UML extension mechanisms are exploited for modeling the information. Not only can the information model provide those different authorities with a method for both analy-sis of resources and communication of knowledge in the RE process, but it can also help lay a foundation for successful implementations of RBAC

    Semantic model-driven development of service-centric software architectures

    Get PDF
    Service-oriented architecture (SOA) is a recent architectural paradigm that has received much attention. The prevalent focus on platforms such as Web services, however, needs to be complemented by appropriate software engineering methods. We propose the model-driven development of service-centric software systems. We present in particular an investigation into the role of enriched semantic modelling for a modeldriven development framework for service-centric software systems. Ontologies as the foundations of semantic modelling and its enhancement through architectural pattern modelling are at the core of the proposed approach. We introduce foundations and discuss the benefits and also the challenges in this context

    Data in Business Process Models. A Preliminary Empirical Study

    Get PDF
    Traditional activity-centric process modeling languages treat data as simple black boxes acting as input or output for activities. Many alternate and emerging process modeling paradigms, such as case handling and artifact-centric process modeling, give data a more central role. This is achieved by introducing lifecycles and states for data objects, which is beneficial when modeling data-or knowledge-intensive processes. We assume that traditional activity-centric process modeling languages lack the capabilities to adequately capture the complexity of such processes. To verify this assumption we conducted an online interview among BPM experts. The results not only allow us to identify various profiles of persons modeling business processes, but also the problems that exist in contemporary modeling languages w.r.t. The modeling of business data. Overall, this preliminary empirical study confirms the necessity of data-awareness in process modeling notations in general

    Ontology-based patterns for the integration of business processes and enterprise application architectures

    Get PDF
    Increasingly, enterprises are using Service-Oriented Architecture (SOA) as an approach to Enterprise Application Integration (EAI). SOA has the potential to bridge the gap between business and technology and to improve the reuse of existing applications and the interoperability with new ones. In addition to service architecture descriptions, architecture abstractions like patterns and styles capture design knowledge and allow the reuse of successfully applied designs, thus improving the quality of software. Knowledge gained from integration projects can be captured to build a repository of semantically enriched, experience-based solutions. Business patterns identify the interaction and structure between users, business processes, and data. Specific integration and composition patterns at a more technical level address enterprise application integration and capture reliable architecture solutions. We use an ontology-based approach to capture architecture and process patterns. Ontology techniques for pattern definition, extension and composition are developed and their applicability in business process-driven application integration is demonstrated

    An Ontological Basis for Design Methods

    Get PDF
    This paper presents a view of design methods as process artefacts that can be represented using the function-behaviour-structure (FBS) ontology. This view allows identifying five fundamental approaches to methods: black-box, procedural, artefact-centric, formal and managerial approaches. They all describe method structure but emphasise different aspects of it. Capturing these differences addresses common terminological confusions relating to methods. The paper provides an overview of the use of the fundamental method approaches for different purposes in designing. In addition, the FBS ontology is used for developing a notion of prescriptiveness of design methods as an aggregate construct defined along four dimensions: certainty, granularity, flexibility and authority. The work presented in this paper provides an ontological basis for describing, understanding and managing design methods throughout their life cycle. Keywords: Design Methods; Function-Behaviour-Structure (FBS) Ontology; Prescriptive Design Knowledge</p

    An Exploratory Study of Forces and Frictions affecting Large-Scale Model-Driven Development

    Full text link
    In this paper, we investigate model-driven engineering, reporting on an exploratory case-study conducted at a large automotive company. The study consisted of interviews with 20 engineers and managers working in different roles. We found that, in the context of a large organization, contextual forces dominate the cognitive issues of using model-driven technology. The four forces we identified that are likely independent of the particular abstractions chosen as the basis of software development are the need for diffing in software product lines, the needs for problem-specific languages and types, the need for live modeling in exploratory activities, and the need for point-to-point traceability between artifacts. We also identified triggers of accidental complexity, which we refer to as points of friction introduced by languages and tools. Examples of the friction points identified are insufficient support for model diffing, point-to-point traceability, and model changes at runtime.Comment: To appear in proceedings of MODELS 2012, LNCS Springe
    • …
    corecore