specifying and separating concerns from requirements to ... - CiteSeerX

SPECIFYING AND SEPARATING CONCERNS FROM REQUIREMENTS TO DESIGN: A CASE STUDY Mohamad Kassab, Constantinos Constantinides, Olga Ormandjieva Department of Computer Science and Software Engineering Concordia University 1455 de Maisonneuve Blvd West Montreal, Quebec, H3G 1M8, CANADA {moh_kass, cc, ormandj}@cs.concordia.ca

The increasing level of software complexity has highlighted the need to consider quality as an integral part of software development. According to the software engineering standard IEEE Std.830-1998 [1], NFRs describe not what the software will do, but how the software will do it, for example, software performance requirements, software design constraints, software external interface requirements and software quality attributes. During requirements engineering, NFRs tend to be stated in terms of the qualities or the constraints on the tasks which are expressed as FRs as the former affect the semantics of the latter.

mini-projects called iterations, where each iteration represents a complete development cycle: it includes its own requirements, analysis, design, implementation and testing activities. In the Rational Unified Process (R)UP, NFRs are listed in the Supplementary Specifications Document which starts during the Inception phase and normally gets refined in the subsequent phases over a number of iterations throughout development. However, the UP does not provide a special vocabulary or notation to support requirements specifications. Similarly the IEEE Standard 830-1998 describes a list of NFRs to be included in a Software Requirements Document. The FURPS+ model used by the (R)UP refers to the following categories of requirements: Functional, Usability, Reliability (replaced by Dependability), Performance, Supportability and others. NFRs that fall into the URPS categories are called quality requirements. NFRs outside URPS are called constraints or pseudo-requirements. Once a software system has been deployed, it is normally straightforward to observe whether or not a certain FR has been met, as the areas of success or failure in their context can be rigidly defined. However, the same is not true for NFRs as these can refer to quantities that can be interdependent and difficult to measure. A decomposition approach proposed by [3] encompasses the refinement of NFRs into more detailed NFRs. Software quality models are used to determine to what extent software components satisfy the requirements of a given context of use. A quality model is defined by means of general characteristics of software, which is further decomposed into sub-characteristics in a multilevel hierarchy; at the bottom of the hierarchy appear measurable software attributes. Furthermore, an interdependency may pose a tradeoff between NFRs. For example, as reliability increases, performance or cost are affected. In cases where conflicts between NFRs tend to arise, developers must work out a satisfactory level of balance (tradeoffs) between them.

An iterative software development process such as the one defined by the Unified Software Development Process (UP) [2] is organized into a series of short fixed-length

Despite the success of object-orientation in the effort to achieve separation of concerns, certain properties in object-oriented systems cannot be directly mapped from the

Abstract Aspect-Oriented Software Development (AOSD) aims at providing a systematic support for the identification, separation, representation (through proper modeling and documentation), and composition of crosscutting concerns as well as mechanisms that can make them traceable throughout software development. In this paper, we discuss a sequence of systematic activities towards an early consideration of specifying and separating crosscutting functional requirements (FRs) and nonfunctional requirements (NFRs). This approach would make it possible to identify and resolve conflicts between NFRs earlier in the development cycle and can promote traceability of broadly scoped requirements throughout system development, maintenance and evolution. We provide a formalism for FRs by specifying their pre- and postconditions using firstorder predicate logic. Measures of conflictiveness and interdependency are proposed to assess the effort required for the composition of the requirements. A new measure of cohesiveness of the use-case model is proposed based on the crosscutting modeling approach.

1. Background and introduction

