bluuebunny/crossref_metadata_2025_split huggingface dataset:
Component‐Based Systems
Authors: Weide Bruce W. 
Published: February 2015

AbstractHuman‐engineered physical devices such as cars and appliances and computers, as well as naturally occurring physical objects such as forests and galaxies and nerve bundles, are often called “systems.” Both this word and the thinking that underlies it are crucial features of modern software engineering as well. Software systems, however, are purely symbolic entities that have meaning and intellectual interest even without a physical manifestation. Component‐based systems in physical engineering and in software engineering therefore have many common features, yet differ in important and sometimes subtle ways.The characteristics of component‐based software engineering as currently practiced can be approached from two different perspectives. One explanation is based on the relationship to fundamental principles of system design. In this view, the key features of component‐based software engineering could have developed simply as inevitable consequences of applying general “system thinking” to software systems. Another explanation is based on observing the history of two related branches of software engineering research. In this view, the key features of component‐based software engineering actually have resulted from a melding of the concurrent but curiously separate activities of two communities: advances in software reuse research and common off‐the‐shelf (COTS) component technology, and advances in object‐oriented (OO) technology.This article begins by exploring the fundamental similarities and differences between component‐based systems in the physical world and those in the software world. It then uses that analysis and a summary of component‐based software research as a basis for understanding the currently unfolding transition from second‐generation to third‐generation OO technology: the integration of component‐based software concepts into modern software practice, which relies on the identification and use of “objects”.
Concurrency in Software Engineering
Authors: Axford Tom 
Published: February 2015

AbstractConcurrency in software engineering means the collection of techniques and mechanisms that enable a computer program to perform several different tasks simultaneously, or apparently simultaneously. The need for concurrency in software first arose in the very early days of computing. Although early computers were very much slower than modern machines, their peripheral devices (such as paper tape or punched‐card readers for input, and teletypewriters for output) were much slower still, and it was soon recognized that many programs could be made to run very much faster if they did not spend so much time waiting for input/output (I/O). The solution is easy in principle—simply allow I/O transfers to be performed concurrently with each other and with normal computation (i.e., computation involving only the central processor). To achieve this, new features needed to be added to both hardware and software.Today, such features—concurrency mechanisms, the most important of which are discussed in this article—are commonplace and form a vital part of all modern computer systems. The operating system of any computer (e.g., Windows, UNIX, Linux) makes use of concurrency to enable the user to do several different things simultaneously or to allow many different users to access the computer at the same time. Many operating systems allow a large number of tasks to be run concurrently and the simultaneous use of peripheral devices. The earliest applications of concurrency were in real‐time systems such as operating systems, in which the software must perform actions at times determined by external events.
Interoperability Testing of Integrated Communication Software Systems
Authors: Lee David 
Published: February 2015

AbstractInteractive graphics offers the software engineer a set of powerful tools for the creation of user interfaces that can convey information in a clear, direct manner. The applications are large in number and highly diverse. The engineer now uses interactive graphics to design and test components for anything from car body frames to silicon chips, the businessperson uses it to look at financial summaries and predictions, the scientist uses it to look at molecules to determine whether they will react, filmmakers use it to create special effects, advertisers use it to animate inanimate objects, and airline pilots use it to learn how to fly. It is also the basis of modern instrumentation systems and a host of games, from cheap children's toys to the virtual reality devices which are now appearing in entertainment parks.The software implementing interactive graphics systems can best be described using three levels of abstraction, namely the functional, procedural and device levels.
Data Flow Analysis and Design
Authors: Stevens Wayne P. 
Published: February 2015

Abstract
Data flow is the name applied when data are passed from one thing to another. The “thing” that passes the data can include a piece of software or an application, a computer or a region in a computer, a person, group, or organizational unit, or combinations of these. The data passed can be simple or complex and it can be passed as a stream or a unit. A diagram that depicts objects or processes and the possible flows of data among them is called a data flow diagram (DFD). DFDs are useful for depicting information about how an organization operates; the interfaces between an application and the people or other applications that use it; and the high‐level design of an application. DFDs have been used in application development for a long time.

