Machine Learning is the study of methods for programming computers to learn. Computers are applied to a wide range of tasks, and for most of these it is relatively easy for programmers to design and implement the necessary software. However, there are many tasks for which this is difficult or impossible. These can be divided into four general categories. First, there are problems for which there exist no human experts. For example, in modern automated manufacturing facilities, there is a need to predict machine failures before they occur by analyzing sensor readings. Because the machines are new, there are no human experts who can be interviewed by a programmer to provide the knowledge necessary to build a computer system. A machine learning system can study recorded data and subsequent machine failures and learn prediction rules. Second, there are problems where human experts exist, but where they are unable to explain their expertise. This is the case in many perceptual tasks, such as speech recognition, hand-writing recognition, and natural language understanding. Virtually all humans exhibit expert-level abilities on these tasks, but none of them can describe the detailed steps that they follow as they perform them. Fortunately, humans can provide machines with examples of the inputs and correct outputs for these tasks, so machine learning algorithms can learn to map the inputs to the outputs. Third, there are problems where phenomena are changing rapidly. In finance, for example, people would like to predict the future behavior of the stock market, of consumer purchases, or of exchange rates. These behaviors change frequently, so that even if a programmer could construct a good predictive computer program, it would need to be rewritten frequently. A learning program can relieve the programmer of this burden by constantly modifying and tuning a set of learned prediction rules. Fourth, there are applications that need to be customized for each computer user separately. Consider, for example, a program to filter unwanted electronic mail messages. Different users will need different filters. It is unreasonable to expect each user to program his or her own rules, and it is infeasible to provide every user with a software engineer to keep the rules up-to-date. A machine learning system can learn which mail messages the user rejects and maintain the filtering rules automatically. Machine learning addresses many of the same research questions as the fields of statistics, data mining, and psychology, but with differences of emphasis. Statistics focuses on understanding the phenomena that have generated the data, often with the goal of testing different hypotheses about those phenomena. Data mining seeks to find patterns in the data that are understandable by people. Psychological studies of human learning aspire to understand the mechanisms underlying the various learning behaviors exhibited by people (concept learning, skill acquisition, strategy change, etc.).

Machine learning

物件導向軟體之架構(Object-Oriented Software Construction)探討

語用論(Pragmatics)を考える

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

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

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

/pdf/requirements-engineering-a-roadmap-3lcu5ikya8.pdf

Requirements engineering: a roadmap

Composite systems are generally comprised of heterogeneous components whose specifications are developed by many development participants. The requirements of such systems are invariably elicited from multiple perspectives that overlap, complement, and contradict each other. Furthermore, these requirements are generally developed and specified using multiple methods and notations, respectively. It is therefore necessary to express and check the relationships between the resultant specification fragments. We deploy multiple ViewPoints that hold partial requirements specifications, described and developed using different representation schemes and development strategies. We discuss the notion of inter-ViewPoint communication in the context of this ViewPoints framework, and propose a general model for ViewPoint interaction and integration. We elaborate on some of the requirements for expressing and enacting inter-ViewPoint relationships-the vehicles for consistency checking and inconsistency management. Finally, though we use simple fragments of the requirements specification method CORE to illustrate various components of our work, we also outline a number of larger case studies that we have used to validate our framework. Our computer-based ViewPoints support environment, The Viewer, is also briefly described. >

/pdf/a-framework-for-expressing-the-relationships-between-4k2grkojin.pdf

A framework for expressing the relationships between multiple views in requirements specification

Software development organizations often choose between alternative starting points-requirements or architectures. This invariably results in a waterfall development process that produces artificially frozen requirements documents for use in the next step in the development life cycle. Alternatively, this process creates systems with constrained architectures that restrict users and handicap developers by resisting inevitable and desirable changes in requirements. The spiral life-cycle model addresses many drawbacks of a waterfall model by providing an incremental development process, in which developers repeatedly evaluate changing project risks to manage unstable requirements and funding. An even finer-grain spiral life cycle reflects both the realities and necessities of modern software development. Such a life cycle acknowledges the need to develop software architectures that are stable, yet adaptable, in the presence of changing requirements. The cornerstone of this process is that developers craft a system's requirements and its architecture concurrently, and interleave their development.

/pdf/weaving-together-requirements-and-architectures-bbm6l3kyoc.pdf

Weaving together requirements and architectures

The development of most large and complex systems necessarily involves many people-each with their own perspectives on the system defined by their knowledge, responsibilities, and commitments. To address this we have advocated distributed development of specifications from multiple perspectives. However, this leads to problems of identifying and handling inconsistencies between such perspectives. Maintaining absolute consistency is not always possible. Often this is not even desirable since this can unnecessarily constrain the development process, and can lead to the loss of important information. Indeed since the real-world forces us to work with inconsistencies, we should formalize some of the usually informal or extra-logical ways of responding to them. This is not necessarily done by eradicating inconsistencies but rather by supplying logical rules specifying how we should act on them. To achieve this, we combine two lines of existing research: the ViewPoints framework for perspective development, interaction and organization, and a logic-based approach to inconsistency handling. This paper presents our technique for inconsistency handling in the ViewPoints framework by using simple examples. >

/pdf/inconsistency-handling-in-multiperspective-specifications-2t3q1t2e7h.pdf

Inconsistency handling in multiperspective specifications

This paper outlines a framework which supports the use of multiple perspectives in system development, and provides a means for developing and applying systems design methods The framework uses "viewpoints" to partition the system specification, the development method and the formal representations used to express the system specifications This VOSE (viewpoint-oriented systems engineering) framework can be used to support the design of heterogeneous and composite systems We illustrate the use of the framework with a small example drawn from composite system development and give an account of prototype automated tools based on the framework

/pdf/viewpoints-a-framework-for-integrating-multiple-perspectives-1p3zgn0a31.pdf

Bashar Nuseibeh

Papers

Requirements engineering: a roadmap

A framework for expressing the relationships between multiple views in requirements specification

Weaving together requirements and architectures

Inconsistency handling in multiperspective specifications

Viewpoints: a framework for integrating multiple perspectives in system development