National Institute of Standards and Technology における超伝導研究及び生活

• Business process reengineering-the redesign of an organization's business processes to make them more efficient. • Coordination technology-an aid to managing dependencies among the agents within a business process, and provides automated support for the most routinized component processes. * Process-driven software development environments-an automated system for integrating the work of all software related management and staff; it provides embedded support for an orderly and defined software development process. These three applications share a growing requirement to represent the processes through which work is accomplished. To the extent that automation is involved, process representation becomes a vital issue in redesigning work and allocating responsibilities between humans and computers. This requirement reflects the growing use of distributed , networked systems to link the interacting agents responsible for executing a business process. To establish process modeling as a unique area, researchers must identify conceptual boundaries that distinguish their work from model-ing in other areas of information science. Process modeling is distinguished from other types of model-ing in computer science because many of the phenomena modeled must be enacted by a human rather than a machine. At least some mod-eling, however, in the area of human-machine system integration or information systems design has this 'human-executable' attribute. Rather than focusing solely on the user's behavior at the interface or the flow and transformation of data within the system, process model-ing also focuses on interacting behaviors among agents, regardless of whether a computer is involved in the transactions. Much of the research on process modeling has been conducted on software development organizations , since the software engineering community is already accustomed to formal modeling. Software process modeling, in particular , explicitly focuses on phenomena that occur during software creation and evolution, a domain different from that usually mod-eled in human-machine integration or information systems design. Software development is a challenging focus for process modeling because of the creative problem-solving involved in requirements analysis and design, and the coordination of team interactions during the development of a complex intellectual artifact. In this article, software process modeling will be used as an example application for describing the current status of process modeling, issues for practical use, and the research questions that remain ahead. Most software organizations possess several yards of software life cycle description, enough to wrap endlessly around the walls of project rooms. Often these descriptions do not correspond to the processes actually performed during software …

Process modeling

Existing models for describing a process (such as a business process or a software development process) tend to focus on the "what" or the "how" of the process. For example, a health insurance claim process would typically be described in terms of a number of steps for assessing and approving a claim. In trying to improve or redesign a process, however, one also needs to have an understanding of the "why"--for example, why do physicians submit treatment plans to insurance companies before giving treatment? and why do claims managers seek medical opinions when assessing treatment plans? An understanding of the motivations and interests of process participants is often crucial to the successful redesign of processes.
This thesis proposes a modelling framework i* (pronounced i-star) consisting of two modelling components. The Strategic Dependency (SD) model describes a process in terms of intentional dependency relationships among agents. Agents depended on each other for goals to be achieved, tasks to be performed, and resources to be furnished. Agents are intentional in that they have desires and wants, and strategic in that they are concerned about opportunities and vulnerabilities. The Strategic Rationale (SR) model describes the issues and concerns that agents have about existing processes and proposed alternatives, and how they might be addressed, in terms of a network of means-ends relationships. An agent's routines for carrying out a process can be analyzed for their ability, workability, viability and believability. Means-ends rules are used to suggest methods for addressing issues, related issues to be raised, and assumptions to be challenged. The models are represented in the conceptual modelling language Telos. The modelling concepts are axiomatically characterized.
The utility of the framework is illustrated each of four application areas: requirements engineering, business process reengineering, organizational impacts analysis, and software process modelling. Advantage of i* over existing modelling techniques in each of these areas are described.

Modelling strategic relationships for process reengineering

The Object Management Group's (OMG) Model Driven Architecture (MDA) strategy envisages a world where models play a more direct role in software production, being amenable to manipulation and transformation by machine. Model Driven Engineering (MDE) is wider in scope than MDA. MDE combines process and analysis with architecture. This article sets out a framework for model driven engineering, which can be used as a point of reference for activity in this area. It proposes an organisation of the modelling 'space' and how to locate models in that space. It discusses different kinds of mappings between models. It explains why process and architecture are tightly connected. It discusses the importance and nature of tools. It identifies the need for defining families of languages and transformations, and for developing techniques for generating/configuring tools from such definitions. It concludes with a call to align metamodelling with formal language engineering techniques.

Model Driven Engineering

Software systems dealing with distributed applications in changing environments normally require human supervision to continue operation in all conditions. These (re-)configuring, troubleshooting, and in general maintenance tasks lead to costly and time-consuming procedures during the operating phase. These problems are primarily due to the open-loop structure often followed in software development. Therefore, there is a high demand for management complexity reduction, management automation, robustness, and achieving all of the desired quality requirements within a reasonable cost and time range during operation. Self-adaptive software is a response to these demands; it is a closed-loop system with a feedback loop aiming to adjust itself to changes during its operation. These changes may stem from the software system's self (internal causes, e.g., failure) or context (external events, e.g., increasing requests from users). Such a system is required to monitor itself and its context, detect significant changes, decide how to react, and act to execute such decisions. These processes depend on adaptation properties (called self-a properties), domain characteristics (context information or models), and preferences of stakeholders. Noting these requirements, it is widely believed that new models and frameworks are needed to design self-adaptive software. This survey article presents a taxonomy, based on concerns of adaptation, that is, how, what, when and where, towards providing a unified view of this emerging area. Moreover, as adaptive systems are encountered in many disciplines, it is imperative to learn from the theories and models developed in these other areas. This survey article presents a landscape of research in self-adaptive software by highlighting relevant disciplines and some prominent research projects. This landscape helps to identify the underlying research gaps and elaborates on the corresponding challenges.