There are two alternatives to (pure) data flow and each alternative has substantial disadvantages when used to link software components. One of these alternatives to data flow is for the data
not
to flow; that is, have various software modules access it directly in shared common data areas. A second alternative to pure data flow is the “call” statement, used in most languages to link subroutines. The call statement has two substantial limitations versus pure data flow: it also passes control and it explicitly names the target subroutine.

In today's application development methodologies, DFDs are important for: analyzing organizational units; depicting the context of an application relative to users and other applications; designing the high level (process) architecture of applications; showing the interfaces between application processes and data stores; and documenting batch job streams. DFDs are likely to be increasingly important for designing distributed systems, object‐oriented design, depicting asynchronous components, and for reusable code. An examination of each is given.
Data Modeling
Authors: Appleton Daniel S. 
Published: February 2015

Abstract

Any organization, whether a business, a government agency, a religion, a family, or any functional human unit, is a jungle of transactions, and these transactions are 99% logical. The vast majority of these transactions are
messages
sent from senders to receivers. The relationship between these two roles is crucial. A sender does not really know if a message it sends has any value to a receiver. From the standpoint of a receiver, each message it receives falls into one of two categories. If the message resolves some uncertainty in the receiver, or, if it adds to the receiver's knowledge or stimulates action, it is an
information message.
If it does none of these things, it is a
noise message
. Information messages, are positive forces in an organization, whereas noise messages are negative forces. The ratio of information messages received to all messages sent is the measure of the information quality of an organization. As this ratio approaches 1, the efficiency and effectiveness of the organization become optimum. This logic commutes the idea of
information
from a passive concept in organizational theory, to an active force for organizational growth and survival.

It is entirely presumptuous to assume that a sender can know for sure whether a message it sends will be an information message or a noise message to a receiver. At best, the sender can only work to increase the
probability
that its messages will be information messages and not noise messages. And this is where management must focus its attention. A primary aspiration of organizational management must be to increase information quality in the organization by concentrating on increasing the probability that messages sent from its senders to its receivers will be information messages and not noise messages. The question then becomes: “How do we increase the probability of information messages?” The answer, as we shall see, lies in an information engineering technology called Data Modeling.

This article covers three aspects of data modeling. First it will cover why we data‐model. Then it will present a sample data modeling technique, and examine how data models are built. Finally, it will discuss nine different applications of data modeling.
Domain Engineering
Authors: Czarnecki Krzysztof 
Published: February 2015

AbstractDomain engineering(DE) is the systematic process of collecting, organizing, and storing past experience in building systems in a particular domain. This experience is captured in the form of reusable assets (i.e., reusable work products), such as documents, patterns, reusable models, components, generators, and domain‐specific languages. An additional goal of DE is to provide an infrastructure for reusing these assets (e.g., retrieval, qualification, dissemination, adaptation, and assembly) during application engineering, i.e., the process of building new systems.By definition, DE focuses on system families rather than single systems. This focus sets it apart from the more traditional software development models, which are geared toward developing one‐of‐a‐kind systems. As a result, DE is the approach of choice for developing product lines and system families, component libraries, frameworks, domain‐specific languages, and generators.Similar to the traditional single‐system software engineering, DE also encompasses the three main process components of analysis, design, and implementation. In this context, however, they are referred to asdomain analysis,domain design, anddomain implementation. The qualifier “domain” emphasizes the multisystem scope of these activities. This article describes each of them. An example is given.
Extreme Programming (XP)
Authors: Tracz Will 
Published: February 2015

AbstracteXtreme Programming (XP) is a lightweight software development methodology based on the widely recognized and effective paradigms of code inspections, iterative spiral development, integrated product development teams (i.e., full‐time customer involvement), frequent builds, programmer teams (i.e., pair programming), design patterns, refactoring, coding standards, risk analysis, and regression testing. XP emerged from the object‐oriented programming community.XP is “extreme” in the sense that it diverges from “traditional” software development methodologies in several ways. In particular, it discourages documentation and encourages a willingness to throw code away.The XP approach to software development is targeted at systems with vague and changing requirements, a short delivery schedule, and limited resources.XP is based on four “values” that are assumed to be embraced by those participating in the software development process:Communication;Simplicity;Feedback; andCourage.
Hypertext for Software Engineering
Authors: Scacchi Walt 
Published: February 2015