problem domain to the solution space, and thus they cannot be localized in single modular units. This is due to the fact that functional decomposition is performed along the notion of class. This crosscutting phenomenon imposes two symptoms over programs: (1) the scattering of concerns across the decomposition hierarchy of the system, and (2) the tangling of concerns in modular units. Problems associated with low level of cohesion of modular units, strong coupling between modular units, low level of reusability of code, low level of adaptability and difficult comprehensibility resulting in programs that are more error prone, have been extensively discussed in the literature over the recent years. Aspect-Oriented Programming (AOP) [4] is a term adopted to describe an increasing number of technologies and approaches that support the explicit capture of crosscutting concerns (or aspects) whereby the implementation of functional components and aspects is performed (relatively) separately, and their composition and coordination (referred to as weaving) is specified by a set of rules. Crosscutting does not necessarily imply that aspects must correspond to NFRs even though NFRs seem to be major candidates for crosscutting concerns, as these normally relate to the system as a whole (or to parts of it) rather than to individual system features. Furthermore, the description of crosscutting leaves space for its manifestation in disciplines that precede programming. Aspect-Oriented Software Development has extended AOP to provide a systematic support for the identification, separation, representation (through proper modeling and documentation) and composition of crosscutting concerns as well as mechanisms that make them traceable throughout software development. The rest of this paper is organized as follows: In Section 2 we will present related work. In Section 3 we will describe our motivation. In Section 4 we will describe our approach that includes measurements for crosscutting which are further described in Section 5. In Section 6 we will present a case study to provide a proof of concept to our proposal and in Section 7 we will conclude and discuss recommendations for further research.

2. Related work and open issues Current aspect-oriented architectural frameworks aim at drawing an abstract pathway that concentrates on a general purpose modeling procedure within a certain domain, or to support particular NFRs in the system (e.g., performance or security [5, 6]). In addition, these approaches do not fully support a smooth transition among the requirements, analysis and the design phases. This is due to the lack of setting a systematic and well-defined set of composition rules which will enable the provision of the following: •

A general mechanism of integration among orthogonal and non-orthogonal FRs and NFRs at particular interaction points.

• • •

A smooth flow to the next phases of the development process based on a well-established mechanism that may extend traditional artifacts. A clear and systematic method to identify and resolve direct and indirect conflicts among aspects. An integration within a framework architecture that could be used for different categories of complex systems (such as reactive, interactive, embedded, etc.)

In [7], the authors adopt model analysis to detect semantic conflicts between aspects. However, the approach is dedicated to serve the detection of direct conflicts only. Resolving conflicts is recommended through a process of correction and refinement of the model, which is not clearly investigated. In [8], the composition of the concerns is defined as the last step of a proposed model for separation of concerns at requirements engineering using the formal method LOTOS. Resolving conflicts among concerns is recommended through negotiation with stakeholders which may not always be applicable except for developers. Defining the dominant concern at a certain matching point as recommended in this approach is not always applicable as well because of the dynamic behavior of the system. In addition, it is not clear how to map the combination set defined in LOTOS to the next stages of the development. In [9, 10, 11] composition of concerns is accomplished by extending UML models to integrate the candidate aspects to the functional behavior. Although the composition process must be considered at the meta-level, these approaches only model certain NFRs in a way that is not necessarily applicable for other requirements. In [12], the authors reason about the semantics of the composition mechanisms of the programming language through an approach that is based on a single meta-model: Composition Graphs meta-model. While these graphs may provide a sufficient homogenous comprehension for the semantics among different programming languages that make them easier to compare and to be transformed, the process to construct such graphs without existing tools can be tedious. In addition, the graphs are generated from an existing implementation that we may not necessarily have when we initially develop the application. In [13, 14], the obliviousness property was adopted to model orthogonal aspects independently from each other and from the functional requirements. The usage of formal methods in these approaches (e.g. GAMMA, LOTOS, Time Temporal Logic) to specify the functional behavior and the associated aspects helps to enable formal validation and facilitates a specification-driven design. On the other hand, the weaving process is not presented in a precise systematic way and it is limited to a specific type of requirements that could not necessary be applicable for others. In addition, it is not clear where and how the formalism is to be placed within the AOSD framework or

how to integrate it with the traditional iterative development processes.

3. Motivation and proposal An effective software development approach must harmonize the need to build the functional behavior of a system with the need to clearly model the associated NFRs. Most of the current approaches adopt the AOSD as an effective mechanism to handle NFRs at the early stages of the development process. This is mainly because the NFRs are considered as global properties of the system and they crosscut at different spots of it, thus they need to be treated within the context of AOSD that is been prompted as an approach to separate crosscutting concerns and improve the modularity in software system artifacts. In this work, our goal is to develop a systematic and precisely defined aspect-oriented architectural framework that supports the capturing of the requirements as well as the analysis and the design of multiple FRs and NFRs. Our approach aims at achieving the following: • • •

