networks [1][18]. Those networks include both those occurring in nature, for example, neuron activity, cellular metabolisms, protein folding and social As software systems become larger and more networks, and those created by people, for example, complex, in order to understand, manage and evolve electricity supply networks, the web and the internet. these systems, we need better ways of characterizing Even though they represent totally different types of and controlling their macroscopic properties. We systems, they share many common properties such as suggest complex network theory may be useful for power-law degree distribution [1], small world these purposes. In recent years, researchers have property [19] and high level of clustering [2][3]. The shown that many complex systems from different similarity between different complex networks inspires disciplines can be investigated as complex networks the idea that network growth mechanisms represent and most of them comply with a scale-free network some basic natural tendency to create order from model. We explore the view that a software system can chaos. be studied as a network with a number of components (classes) connected by dependency (integration) The recent progress in complex network theory relationships; we call this network the Component motivates us to study software systems as complex Dependency Network (CDN). The CDNs of several networks. A software system can be treated as a Java libraries and applications have been examined network of components connected by dependency and all of them exhibit some scale-free characteristics. relationships [7]. The importance of relationship is This result has some practical value including that it stressed by the Object-Attribute-Relation (OAR) model allows us to identify important components (classes) [4], which shows that human memory and knowledge and thereby assists software maintenance and are represented by connections of synapses between reengineering. We have built a tool to study software neurons, rather than by the neurons themselves [5]. systems as complex networks. In the paper we also Similarly, for software systems, some high level suggest ways of controlling and changing how systems functions are realized by the relationships of low level evolve in order to improve theirunderstandability and components. In this paper, the term component maintainability, indicates an abstract form of software or even hardware entities as in the behavior tree approach [6].

No abstract

No abstract

We know that students solve problems in different ways, but we know little about the kinds of variation, or the degree of variation between these student generated solutions. In this paper, we propose a taxonomy that classifies the variation between correct student solutions in objective terms, and we show how the application of the taxonomy provides instructors with additional insight about the differences between student solutions. This taxonomy may be used to inform instructors in selecting examples of code for teaching purposes, and provides the possibility of automatically applying the taxonomy to existing solution sets.

A growing number of empirical software engineering researchers suggest that a complementary focus on theory is required if the discipline is to mature. A first step in theory-building involves the establishment of suitable theoretical constructs. For researchers studying software projects, the lack of a theoretical construct for context is problematic for both experimentation and effort estimation. For experiments, insufficiently understood contextual factors confound results, and for estimation, unstated contextual factors affect estimation reliability. We have earlier proposed a framework that we suggest may be suitable as a construct for context i.e. represents a minimal, spanning set for the space of software contexts. The framework has six dimensions, described as Who, Where, What, When, How and Why. In this paper, we report the outcomes of a pilot study to test its suitability by categorising contextual factors from the software engineering literature into the framework. We found that one of the dimensions, Why, does not represent context, but rather is associated with objectives. We also identified some factors that do not clearly fit into the framework and require further investigation. Our contributions are the pursuing of a theoretical approach to understanding software context, the initial establishment and evaluation of a construct for context and the exposure of a lack of clarity of meaning in many 'contexts' currently applied as factors for estimating project outcomes.