AbstractWhat is the power of hypertext in supporting software engineering? (The term “hypertext” is treated throughout as synonymous with “hypermedia,” which denotes the nonlinear representation of interrelated textual, graphic, filmic, or auditory information.) Power in other contexts usually refers to the ability of some entity or agent to affect the behavior of another or to achieve advantage over another in ways that the other cannot avoid. Following this, one might expect that as atechnology, hypertext systems offer relative advantage over alternatives to automated text/document information systems, including conventional word processing systems, file systems, and database management systems.Hypertext systems offer a degree of information processing power that enables new kinds of applications, much like the advent of expert system shells enabled the creation of expert applications for domains such as computer configuration and diagnostic pathology. Similarly, as amediumfor writing and reading electronic documents hypertext systems allow the redefinition of the structure and content of documents that alter the constraints and opportunities for conveying information in contrast to the linear print medium. Thus the power of hypertext in whatever form it exists is subtle and incremental; it is potential rather than kinetic. However, such power can accumulate in different application domains in the long run if effectively mobilized and integrated with domain‐specific tasks, processing mechanisms, and workflows.The power of hypertext technology in different application domains can be realized in a number of ways. In particular, technology that supports a unified view of the hypertext documents, production processes, processing mechanisms, and settings of use appears to offer the greatest power at this time. To see this, the concept of a domain‐specific hypertext environment (DSHE) is defined in the following section. Next, the domain of software production is examined in order to identify how hypertext tools and document production/consumption techniques can play a role to facilitate software engineering objectives. The focus then shifts to describe the structure of information to evolve within a DSHE in terms of product, task, and setting information for the domain of software production. Together, these sections then set the final stage for a discussion of the power of DSHE. Subsequently, seven ways the power of DSHE can be realized are identified, followed by an examination of the costs that are borne in order to realize this power.
Information Age
Authors: Eisner Howard 
Published: February 2015

Abstract
The Information Age is a period of time, or era, in which information itself, in its various forms, constitutes a key or dominant ingredient in our delivery of products and services. The Information Age began to emerge in a most serious manner about halfway through the twentieth century, when, for the first time, white collar workers started to outnumber blue collar employees.

Advances such as successes in telegraphy, telephony, radio, television, xerography, larg scale computers, etc; provided initial fuel for the Information Age engine by proving the importance of information‐related technologies and demonstrating their economic value in the marketplace. Two additional and extremely significant sets of events included the refinement and market penetration of the personal computer (PC), along with its resident applications, and connectivity to the Internet. These events were acknowledged, in the aggregate, as “trends that were shaping the 1980s” in shifting from an industrial society to an information society. In doing so, at least four key points were considered to be critical:

The reality and influence of the information‐oriented society

Computers and communications coming together to support each other

New information technologies migrating from old industrial activities to new processes

The need for our education system to step up to difficult challenges associated with the new information orientation

These key points are discussed in this article.
Jackson Development Methods
Authors: Jackson Michael 
Published: February 2015