Eliminate the gap generated out of the diverse nature of FRs and NFRs. Establish a systematic way to identify and resolve conflicts among crosscuttings. Establish a smooth transition from the requirements phase to the analysis and the design phases.

In our proposal we will adopt use-case driven activities to model the system. We argue that use-cases tend to be more concrete in their representation of the system as they explicitly state series of interactions between actors and the system. Furthermore, their representations tend to be easy to map to the next phases in development. Use-cases are also widely used as part of the de facto standard of UML. The approach is illustrated in Figure 1. The iterative and incremental nature of development is implied even though it is not explicitly captured in the diagram.

4. The framework In this section we will describe the roles and activities that form part of our architectural framework. 4.1 Identifying functional requirements Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions which the system is required to perform. We use use-case diagrams as a starting point to summarize within a graphical representation the high-level behavior of the system: what the system does (as a black-box), what lies outside the system and how it gets used. Identifying FRs is a process that involves discussions with stakeholders, reviewing proposals, building prototypes and arranging requirements elicitation meetings.

4.2 Specifying functional requirements In this activity, we further refine the detailed functional behavior of each use-case with textual description, graphical representation and formal specification. The outcome of this activity is the completion of a use-case description (Table 1) which forms an extension to the fully-dressed format [15] with the provision of formalisms (for use-case signature and assertions). By the end of the current activity, we illustrate with a graphical representation the interactions between actors and the system in terms of a system sequence diagram (SSD). Transition

Requirements Elicitation

Dependency Identifying Functional Requirements Identifying and Specifying Nonfunctional Requirements

Specifying Functional Requirements Identifying Crosscutting Functional Requirements Identifying Interaction Points

Composing Requirements Defining Conflicts

Resolving Conflicts

Integration

Analysis and Design

Figure 1. AOSD activities in the proposed framework 4.3 Identifying crosscutting functional requirements To identify the crosscutting nature of certain FRs we need to take into consideration the information contained in row Related Use Cases in Table 1. If a use-case is included in several use-cases, then it is crosscutting. In spite of that, it is quite important to recognize that a certain use-case may seem to be crosscutting when defined at a certain abstract level, and then it could turn to be not crosscutting if we break it down to a finer level. There is no specific measurement on which level we shall be standing when defining and specifying use-cases. This issue will be further discussed in the case study. Table 1: Template to specify use-cases Use Case No. Unique to the use-case. Name The name of the use-case. Use Case Signature The use-case is written in the form of: () Priority Importance of the use-case. Actors Primary and secondary actors. Precondition (textual) Textual description of the condition that must be satisfied before the use-case is exe-

Precondition ( Formal) Main Scenario

Alternative Scenario Postcondition (Textual) Postcondition (Formal) Related Use Cases

cuted. A formal translation of the textual description for the precondition. A single and complete sequence of steps describing an interaction between a user and a system. Extensions or alternate courses of main scenario. Textual description of the condition that must be satisfied after the use case is executed. A formal translation of the textual description for the postcondition. Use-cases which the current use-case depends on.

4.4 Identifying and specifying nonfunctional requirements Nonfunctional requirements that are relevant to the problem domain are captured in parallel to the identification and specification of FRs. Even though the elicitation of NFRs can be accomplished in a number of existing techniques, we recommend the adoption of the NFR catalog mechanism [8] where each entry in the catalog is crosslisted against the decision of whether it is applicable for the system or not. We propose the adoption of a matrix (Table 2) that relates the identified NFRs to the use-cases they affect. In the case where an NFR (e.g. portability) would affect the system as a whole, all entries in the corresponding column must be checked. Table 2. Relating NFRs to use-cases NFR 1 NFR2 …. NFRN Use Case1 √ √ Use Case 2 √ …. √ Use Case n √ √ 4.5 Composing requirements The goal of this activity is to compose the requirements together. This is achieved in a series of four steps: (1) identifying the interaction points at which crosscutting requirements affect the system, (2) identifying possible conflicts among requirements at each interaction point, (3) resolving conflicts, and (4) integrating requirements.

