Aspect oriented software development

Introduction
In computing, Aspect-oriented software development (AOSD) is an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic. AOSD allows multiple concerns to be expressed separately and automatically unified into working systems. Aspect-Oriented Software Development focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

Introduction
To identify aspects, Aspects are behaviours that are tangled and scattered across a system early in the software lifecycle, and establish sufficient traceability, developers need support for aspect identification and analysis in requirements documentation. To address this, Theme approach for viewing the relationships between behaviours in a requirements document, identifying and isolating aspects in the requirements and modelling those aspects using a design language has been deviced. The intent of aspect-orientation is to allow developers to encapsulate system behaviour that does not fit cleanly into the particular programming model in use.

Goals
The AOSD process needs to: be fully customizable, extensible and platform independent. be usable in a staged manner and integrated with other. guarantee quality assurance in the process and the design artifacts

Requirements
The core requirements of an AO process include the need to support: concern module design. composition specification. resolution of conflicts and cooperation between interacting concerns.

AOD Process

This model has several elements: a start and end point, activities that make up the process, decision points and transitions between activities. The start and end points are denoted by circles, the activities are illustrated as boxes and the transitions are denoted by directed arrows. Points where decisions need to be made are denoted by a black diamond.

AOD Process activities

These activities include: Concern identification and classification in this process, the inputs to the design process are analyzed and refined to validate outputs from concern identification and classification within the requirements engineering, architecture design or system specification processes. Design test(s) - in this process, the design tests are created based on models that define system behavior and structure, such as system specifications and architecture design. Design tests ensure the concern designs; composition specifications and conflict and cooperation resolution specifications are satisfactory.

AOD Process activities

Design by reuse concerns may be repetitively encountered across application design. The process of designing by reuse addresses this by allowing the designer to decontextualise concern designs they consider reusable and support reuse of previously defined concern designs. Design composition specification(s) in this process, an order for composition of concerns is defined and the description of how the concerns are to be composed to create a functioning system is defined. This activity also deals with resolving the conflict and cooperation issues that exist between concerns.

AOD Process activities

Verify when concerns and composition specifications have been designed, there needs to be some means of verifying specific properties of the design, relevant to the application.

Refine A scaleable design process needs to be capable of dealing with simple and complex systems. Complexity is typically overcome through hierarchical abstraction. We believe that a layered design process based on the recursive refinements of abstract models to more concrete models will address both cases.

Course Management System

The Course Management System (CMS) is a very small system, with nine requirements: R1. Students can register for courses. R2. Students can unregister for courses. R3. When a student registers then it must be logged in their record. R4. When a student unregisters it must also be logged. R5. Professors can unregister students. R6. When a professor unregisters a student it must be logged. R7 When a professor unregisters a student it must be flagged as special. R8. Professors can give marks for courses. R9. When a professor gives a mark this must be logged in the record.