AbstractThe Jackson Development Methods are JSP (Jackson Structured Programming) and JSD (Jackson System Development). JSP is a method for designing programs as compositions of sequential processes; JSD is a method for specifying and designing systems whose application domain has a strong temporal flavor and contains objects whose behavior is describable in terms of sequences of events. Many program and system development problems thus fall within the scope of JSP and JSD and these methods have been used to develop data processing systems, control systems, systems software, embedded systems, and even a music synthesizer.JSP and JSD differ from some widely used methods in two main respects. First, unlike other methods, they pay attention initially to the domain of the software and only later to the software itself. Their first describe not the software, but its subject matter. Second, they focus on time‐ordering: on event sequencing rather than on static data models. For a JSP program, the domain is the time‐ordered streams of records or of events that the program must process. For a JSD system, the domain is the real world in which the entities exhibit concurrent time‐ordered behaviors that the system must model and compute about. If JSD entities are regarded as objects, JSD may be said to be object‐oriented.The basic idea is to describe the structures of the sequential streams as regular languages and to form the structure of the program by composing the stream languages into one superset regular language.Program inversion technique is an important element in the progression from JSP to JSD. Two other important elements are the recognition and resolution of interleaving clashes and an implementation technique—state‐vector separation—used to deal with the resulting multiplicity of processes.The development steps of JSD as originally formulated are six: the entity action step; the entity structure step; the initial model step; the function step; the system timing step; and the implementation step.These steps were later modified and rearranged into three development phases: the modeling phase; the network phase; and The implementation phase.Explanation here follows the broad lines of this later formulation and also draws on some later refinements and elaborations of the method.
Knowledge Bases
Authors: Pease Adam , Liuzzi Raymond A. , Gunning David 
Published: February 2015

AbstractIn this article we present an overview of knowledge‐based systems. We begin by discussing the basic characteristics of knowledge base rules and present an example comparing a toy knowledge base to an equivalent procedural version of the same code. We then discuss the applications for which it makes sense to use knowledge‐based technology and the advantages offered by reuse of a general‐purposeupper ontology. Next we describe important research and applications in both knowledge representation and knowledge‐based systems. We then describe how work in philosophy and other research has had an impact on knowledge‐based systems. We conclude with thoughts on where the field is heading.
Linux
Authors: Bollinger Terry 
Published: February 2015

Abstract

Linux
(pronounced LIN‐ucks) is the common name for any well‐defined collection of system and application software (a
distribution
) that uses the UNIX‐like
Linux kernel
for its basic operating system services, such as process control, memory allocation, device management, file access, and networking. To qualify as a Linux distribution, such a collection of software must also consist entirely or almost entirely of freely redistributable, public‐source software, which is variously known as
free
,
open
, or sometimes
libre
software. Linux is most commonly used on Intel x86/Pentium‐based personal computers (PCs), but it has also been ported to a large and growing non‐x86 computers of diverse ages, sizes, and capabilities. Linux is notable for having achieved a level of public awareness and stockmarket notice second only to Microsoft Windows.

This article discusses the history of Linux, the design of the Linux kernel, Linux development, the role of Linux distributions, and possible future directions of this intriguing operating system.
Model‐Based Software Testing
Authors: El‐Far Ibrahim K. , Whittaker James A. 
Published: February 2015

AbstractThere 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 dubbedmodel‐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.
Video and Multimedia Indexing
Authors: Aref Walid G. , McIver William J. , Al‐Khatib Wasfi , Ghafoor Arif , Bruce Berra P. 
Published: February 2015

AbstractWith the continuous evolution of telecommunication and computing technologies, more and more repositories of digital video data are being developed to support a wide range of applications in digital libraries, telemedicine, distance learning, tourism, entertainment, etc. With the rapid proliferation of the Web, these applications are rapidly emerging. Content‐based retrieval of video data has been the subject of extensive research since 1990. Because of the huge volume of data, it becomes crucial to develop indexing techniques that will carry out the process of content‐based retrieval more efficiently.The problem of video indexing is to create and maintain index structures and algorithms that support the efficient execution of queries about the contents of video presentations. Such queries may ask about features of objects or regions contained within a video, or relationships between objects or regions contained within a video. Additionally, queries may concern these features or relationships in relation to time. The spatial and temporal aspects of video indexing taken separately are nontrivial problems. Each type of indexing has been studied widely, and many research problems remain. Indexing of video, however, must be differentiated from spatial, temporal, and spatiotemporal indexing techniques in that information to be indexed may include not only spatiotemporal information, but possibly highly dimensional feature data such as texture, textual closed captioning information, shape, color histograms, and object trajectories or animation operations. A video indexing technique must, therefore, support efficient searches for objects and images on the basis of the three major facets of a video: its spatial, temporal, and feature values.A simple multimedia object model is presented to provide a common reference point for discussing multimedia indexing in the remainder of this chapter. The model is contained in the following definitions discussed.