We define the following sets: U = {Use Cases} C = {crosscutting FRs} ∪ {crosscutting NFRs} We also define the function A to assign the crosscutting requirements to each affected use-case (based on the analysis of Tables 1 and 2). Let u ∈U and c ⊆ C. We define A as: A (u) =∅, if there are no crosscutting requirements at u, and A (u) = c, otherwise. The set of interaction points I is defined as: I = U – {u | A (u) =∅} We can illustrate the mapping of each element in I to a list of crosscuttings (Table 3) which is provided by function A. Table 3. Interaction points in the system Interaction Interaction … Interaction Point i1 Point i2 Point in c1 c2 ... cn 4.5.2 Defining conflicts Hardly any requirements manifest in isolation, and normally the provision of one crosscutting requirement may affect the level of provision of another. We refer to this mutual dependency as non-orthogonality. To define possible conflicts among requirements, we deploy a contribution aspect matrix (Table 4) based on the (C x C) set, where Ri∈C in a similar fashion to what is proposed in [16]. For requirements that coexist at the same interaction point, we assign a positive sign for a positive contribution, and a negative sign if their contribution is negative. It is important to stress that any conflict defined at this step may prove not to be a real conflict when the system will be refined further during later phases. Table 4. Candidate aspects contribution matrix for a set of requirements (C) R1 R2 … Rn R1 + R2 … Rn +

4.5.1 Identifying interaction points Based on functional crosscuttings (defined in 4.3) and the correspondence between NFRs and use-cases (defined in 4.4) which constitutes another form of crosscutting, we can identify interaction points in the system where crosscuttings will manifest themselves.

4.5.3 Resolving conflicts For each interaction point i∈I we analyze the set c = A (i), and study the contribution among its elements. We are essentially interested in those elements (requirements) that

have a mutual negative interaction. We manage conflict resolution by refining the set c to eliminate the negative contribution, or assign a priority among these elements to determine the order of execution. The set c could then be replaced by a sequence cseq or a list clist to represent the order of the elements. 4.5.4 Integration In this step, we integrate requirements together to obtain the whole system, and we use UML diagrams to illustrate this integration. 4.6 Analysis and design System analysis is an explicit inquiry carried out to help identifying and specifying the intended behavior of the system. This investigation is performed by identifying system operations and specifying operation contracts which provide a formal (or semi-formal) analysis model [17]. Each operation contract will determine object collaborations during design which are illustrated in interaction diagrams. For the list of crosscutting requirements that affect each external or internal message, we have to specify the point in the interaction diagram which is affected by the crosscutting as well as the semantics of the integration. If two crosscuttings are intended to interact at the same point with the same integration semantics (for example, response time and availability that can affect the same part of the system at the same time) we have a direct conflict which must be resolved by the assignment of priorities for execution.

5. Measurements of crosscutting Adopting AOP technologies requires a restructuring of the software engineering phases to identify and represent crosscuttings during software requirements engineering and design, and to determine how these requirements are composed. The consequences of that is a more interleaving of the software engineering processes and better specifications that can map the problem domain to the solution space. In this section we are enriching the activity of composing requirements by proposing a set of measurements that aid in better design strategies based on quantitative evidence. The set of measurements are used to obtain a quantitative analysis of the characteristics of interaction points such as cohesiveness, conflictiveness, and interdependency. These measurements intend to assess the effort required for the integration of the requirements, and to provide a solid ground for making decisions and setting priorities while mapping candidate elements into the next phases of the development. 5.1 Cohesiveness The notion of crosscutting requirements analysis is strongly related to the cohesiveness of the set of requirements. Cohesiveness is a quality characteristic of software

models indicating the semantic relationship between the parts of a component and a single well-defined goal. In the analysis model, the user-level use-cases are the abstractions of single well-defined goals for system usage. Crosscutting FRs are, therefore, reducing the level of cohesiveness because they tend to contribute to different goals (usages). We propose to evaluate the Use-Case Model Cohesiveness using the UCMC measure defined as follows: UCMC (Use-Case Model) =1- |{crosscutting FRs}|/ |U| The range of the UCMC values is [0..1]. A Use-Case model is said to exhibit a high degree of cohesion if the number of functional crosscutting concerns is relatively low, in other words, higher values of UCMC would indicate higher level of the Use-Case Model cohesiveness. 5.2 Conflictiveness The effort required for the process of composing requirements (see Section 4.5) would highly depend on the level of interdependency between the crosscutting requirements, and more specifically on the defined conflicts. We propose to use a Conflictiveness Profile which reports the level of conflictiveness LLC (Local Level of Conflictiveness) for each Interaction Point i∈I based on the list of crosscutting requirements A(i): LLC (i) = (number of conflicting pairs of requirements in A(i)) ⁄ (total pairs of requirements in A(i)) 5.3 Interdependency Similar to LLC, we propose to define the level of interdependency LLI (Local Level of Interdependency) for each Interaction Point i∈I based on the list of crosscutting requirements A(i): LLI (i) = (number of positively contributing pairs of requirements in A(i)) ⁄ (total pairs of requirements in A(i)) Note that in general LLC(i)+LLI(i) ≠ 1 because of the existence of unrelated requirements (see Table 4).

