A good way to obtain secure systems is to build applications in a systematic way where security is an integral part of the lifecycle. The same applies to reliability. If we want a system which is secure and reliable, both security and reliability must be built together. If we build not only applications but also middleware and operating systems in the same way, we can build systems that not only are inherently secure but also can withstand attacks from malicious applications and resist errors. In addition, all security and reliability constraints should be defined in the application level, where their semantics is understood and propagated to the lower levels. The lower levels provide the assurance that the constraints are being followed. In this approach all security constraints are defined at the conceptual or application level. The lower levels just enforce that there are no ways to bypass these constraints. By mapping to a highly secure platform, e.g., one using capabilities, we can produce a very secure system. Our approach is based on security patterns that are mapped through the architectural levels of the system. We make a case for this approach and we present here three aspects to further develop it. These aspects include a metamodel for security requirements, a mapping of models across architectural levels, and considerations about the degree of security of the system.

It is possible to reasonably measure the security quality of individual security patterns. However, more interesting is to ask: Can we show that a system built using security patterns is secure in some sense? We discuss here some issues about evaluating the security of a system built using security patterns. We consider the use of threats and misuse patterns to perform this evaluation.

An underlying theory is a framework of goals, solutions, and assumptions that guide how we observe situations and define problems. In science, the underlying theories, like particles, waves, relativity, plate tectonics, and evolution, are well known and well understood. In process improvement, the underlying theories are not so well understood. To address that problem, we present a system of patterns. The system includes six patterns for theories that underlie many of the well known practices in process improvement. The patterns are Plan, Best Practices, Flow, Feedback, Systems Thinking, and Living System. These patterns are found in ISO 9000, PMBOK, CMMI, SPICE, Lean, TQM, Six Sigma, and Agile. Like all patterns, the patterns in this system are structural configurations that solve a problem in a context.

Sensors are widely used in everyday life in household appliances, fire alarms, traffic control systems, battlefields, banks, and museums. Sensors are used either as standalone devices or in networks. Understanding the basic structure of a sensor node is essential to be able to use the sensors in different types of devices and different kinds of environments. Many applications require different types of sensor nodes that communicate with each other to perform a specific function. We present a pattern that describes an abstract view of the architecture of a sensor node. This description would help the application designer to choose from different types of sensor nodes for his application and to integrate it with other functional units. Moreover, this model also helps the designer to reuse, combine, or modify the architecture of a node to suit more complex needs.

The three-tier architecture pattern and its variants have been around for a while and there are several discussions of their properties as well as several patterns. None of these discussions considers security. However, several real systems implement this approach including security. We revisit this pattern to explicitly separate and analyze its security aspects.

In this paper we present a method of code implementation that works in conjunction with collaboration and responsibility based analysis modeling techniques to achieve better code reuse and resilience to change. Our approach maintains a closer mapping from responsibilities in the analysis model to entities in the implementation. In so doing, it leverages the features of flexible design and design reuse found in collaboration-based design models to provide similar adaptability and reuse in the implementation. Our approach requires no special development tools and uses only standard features available in the C++ language. In an earlier paper we described the basic mechanisms used by our approach and discussed its advantages in comparison to the framework approach. In this paper we show how our approach combines code and design reuse, describing specific techniques that can be used in the development of larger applications.

Parnas' seminal 1972 paper, "On the Criteria To Be Used in Decomposing Systems into Modules," identified simplifying change as a critical criterion for modularizing software. Successful designs are those in which a change can be accommodated by modifying a single module. There is a tacit assumption in most of the literature that once a change has been limited to a single module, the cost of making the change is essentially inconsequential. But modules have complexity of their own and are frequently large. Thus, making a change can be expensive, even if limited to a single module.We present a method of decomposing modules into smaller components for the purpose of supporting change. Although similar to the approach of modularizing programs described by Parnas, our approach is specific to decomposing modules. It is not intended to replace traditional high level modularization but rather to augment it with a second level of modularization where the standard of information hiding can be relaxed. The goal of the method is to make modules easier to change by decomposing them around smaller design decisions---ideally encoding only one design choice per submodule component.In this paper we show how submodule components can be used to address the issue of change. We also demonstrate how the ability to address change with submodule components is, to a large extent, independent of the design level modularization. Moreover, we show that, at least in some cases, by using submodule components the choice of high level modularization can itself be changed without having to rewrite large amounts of code.A method of implementation is presented using inheritance, parameterization, and static binding in a way that minimizes implementation dependencies between components. The method supports fine grained decomposition with flexible composability and almost no runtime overhead.