/pdf/self-adaptive-software-landscape-and-research-challenges-4rt6vhdmq2.pdf

Self-adaptive software: Landscape and research challenges

In November 2004, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named the Architecture Analysis & Design Language (AADL). The AADL is a modeling language that supports early and repeated analyses of a system's architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics.

The language employs formal modeling concepts for the description and analysis of application system architectures in terms of distinct components and their interactions. It includes abstractions of software, computational hardware, and system components for (a) specifying and analyzing real-time embedded and high dependability systems, complex systems of systems, and specialized performance capability systems and (b) mapping of software onto computational hardware elements.

The AADL is especially effective for model-based analysis and specification of complex real-time embedded systems. This technical note is an introduction to the concepts, language structure, and application of the AADL.

/pdf/the-architecture-analysis-design-language-aadl-an-5dwgofrstm.pdf

The Architecture Analysis & Design Language (AADL): An Introduction

: The U. S. Department of Defense (DoD) has a goal of information dominance to achieve and exploit superior collection, fusion, analysis, and use of information to meet mission objectives. This goal depends on increasingly complex systems characterized by thousands of platforms, sensors, decision nodes, weapons, and warfighters connected through heterogeneous wired and wireless networks. These systems will push far beyond the size of today s systems and systems of systems by every measure: number of lines of code; number of people employing the system for different purposes; amount of data stored, accessed, manipulated, and refined; number of connections and interdependencies among software components; and number of hardware elements. They will be ultra-largescale (ULS) systems. The sheer scale of ULS systems will change everything. ULS systems will necessarily be decentralized in a variety of ways, developed and used by a wide variety of stakeholders with conflicting needs, evolving continuously, and constructed from heterogeneous parts. People will not just be users of a ULS system; they will be elements of the system. Software and hardware failures will be the norm rather than the exception. The acquisition of a ULS system will be simultaneous with its operation and will require new methods for control. These characteristics are beginning to emerge in today s DoD systems of systems; in ULS systems they will dominate. Consequently, ULS systems will place unprecedented demands on software acquisition, production, deployment, management, documentation, usage, and evolution practices.

/pdf/ultra-large-scale-systems-the-software-challenge-of-the-23wh4oixng.pdf

Ultra-Large-Scale Systems: The Software Challenge of the Future

A core set of concepts for the software process is defined. These concepts are intended to facilitate communications and to provide a framework for further definitions. The definitions focus on essential concepts; however, they do not represent a comprehensive glossary of common software process terms. Following an initial overview, the basic process concepts which underlie the definitions are outlined. The definitions are grouped in four sets: a framework for process definition, an engineering of process, an enactment of process, and process properties. The use of these concepts in several domains is illustrated. Some observations on the definition process are offered. >

Software process development and enactment: concepts and definitions

Conventional build-then-test practices are making todays embedded, software-reliant systems unaffordable to build. In response, more than thirty leading industrial organizations have joined SAE (formerly, the Society of Automotive Engineers) to define the SAE Architecture Analysis & Design Language (AADL) AS-5506 Standard, a rigorous and extensible foundation for model-based engineering analysis practices that encompass software system design, integration, and assurance. Using AADL, you can conduct lightweight and rigorous analyses of critical real-time factors such as performance, dependability, security, and data integrity. You can integrate additional established and custom analysis/specification techniques into your engineering environment, developing a fully unified architecture model that makes it easier to build reliable systems that meet customer expectations. Model-Based Engineering with AADL is the first guide to using this new international standard to optimize your development processes. Coauthored by Peter H. Feiler, the standards author and technical lead, this introductory reference and tutorial is ideal for self-directed learning or classroom instruction, and is an excellent reference for practitioners, including architects, developers, integrators, validators, certifiers, first-level technical leaders, and project managers. Packed with real-world examples, it introduces all aspects of the AADL notation as part of an architecture-centric, model-based engineering approach to discovering embedded software systems problems earlier, when they cost less to solve. Throughout, the authors compare AADL to other modeling notations and approaches, while presenting the language via a complete case study: the development and analysis of a realistic example system through repeated refinement and analysis. Part One introduces both the AADL language and core Model-Based Engineering (MBE) practices, explaining basic software systems modeling and analysis in the context of an example system, and offering practical guidelines for effectively applying AADL. Part Two describes the characteristics of each AADL element, including their representations, applicability, and constraints. The Appendix includes comprehensive listings of AADL language elements, properties incorporated in the AADL standard, and a description of the books example system.

Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis & Design Language

An environment is described, called Professor Marvel, that provides early error checking and answers questions about the program under development. The environment has a certain understanding of the systems being developed and how to use tools to produce software. It aids individual programmers and helps coordinate programming teams. The key components of Marvel are a database that stores data represented as objects, as in object-oriented languages, and a model of the development process that imposes a structure on programming activities. Marvel's support of insight and of opportunistic processing is discussed at length, as is the handling of side effects. A sample session is described. >

/pdf/intelligent-assistance-for-software-development-and-4o00vynn18.pdf

Peter H. Feiler

Papers

The Architecture Analysis & Design Language (AADL): An Introduction

Ultra-Large-Scale Systems: The Software Challenge of the Future

Software process development and enactment: concepts and definitions

Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis & Design Language

Intelligent assistance for software development and maintenance