6. Case study This section will illustrate how we have applied our proposal in the context of a real system. The case study we have chosen is a web-based invoicing system. The system is capable of receiving multiple orders or cancellation requests at the same time. Multiple tellers can access the system to process orders and change their status from “Pending” to “Invoiced” if there is a sufficient quantity available; otherwise, the requested order will wait in a

queue until the required quantity becomes available and a teller process the request. We assume that no multiple products are allowed to be requested in one order. The system requires its users to have a certain level of privileges to access any of the above functionalities except when searching for a product. The privileges are granted automatically upon successful authentication. 6.1 Identifying functional requirements Based on the requirements provided above, we can identify two actors: 1. 2.

Customer: Interested in searching the catalog, placing and canceling requests. Teller: Tracks requests from customers and processes orders.

We also identify the following use-cases (functionalities): (1) Search, (2) Place Order, (3) Cancel Order, (4) View Orders and (4) Process Order. The use-case diagram of Figure 2 illustrates the context of the system in terms of FRs and how they relate to the actors. Use-cases Place Order and Cancel Order have been refined to factorize the Process Payment as a common functionality.

Customer

Search Place Order Process Payment

Teller

Cancel Order

View Orders

Process Order

Figure 2. Use Case diagram for the case study 6.2 Specifying functional requirements In the use-case definitions, we have chosen to adopt firstorder predicate logic to formalize the preconditions and postconditions for the FRs, as this can facilitate a specification-driven design and enable formal validation of requirements. A summary of our notations is shown in Figure 3. Tables 6 and 7 show how the template described in our approach is used for the use-cases Place Order and View Order. The SSDs for the use-cases shown in Tables 6 and 7 are illustrated in Figures 4 and 5 respectively. Predefined data types --We use the three predefined data types: --integer Z , real R and String S

Composite Types ProductInfo = structure of prodNum : Z prodName : S quantity : Z end // Define products ordered per invoice. InvoiceInfo = structure of invoiceNum : Z prod : ProductInfo OrderedQty : Z Status : S end // Define user accounts AccountInfo = structure of username = S pwd = S end // Define authenicated users LoggedInUserInfo = structure of uname = S // priority is 1 if teller is logged in // 2 if customer priority = Z end Global Variables Products : sequence of ProductInfo Invoices: sequence of InvoiceInfo Accounts: sequence of AccountInfo LoggedInUsers: sequence of LoggedInUserInfo

