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

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

[서평]「The Unified Modeling Language User Guide」

Will Tracz, our esteemed editor and Used-Program salesman, has written an entertaining, non-technical book dealing with the practice (and lack of) of software reuse. Its a collection of essays, mostly rehashed (reused?) and updated from various columns and papers published over the years.. Its a short (a bit over 200 pages) easy reading and enjoyable book (I read most of it in one sitting). Some of the essays discuss what was printed in the past and a discussion of the current status of the points.

Safeware: System Safety and Computers

Use cases have become increasingly common during requirements engineering, but they offer limited support for eliciting security threats and requirements. At the same time, the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. This paper presents a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines. The approach extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.

Eliciting security requirements with misuse cases

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.

/pdf/engineering-security-requirements-567knl1k0h.pdf

Engineering Security Requirements

Although use cases are a popular modeling approach for engineering functional requirements, they are often misused when it comes to engineering security requirements because requirements engineers unnecessarily specify security architectural mechanisms instead of security requirements. After discussing the relationships between misuse cases, security use cases, and security mechanisms, this column provides examples and guidelines for properly specifying essential (i.e., requirements-level) security use cases.

Security Use Cases.

Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them. Then, I will discuss the value of reusable parameterized templates for specifying security requirements and provide an example of such a template and its associated usage. Finally, I will outline an asset-based riskdriven analysis approach for determining the appropriate actual parameters to use when reusing such parameterized templates to specify security requirements.

/pdf/specifying-reusable-security-requirements-34ezckv3us.pdf

Specifying Reusable Security Requirements

: This technical note presents a consistent set of information models that identify and define the foundational concepts underlying safety, security, and survivability engineering. In addition, it shows how quality requirements are related to quality factors, subfactors, criteria, and metrics, and it emphasizes the similarities between the concepts that underlie safety, security, and survivability engineering. The information models presented in this technical note provide a standard terminology and set of concepts that explain the similarities between the asset-based, risk-driven methods for identifying and analyzing safety, security, and survivability requirements as well as a rationale for the similarity in architectural mechanisms that are commonly used to fulfill these requirements.

/pdf/common-concepts-underlying-safety-security-and-survivability-1oly1kah38.pdf

Donald Firesmith

Papers

Engineering Security Requirements

Security Use Cases.

Specifying Reusable Security Requirements

Common Concepts Underlying Safety, Security, and Survivability Engineering

The open process framework : an introduction