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

Many scientific disciplines are now data and information driven, and new scientific knowledge is often gained by scientists putting together data analysis and knowledge discovery “pipelines”. A related trend is that more and more scientific communities realize the benefits of sharing their data and computational services, and are thus contributing to a distributed data and computational community infrastructure (a.k.a. “the Grid”). However, this infrastructure is only a means to an end and scientists ideally should be bothered little with its existence. The goal is for scientists to focus on development and use of what we call scientific workflows. These are networks of analytical steps that may involve, e.g., database access and querying steps, data analysis and mining steps, and many other steps including computationally intensive jobs on high performance cluster computers. In this paper we describe characteristics of and requirements for scientific workflows as identified in a number of our application projects. We then elaborate on Kepler, a particular scientific workflow system, currently under development across a number of scientific data management projects. We describe some key features of Kepler and its underlying Ptolemyii system, planned extensions, and areas of future research. Kepler is a communitydriven, open source project, and we always welcome related projects and new contributors to join.

/pdf/scientific-workflow-management-and-the-kepler-system-5a9uicngu7.pdf

Scientific Workflow Management and the Kepler System

Numerical Initial Value Problems in Ordinary Differential Equations

Modern embedded computing systems tend to be heterogeneous in the sense of being composed of subsystems with very different characteristics, which communicate and interact in a variety of ways-synchronous or asynchronous, buffered or unbuffered, etc. Obviously, when designing such systems, a modeling language needs to reflect this heterogeneity. Today's modeling environments usually offer a variant of what we call amorphous heterogeneity to address this problem. This paper argues that modeling systems in this manner leads to unexpected and hard-to-analyze interactions between the communication mechanisms and proposes a more structured approach to heterogeneity, called hierarchical heterogeneity, to solve this problem. It proposes a model structure and semantic framework that support this form of heterogeneity, and discusses the issues arising from heterogeneous component interaction and the desire for component reuse. It introduces the notion of domain polymorphism as a way to address these issues.

/pdf/taming-heterogeneity-the-ptolemy-approach-v4qpoppcbo.pdf

Taming heterogeneity - the Ptolemy approach

The Ptolemy project studies heterogeneous modeling and design of concurrent systems. Th is on embedded systems , particularly those that mix technologies, including for example analog a digital electronics, hardware and software, and electronics and mechanical devices (including M microelectromechanical systems). The focus is also on systems that are complex in the sense t mix widely different operations, such as signal processing, feedback control, sequential decision ing, and user interfaces. Modelingis the act of representing a system or subsystem formally. A model might be mathe cal, in which case it can be viewed as a set of assertions about properties of the system such as tionality or physical dimensions. A model can also be constructive, in which case it defin computational procedure that mimics a set of properties of the system. Constructive models ar used to describe behavior of a system in response to stimulus from outside the system. Cons models are also called executable models. Designis the act of defining a system or subsystem. Usually this involves defining one or m models of the system and refining the models until the desired functionality is obtained within a constraints. Design and modeling are obviously closely coupled. In some circumstances, models m immutable, in the sense that they describe subsystems, constraints, or behaviors that are ex imposed on a design. For instance, they may describe a mechanical system that is not under des must be controlled by an electronic system that is under design. Executable models are sometimes called simulations, an appropriate term when the executab model is clearly distinct from the system it models. However, in many electronic systems, a mode starts as a simulation mutates into a software implementation of the system. The distinction be the model and the system itself becomes blurred in this case. This is particularly true for emb software.

/pdf/overview-of-the-ptolemy-project-105cn2y1j9.pdf

Overview of the Ptolemy project

: The Ptolemy project studied heterogeneous modeling, simulation, and design of concurrent systems. The focus is on embedded systems, particularly those that mix technologies including, for example, analog and digital electronics, hardware and software, and electronics and mechanical devices (including MEMS, microelectromechanical systems). The focus is also on systems that are complex in the sense that they mix widely different operations such as signal processing, feedback control, sequential decision making, and user interfaces.

