We introduce the Progression of Early Computational Thinking (PECT) Model, a framework for understanding and assessing computational thinking in the primary grades (Grades 1 to 6). The model synthesizes measurable evidence from student work with broader, more abstract coding design patterns, which are then mapped onto computational thinking concepts.We present the results of a pilot-test study of the PECT Model in order to demonstrate its potential efficacy in detecting both differences in computational thinking among students of various ages as well as any clear overall progressions in increasing computational sophistication. Results of this sort are vital for establishing research-based and age-appropriate curricula for students in the primary grades, i.e., developing non-trivial, challenging but not overly daunting lesson plans that utilize the cognitive development stage of each grade level most effectively.

This paper presents an assessment designed to measure computational thinking skills of fourth grade students. The students in two public schools were given a set of Scratch programming challenges. The SOLO taxonomy was used to classify student programming responses based on the degree of understanding of the problem structure. The majority of fourth grade students from one school demonstrated the ability to synchronize the costume and motion of a single character sprite, as well as synchronize a basic conversation between multiple sprites. However, they struggled to integrate motion and costume changes into a multi-sprite conversation. The majority of fourth grade students from the second school, where reading and math comprehension scores fall below the state minimum requirements for proficiency, were unable to demonstrate a basic understanding of the programming tasks. The results suggest that fourth grade students who read at grade level are capable of understanding the relationships between multiple concerns within a single script, along with synchronizing a single concern across multiple scripts, but are challenged when synchronizing multiple concerns across multiple scripts.

Multi-agent systems must be engineered to ensure that desirable system-level properties will consistently emerge from the complex interactions of the underlying agents, while also guaranteeing that undesirable behavior will be suppressed. We present an Aspect-Oriented Programming (AOP) framework for modeling, visualizing and manipulating emergent structure in multi-agent systems. By encapsulating the macroscopic structure, we can identify undesirable patterns of behavior at a higher level of abstraction. The identification of such patterns allows us to implement a feedback loop to steer the behavior of the lower level agents towards actions favorable for the emergence of a reliable solution.AOP facilitates the modeling of the system-wide behavior, thus it serves as a valuable tool for building confidence that a given multi-agent system will consistently meet its requirements.

A collection of design patterns was described by Gamma, Helm, Johnson, and Vlissides in 1994. Recognizing that designs change, each pattern ensures that a certain system aspect can vary over time such as the operations that can be applied to an object or the algorithm of a method. The patterns are described by constructs such as the inheritance and reference relations, attempting to emulate more dynamic relationships. As a result, the design patterns demonstrate how awkward it is to program natural concepts of behavioral evolution when using a traditional object-oriented language.In this paper we present a new relation between classes: the context relation. It directly supports behavioral evolution, and it is meaningful at the analysis, design, and implementation level. At the design level we picture a context relation as a new form of arrow between classes. At the implementation level we use a small extension of C++. The basic idea is that if class C is context-related to a base class B, then B-objects can get their functionality dynamically altered by C-objects. Our language construct for doing this is a generalization of the method update in Abadi and Cardelli's imperative object calculus. A C-object may be explicitly attached to a B-object, or it may be implicitly attached to a group of B-objects for the duration of a method invocation. We demonstrate how the context relation can be used to easily model and program the Adapter, Bridge, Chain of Responsibility, Decorator, Iterator, Observer, State, Strategy, and Visitor patterns.

A collection of design patterns was described by Gamma, Helm, Johnson, and Vlissides in 1994. Recognizing that designs change, each pattern ensures that a certain system aspect can vary over time such as the operations that can be applied to an object or the algorithm of a method. The patterns are described by constructs such as the inheritance and reference relations, attempting to emulate more dynamic relationships. As a result, the design patterns demonstrate how awkward it is to program natural concepts of behavioral evolution when using a traditional object-oriented language.In this paper we present a new relation between classes: the context relation. It directly supports behavioral evolution, and it is meaningful at the analysis, design, and implementation level. At the design level we picture a context relation as a new form of arrow between classes. At the implementation level we use a small extension of C++. The basic idea is that if class C is context-related to a base class B, then B-objects can get their functionality dynamically altered by C-objects. Our language construct for doing this is a generalization of the method update in Abadi and Cardelli's imperative object calculus. A C-object may be explicitly attached to a B-object, or it may be implicitly attached to a group of B-objects for the duration of a method invocation. We demonstrate how the context relation can be used to easily model and program the Adapter, Bridge, Chain of Responsibility, Decorator, Iterator, Observer, State, Strategy, and Visitor patterns.