Figure 3. Summary of formalism notations for the case study Table 6. Place Order specification Use Case No. 2 Name Place Order Use Case PlaceOrder: (orderedProduct: ProductSignature Info, quantity: Z, un : S) Priority Highest Actors Customer Precondition The Customer is authenticated by looking (Textual) up username in LoggedInUsers. Precondition ∃ i : Z •1 ≤ i ≤ sizeof(LoggedInUsers) • (Formal) (LoggedInUsers(i).username = un) ∧ (LoggedInUsers(i).privilege = 2) Main The Customer accesses a terminal in orScenario der to place an order for one product. The Customer specifies the product number along with the required quantity. The Customer specifies the payment information which will have to be verified and accessed in the Process Payment usecase. Alternative If the product number is wrong, then an Scenario informative error message will be displayed and the Customer will be asked to search for the product. Postcondition Ensure that a new invoice is created and it (Textual) is assigned to a unique invoice number. Postcondition [(sizeof(Invoices’) = sizeof(Invoices) + 1) ∧ (∀ k, l : Z | 1 ≤ k, l ≤ sizeof(Invoices) • (Formal) k≠l⇒ (Invoices.invoiceNum(k) ≠ Invoices.invoiceNum(l))]

Related Use Cases

Process Payment

Precondition (Formal)

:System :System

:Actor :Actor createOrder() orderProduct(productNumber,quantity, billingInfo) confirmation message

Main Scenario Alternative Scenario Postcondition (Textual) Postcondition (Formal) Related Use Cases

∃ k : Z | 1 ≤ k ≤ sizeof(LoggedInUsers) • (LoggedInUsers(k).username = un) ∧ (LoggedInUsers(k).privilege = 1 The Teller accesses the system and chooses to view all pending orders. A list of the pending orders will be displayed. None. Ensure that all invoices displayed are in “Pending” status. ∀i : Z •1 ≤ i ≤ sizeof(Invoices) • Invoices(i).status = “Pending” None

:System :System

:Actor :Actor

Figure 4. SSD for Place Order viewPendingOrders()

6.3 Identifying crosscutting functional requirements informative message

We can identify crosscutting FRs by analyzing the Related Use Cases row in the above use-case definitions. For example, Process Payment is a crosscutting use-case as it is included in both Place Order and Cancel Order use cases. This result would allow evaluating the cohesiveness of the use-case model: UCMC (invoicing system) =5/6 The UCMC value is indicating a high level of cohesion (and thus high quality of the solution) for the analysis model invoicing system. It is important to make it clear that a crosscutting use-case at this level is not necessary going to be mapped to an aspect at later stages of the development process. On the other hand it could be mapped to more than one aspect. This would depend on the level of abstraction at which we choose to model the functionality. For instance, use-case Process Payment could be further broken down to a finer level: Verify Payment Information, Make Debit Payment, and Process Refund. At the refined level, only Verify Payment Information use-case is a crosscutting component while Make Debit Payment only affects Place Order and Process Refund only affects the Cancel Order use-case. Table 7. View Orders specification Use Case No. 4 Name View Orders Use Case View Orders: (un : S) Signature Priority Highest Actors Teller Precondition The teller is authenticated. (Textual)

Figure 5. SSD for View Orders 6.4 Identifying and specifying nonfunctional requirements For each entry in the NFR catalog, we decide whether or not it is related to the invoice system. In this case study, we will present the contribution of the following NFRs: Scheduling (SCH), Synchronization (SYN), Response Time (RT), Availability (AVA), Multi Access (MA) and Security (SEC). In Table 8, we relate these requirements to the main use-cases.

UC1 UC2 UC3 UC4 UC5 UC6

Table 8. Relating NFRs to use-cases SCH SYN RT AVA MA √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

SEC √ √ √ √ √

Table Legend: UC1: Search, UC2: Place Order, UC3: Cancel Order, UC4: View Order, UC5: Process Order, UC6: Process Payment.

6.5 Composing Requirements In this section we will illustrate the required series of steps in order to compose requirements. 6.5.1 Identifying interaction points Based on the last two steps, we identify the set of crosscutting requirements as: {Process Payment, Synchronization, Scheduling, Response Time, Availability, Multi Access, Security}. The interactions are illustrated in Table 9. Table 9. Interaction points Search

Place Order

RT AVA MA

UC6 SCH SYN RT AVA MA SEC

Process Payment RT AVA MA SEC

Cancel Order

View Orders

Process Order

UC6 RT AVA MA SEC

SCH SYN RT AVA MA SEC

SCH SYN RT AVA MA SEC

A (Search) = [AVA, RT, MA] A (Place Order) = [SEC, AVA, {RT, SCH, A (Process Payment) = [SEC, A (Cancel Order) = [SEC, AVA, {RT, SCH, A (View Orders) = [SEC, AVA, {RT, SCH, A (Process Order) = [SEC, AVA, {RT, SCH,

SCH

SYN}]

During integration FRs and NFRs are combined to obtain the whole system. We use UML at this high level of abstraction to model the composition. In the new structured use-case diagram, we use the stereotype for each NFR and have the set of initial crosscutting use-cases include the new ones. Figure 6 shows a partial use-case diagram that includes the following use cases: Place Order, Cancel Order, View Orders and Process Payment while interacting with Response Time, Scheduling and Synchronization.

RT

AVA



Place Order

Process Payment

Customer

Table 10. Candidate aspects contribution SYN

SYN}]



Table 10 illustrates the contribution (positive, negative or none) between the requirements.

UC6

SYN, UC6}]

6.5.4 Integration

6.5.2 Identifying conflicts

UC6 SYN SCH RT AVA MA SEC

SYN, UC6}] AVA, RT, MA]

MA

View Order

SEC



Response Time

+

-

We illustrate the conflictiveness and interdependency measures on the “Search” Interaction Point. There are three pairs of requirements in A(Search), namely, {RT, AVA, MA}. The pair {RT, MA} is conflicting and the pair {AVA, MA} is positively contributing (see Table 10), therefore, the values for the Conflictiveness and Interdependency measures are as follows: LLC(Search)=1/3 LLI(Search)=1/3 6.5.3 Resolving conflicts We reduce the conflict by assigning priorities for the negatively contributed requirements at each Interaction Point. We present below the ordered list of crosscutting concerns clist for each Interaction Point i. A set within the list indicates that the set elements are free to execute in any order as there is no negative contribution identified.



Teller Cancel Order



Scheduling

Synchronization

Figure 6. Structured use-case diagram In SSDs, crosscutting requirements are usually invoked during external messages (e.g. security) or between messages (e.g. response time). We introduce crosscuttings into these diagrams to be intersecting with the corresponding messages. Figure 7 shows the SSD of the main scenario of View Order with the following crosscutting elements: security, scheduling, synchronization and response time. Even though in the domain model certain (crosscutting) concerns may be modeled as conceptual classes, some other concerns may not be modeled. On the other hand, the SSD may be a better candidate to provide adequate representations.

6.6 Analysis and design

createOrder()

We will deploy operation contracts for createOrder and viewPendingOrders system operations specified within the Place Order and View Order use-cases respectively. For both operations, the system initially authenticates the corresponding actor to be eligible to use the service (addressed by the synchronization aspect) before establishing what should be considered as the race condition between multiple actors due to the multi-access nature of the system (addressed by the scheduling aspect). Tables 11 and 12 show the operation contracts for createOrder() and viewPendingOrders() followed by the corresponding communication diagrams which illustrate the crosscutting view of security, synchronization , scheduling and response time (Figures 8, and 9 respectively).

:System Facade

Response Time

1.1 execute() 1.2 create()

Authenticate 4.2 create()

4.1 create()

:Order 2.1 execute()

:OrderQueue

2.2 execute() 2.3. insert(ord) 3. add() : Order

Synchronization

Scheduling

Figure 8. Communication diagram for createOrder() with crosscuttings :Actor :Actor

:System :System viewPendingOrder() informative message

Response Time Authentication

Scheduling

Table 12. Operation Contract for viewOrders() Operation viewPendingOrders() CrossUC5: View Orders reference Preconditions Postconditions

Synchronization

1. 2. 3.

Figure 7. Partial integration between the main scenario of View Orders case-study with crosscuttings

Ensure that the appropriate records displayed for all pending invoices. RT Synchronization

Scheduling

viewPendingOrders()

Table 11. Operation Contract for createOrder() Operation createOrder() Cross-reference UC2: Place order Precondition Postcondition 1. An order instance ord has been created (instance creation). 2. ord is associated with the order queue (formation of association). 3.

7. Conclusion and future work Tangling and scattering are symptoms that do not exclusively affect implementation, but they also propagate to early stages of the development process. Identifying and modeling crosscuttings earlier has a great impact on improving the general quality of the system and reducing complexity by (1) prompting understandability and reusability, (2) enhancing the process of detecting and removing defects, and (3) reducing development time.

1.1 execute() 1.2 execute()

3.1 execute()

:SystemFacade

:OrderQueue 3.2 execute() 1.3 view(order)

2 retrieve() :Order

Response Time

Authentication

Figure 9. Communication diagram for viewPendingOrders() with crosscuttings In this paper, we discussed a sequence of systematic activities towards an early consideration of identifying, specifying and separating broadly scoped requirements that are traceable throughout system development process. We addressed both FRs and NFRs as candidate crosscutting requirements. We also proposed to specify FRs by extending the fully dressed format of use case specification [15] with the provision of formal definition for describing assertions (preconditions/postconditions).

To compose requirements, we provided a fine grained approach to define interaction points and relate them to the level of use-cases. Also, we proposed to measure cohesiveness, conflictiveness and interdependency to assess the effort required for achieving better design strategies based on quantitative evidences. Our approach makes it possible to early recognize and resolve conflicts within the activity of composing requirements. For future research, we plan to investigate how to formalize NFRs to integrate them with formally specified FRs. We also plan to investigate how to formally resolve conflicts among requirements at interaction points with minimum contribution of stakeholders.

References [1] IEEE Std 830-1998, IEEE recommended practice for software requirements specifications (October 20, 1998). [2] I. Jacobson, G. Booch, and J. Rumbaugh, The unified software development process (Addison-Wesley, 1999). [3] L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos. Nonfunctional requirements in software engineering (Kluwer Academic Publishing, 2000). [4] G. Kiczales, J. Lamping , A. Mendhekar, C. Maeda, C. V. Lopes, J-M. Loingtier, and J. Irving, Aspect-oriented programming, Proc. 11th European Conference on ObjectOriented Programming, Jyväskylä, Finland, 1997, 220242. [5] E. Franz and C. Pohl , Towards a unified treatment of security and other non-functional properties, Proc. Workshop on AOSD Technology for Application-Level Security (AOSDSEC'04), Lancaster, UK, 2004. [6] V. Shah and F. Hill, An aspect-oriented security framework: Lessons learned, Proc. Workshop on AOSD Technology for Application-Level Security (AOSDSEC'04), Lancaster, UK, 2004. [7] F. Tessier, L. Badri and M. Badri, Towards a formal detection of semantic conflicts between aspects: A modelbased approach, Proc. 5th Aspect-Oriented Modeling Workshop in conjunction with UML 2004, Lisbon, Portugal, 2004. [8] I. Brito and A. Moreira, Integrating the NFR framework in a RE model, Proc. Workshop on Early Aspects in conjunction with 3rd International Conference on AspectOriented Software Development, Lancaster, UK, 2004.

[9] A. Moreira, J. Araujo and I. Brito, Crosscutting quality attributes for requirements engineering, Proc. 14th International conference on Software Engineering and Knowledge Engineering, Ischia, Italy, 2002, 167-174. [10] D. Park and S. Kand, Design phase analysis of software performance using aspect-oriented programming, Proc. 5th Aspect-Oriented Modeling Workshop in conjunction with UML 2004, Lisbon, Portugal, 2004. [11] J. Araujo, A. Moreira, I. Brito and A. Rashid, Aspectoriented requirements with UML, Proc. Workshop on Aspect-Oriented Modeling with UML in conjunction with 1st International Conference on Aspect-Oriented Software Development, Enschede, Netherlands, 2002. [12] I. Nagy, M. Aksit and L. Bergmans, Composition graphs: A foundation for reasoning about aspect-oriented composition, Proc. 5th Aspect-Oriented Modeling Workshop in conjunction with UML 2004, Lisbon, Portugal, 2004. [13] L. Blair, G. Blair, A tool suite to support aspectoriented specification, Proc. Aspect-Oriented Programming Workshop in conjunction with 13th European Conference on Object-Oriented Programming, Lisbon, Portugal, 1999, 7-10. [14] M. Mousavi, G. Rusello, M. Ghaudron, M. Reniers, T. Basten, A. Corsaro, S. Shukla, R. Gupta and D. Schmidt, Aspects + GAMMA = AspectGAMMA: A formal framework for aspect-oriented specification, Proc. Workshop on Aspect-Oriented Modeling with UML in conjunction with 1st International Conference on AspectOriented Software Development, Enschede, Netherlands, 2002. [15] C. Larman, Applying UML and patterns; An introduction to object-oriented analysis and design and the unified process; Second edition, (Upper Saddle River, NJ: Prentice Hall Inc., 2002). [16] A. Rashid, A. Moreira and J. Araujo, Modularisation and composition of aspectual requirements, Proc. 2nd International Conference on Aspect-Oriented Software Development, Boston, MA, 2003, 11-20. [17] C. Constantinides and T. Skotiniotis, The provision of contracts to enforce system semantics throughout software development, Proc. 8th IASTED International Conference on Software Engineering and Applications (SEA2004), Cambridge, MA, 2004.