Ptolemy II, Heterogeneous Concurrent Modeling and Design in JAVA

: This volume describes how to construct Ptolemy II models for web-based modeling or building applications. The first chapter includes an overview of Ptolemy II software, and a brief description of each of the models of computation that have been implemented. It describes the package structure of the software, and includes as an appendix a brief tutorial on UML notation, which is used throughout the documentation to explain the structure of the software. The second chapter is a tutorial on building models using Vergil, a graphical user interface where models are built pictorially. The third chapter discusses the Ptolemy II expression language, which is used to set parameter values. The next chapter gives an overview of actor libraries. These three chapters, plus one of the domain chapters, will be sufficient for users to start building interesting models in the selected domain. The fifth chapter gives a tutorial on designing actors in Java. The sixth chapter describes the Ptolemy coding style, The seventh chapter explains MoML, the XML schema used by Vergil to store models. And the eighth chapter, the final one in this part, explains how to construct custom applets. Volume 2 describes the software architecture of Ptolemy II, and volume 3 describes the domains, each of which implements a model of computation.

/pdf/heterogeneous-concurrent-modeling-and-design-in-java-volume-21xanbzpxb.pdf

Heterogeneous Concurrent Modeling and Design in Java (Volume 1: Introduction to Ptolemy II)

: This volume describes the software architecture of Ptolemy II. The first chapter covers the kernel package, which provides a set of Java classes supporting clustered graph topologies for models. Cluster graphs provide a very general abstract syntax for component-based modeling, without assuming or imposing any semantics on the models. The actor package begins to add semantics by providing basic infrastructure for data transport between components. The data package provides classes to encapsulate the data that is transported. It also provides an extensible type system and an interpreted expression language. The graph package provides graph-theoretic algorithms that are used in the type system and by schedulers in the individual domains. The model transformation package provides a mechanism to systematically transform models by means of graph rewriting. The plot package provides a visual data plotting utility that is used in many of the applets and applications. The codegen package is a templated based code generator similar to the Ptolemy Classic code generators. The copernicus package is a code generator that performs static analysis on Java class files to produce smaller, faster executable models. Volume 1 gives an introduction to Ptolemy II, including tutorials on the use of the software, and volume 3 describes the domains, each of which implements a model of computation.

Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture)

: This volume describes Ptolemy II domains. The domains implement models of computation, which are summarized in chapter 1. Most of these models of computation can be viewed as a framework for component- based design, where the framework defines the interaction mechanism between the components. Some of the domains (CSP, Rendezvous, DDE, and PN) are thread-oriented, meaning that the components implement Java threads. These can be viewed, therefore, as abstractions upon which to build threaded Java programs. These abstractions are much easier to use (much higher level) than the raw threads and monitors of Java. Others (CT, DE, SDF) of the domains implement their own scheduling between actors, rather than relying on threads. This usually results in much more efficient execution. The Giotto domain, which addresses real-time computation, is not threaded, but has concurrency features similar to threaded domains. The FSM domain is in a category by itself, since in it, the components are not producers and consumers of data, but rather are states. The non-threaded domains are described first, followed by FSM and Giotto, then the threaded domains followed by two newer domains, HDF and DDF. Volume 1 is an introduction to Ptolemy II, including tutorials on use of the software, and volume 2 describes the Ptolemy II software architecture.

/pdf/heterogeneous-concurrent-modeling-and-design-in-java-volume-bur4po4evq.pdf

Heterogeneous Concurrent Modeling and Design in Java (Volume 3: Ptolemy II Domains)

ion and modu-larity mechanisms for concurrent computing.

http://ptolemy.eecs.berkeley.edu/publications/papers/98/HMAD/design011.pdf

Jeff Tsay

Papers

Ptolemy II, Heterogeneous Concurrent Modeling and Design in JAVA

Heterogeneous Concurrent Modeling and Design in Java (Volume 1: Introduction to Ptolemy II)

Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture)

Heterogeneous Concurrent Modeling and Design in Java (Volume 3: Ptolemy II Domains)

Heterogeneous concurrent modeling and design