A Game of Attribute Decomposition for Software Architecture Design
Attribute-driven software architecture design aims to provide decision support by taking into account the quality attributes of softwares. A central question in this process is: What architecture design best fulfills the desirable software requirements? To answer this question, a system designer needs to make tradeoffs among several potentially conflicting quality attributes. Such decisions are normally ad-hoc and rely heavily on experiences. We propose a mathematical approach to tackle this problem. Game theory naturally provides the basic language: Players represent requirements, and strategies involve setting up coalitions among the players. In this way we propose a novel model, called decomposition game (DG), for attribute-driven design. We present its solution concept based on the notion of cohesion and expansion-freedom and prove that a solution always exists. We then investigate the computational complexity of obtaining a solution. The game model and the algorithms may serve as a general framework for providing useful guidance for software architecture design. We present our results through running examples and a case study on a real-life software project.
Software architecture, coalition game, decomposition game
Computational game theory studies the algorithmic nature of conflicting entities and establishes equilibria: A state of balance that minimises the negative effects among players. The field has attracted much attention in the recent 10-15 years due to applications in multi-agent systems, electronic markets and social networks . In this paper, we investigate the problem of software architecture design from a game theory perspective. In particular, we provide a novel model, called decomposition game, which captures interactions among software requirements and derives a software architecture through equilibria.
The architecture of a software system lays out its basic composition. For softwares become larger, quality attributes such as performance, reliability, usability and security, play an increasingly important role. It has been a common belief that architecture design heavily influences the quality attributes such as performance, reliability, usability and security of a software system . A major objective of architecture design is therefore the assurance of non-functional requirements through compositional decisions. In other words, we need to answer the following question: What architecture best fulfills the desirable software requirements? There is, however, usually no “perfect” architecture that fulfills every requirement. For example, performance and security are both key non-functional requirements, which may demand fast response time to the users, and the application of a sophisticated encryption algorithm, respectively. These two requirements are in intrinsic conflict, as a strong focus of one will negatively impact the fulfilment of the other. A main task of the software architect, therefore, is to balance such “interactions” among requirements, and decide on appropriate tradeoffs among such conflicting requirements.
While it is a common practice to decide on software architecture designs through the designers’ experiences and intuition, formal approaches for architecture design are desirable as they facilitate standardisation and automation of this process, providing rigorous guidelines, allowing automatic analysis and verifications . Notable formal methods in software architecture include a large number of formal architecture description languages (ADL), which are useful tools in communicating and modeling architectures. However, as argued by , industry adoptions of ADL are rare due to limitations in usability and formality. Other algorithmic methods for software architecture design include employing hierarchical clustering algorithms to decompose components based on their common attributes , as well as quantifying tradeoffs between requirements .
In this paper, we propose to use computational game theory as a mathematical foundation for conceptualising software architecture designs from requirements. Our motivation comes from the following two lines of research:
(1). Attribute driven design (ADD) : ADD is a systematic method for software architecture design. The method was invented by Bass, Klein and Bachmann in  and subsequently updated and improved through a sequence of works . The goal is to assist designers to analyse quality attribute tradeoffs and provide design suggestions and guidance. Inputs to ADD are functional and non-functional requirements, as well as design constraints; outputs to ADD are conceptual architectures which outline coarse-grained system compositions. The method involves a sequence of well-defined steps that recursively decompose a system to components, subcomponents, and so on. These steps are not algorithmic: They are meant to be followed by system designers based on their experience and understanding of design principles. As mentioned by the authors in , an ongoing effort is to investigate rigorous approaches in producing conceptual architectures from requirements, hence enabling automated design recommendation under the ADD framework. To this end, we initiate a game-theoretic study to formulate the interactions among software requirements so that a conceptual architecture can be obtained in an algorithmic way.
(2). Coalition game theory : A coalition game is one where players exercise collaborative strategies, and competition takes place among coalitions of players rather than individuals. In ADD, we can imagine each requirement is “handled” by a player, whose goal is to set up a coalition with others to maximise the collective payoff. The set of coalitions then defines components in a system decomposition which entails a software architecture. This fits into the language of coalition games. However, the usual axioms in coalition games specify super-additivity and monotonicity, that is, the combination of two coalitions is always more beneficial than each separate coalition, and the payoff increases as a coalition grows in size. Such assumptions are not suitable in this context as combination of two conflicting requirements may result in a lower payoff. Hence a new game model is necessary to reflect the conflicting nature of requirements. In this respect, we propose that our model also enriches the theory of coalition games.
Our contribution. We provide a formal framework which, following the ADD paradigm , recursively decomposes a system into sub-systems; the final decomposition reveals design elements in a software architecture. The basis of the framework is an algorithmic realisation of ADD. A crucial task in this algorithmic realisation is system decomposition, which derives a rational decomposition of an attribute primitive.
We model system decomposition using a game, which we call decomposition game. The game takes into account interactions between requirements, which express the positive (enhancement) or negative (canceling) effects they act on each other. A solution concept (equilibrium) defines a rational decomposition, which is based on the notions of cohesion and expansion-freedom.
We demonstrate that any such game has a solution, and a solution may not be unique. We also investigate algorithms that compute solutions for the decomposition game. Finding cohesive coalitions with maximal payoff turns out to be NP-hard (Thm. ?). Hence we propose a relaxed notion of -cohesion for , and present a polynomial time algorithm for finding a -cohesive solution of the game (Thm. ?). To demonstrate the practical significance our the framework, we implement the framework and perform a case study on a real-world Cafeteria Ordering System.
Paper organisation. Section 2 introduces the formal ADD framework. Section 3 discusses decomposition game and its solution concept. Section 4 presents algorithms for solving decomposition games. Section 5 presents the case study. Section 6 discusses related works and finally Section 7 concludes with future works.
2Algorithmic Attribute Driven Design (ADD) Process
ADD is a general framework for transforming software requirements into a conceptual software architecture. Pioneers of this approach introduced it through several well-formed, but informally-defined concepts and steps . A natural question arises whether it can be made more algorithmic, which provides unbiased, mathematically-grounded outputs. To answer this question, one would first need to translate the original informal descriptions to a mathematical language.
2.1Software Requirements and Constraints
Functional requirements. Functional requirements are specifications of what tasks the system perform (e.g. “the system must notify the user once a new email arrives”). A functional requirement does not stand alone; often, it acts with other functional requirements to express certain combined functionality (e.g. “the user should log in before making a booking”). Thus, a functionality may depend on other functionalities. We use a partial ordering to denote the functional requirements where each is a functional requirement, and denotes that depends on . Note that is a transitive relation.
Non-functional requirements. Non-functional requirements specify the desired quality attributes; ADD uses general scenarios and scenarios as their standard representations. A general scenario is a high-level description on what it means to achieve a non-functional requirement . For example, the general scenario “A failure occurs and the system notifies the user; the system continues to perform in a degraded manner” refers to the availability attribute. There has been an effort to document all common general scenarios; a rather full list is given in . Note that a general scenario is vaguely-phrased and is meant to serve as a template for more concrete “instantiations” of quality attributes. Such “instantiations” are called scenarios. More abstractly, we use a pair to denote the non-functional requirements where is a set of scenarios and is an equivalence relation on , denoting the general scenario relation: means that and instantiates the same general scenario.
Design constraints. Design constraints are factors that must be taken into account and enforce certain design outcomes. A design constraint may affect both functional and non-functional requirements. More abstractly, we use a collection of sets to denote the set of design constraints, where each set is a design constraint. Intuitively, if two requirements belong to the same , then they are constrained by the same design constraint .
Derived Functionalities. The enforcement of certain quality attributes may lead to additional functionalities. For example, to ensure availability, it may be necessary to add extra functionalities to detect failure and automatically bypass failed modules. Hence we introduce a derivation relation such that means the functional requirement is derived from the scenario .
The intentional outcome of ADD describes the design elements, i.e., subsystems, components or connectors. It is important to note that the goal of ADD is not the complete automation of the design process, but rather, to provide useful guidance. Thus, the conceptual view reveals only the organisational structure but not the concrete design.
An attribute primitive is a set of design elements that collaboratively perform certain functionalities and meet one or more quality requirements; it is also the minimal combination with respect to these goals . Examples of attribute primitives include data router, firewall, virtual machine, interpreter and so on. ADD prescribes a list of attribute primitives together with descriptions of their properties and side effects (such as in ). Hence, ADD essentially can be viewed as assigning the right attribute primitives to the right requirement combinations. Note also that an attribute primitive may be broken down further.
Let be an attribute primitive. We also need the following definition:
A requirement of is an element in the set .
For , the dependency set of is the set .
For , the general scenario of is the set , i.e., the -equivalence class of .
For , the constraints of is the set .
For , the derived set of is , and for , let
2.3The ADD Procedure
Essentially ADD provides a means for system decomposition: The entire system is treated as an attribute primitive, which is the input. At each step, the procedure decomposes an attribute primitive by identifying a decomposition . The process then maps each resulting design element to an attribute primitive , which contains all elements in and may require some further requirements and constraints. Hence we require that and , , , are consistent with , , and on , resp.; in this case we say that is consistent with . Thus the attribute primitive is decomposed into attribute primitives . On each where , the designer may choose to either terminate the process, or start a new step recursively to further decompose . See Procedure ?.
We point out that the ADD procedure, as presented by its original proponents, involves numerous additional stages other than the ones described above . The reason we choose this over-simplified description is that we believe these are the steps that could be rigorously presented, and they abstractly capture in a way most of the steps mentioned in the original informal description.
The operation produces a rational decomposition of the input attribute primitive that satisfies the requirements of . We also note that amounts to a crucial step in the ADD process, as the decomposition determines to a large extend how well the quality attributes are met. This step is also a challenging one as interactions among quality attributes create potential conflicts. Thus, in the next section, we define a game model which allows us to automate the operation.
The procedure looks for a rational decomposition that meets the requirements in as much as possible. Let be an attribute primitive. Relevance between requirements are determined by the relations and the constraint set . In the following the Jaccard index measures the similarity between two sets with
Intuitively, the relevance of a requirement to other requirements is influenced by the “links” between and the functional, the non-functional requirements, as well as design constraints.
If two requirements are relevant, their relevance depends on overlaps between their derived sets, dependency sets and constraints. If two requirements are not relevant, then we regard them as having a negative relevance , which represents a “penalty” one pays when two irrelevant requirements get in the same design element.
For simplicity, we do not include these constants in expressing the function , and all subsequent notions that depend on (thus saving us from writing “”).
We employ notions from coalition games to define what constitutes a rational decomposition. In a coalition game, players cooperate to form coalitions which achieve certain collective payoffs .
This provides the set up for decompositions: Imagine a coalition game consisting of agents as players, where each agent is in charge of a different requirement. The players form coalitions which correspond to sets of requirements, i.e., design elements. The payoff function would associate with every coalition a numerical value, which is the payoff gained by each member of the coalition. Therefore, an equilibrium of the game amounts to a decomposition with the right balance among all requirements – this would be regarded as a rational decomposition.
It remains to define the payoff function. Naturally, the payoff of a coalition is determined by the interactions among its members. Take . If one of is a functional requirement, then their interaction is defined by their relevance index , as higher relevance means a higher level of interaction. Suppose now both are scenarios (non-functional). Then the interaction becomes more complicated, as a quality attribute may enhance or defect another quality attribute. In , the authors identified effects acting from one quality attribute to another, which is expressed by a tradeoff matrix :
has dimension where is the number of general scenarios
For , the -entry .
Let be general scenarios. (resp. ) means has a positive (resp. negative) effect on , means no effect. E.g., the tradeoff matrix defined on six common quality attributes is: Note that the matrix is not necessarily symmetric: The effect from to may be different from the effect from to . For example, an improvement in system performance may not affect security, but increasing security will almost always adversely impact performance. we assume that the matrix is given prior to ADD; this assumption is reasonable as there is an effective map from any general scenario to the main quality attribute it tries to capture. We use this tradeoff matrix to define the interaction between two scenarios in .
We are now ready to define the interaction between two scenarios .
We point out some major differences between decomposition and typical coalition games: Firstly, in coalition game theory, one normally assumes the axioms of superadditivity () and monotonicity () which would obviously not hold for decomposition as players may counteract with each other, reducing their combined utility. Secondly, the typical solution concepts in coalition games (such as Pareto optimality, and Shapely value) focus on distribution of payoffs to each individual player assuming a grand coalition consisting of all players. In decomposition such a grand coalition is normally not desirable and the focus is on the overall payoff of each coalition , rather than the individual requirements. The above differences motivate us to consider a different solution concept of DG . At any instance of the game, the players form a decomposition . We assume that the players may perform two collaborative strategies:
Merge strategy: Two coalitions may choose to merge if they would obtain a higher combined payoff.
Bind strategy: Players within the same coalition may form a sub-coalition if they would obtain a higher payoff.
Example ? shows that a solution concept would be a decomposition where no “expansion” nor “crumbling” occur to any coalition. Formally, we define the following solution concepts:
A solution of a DG corresponds to a rational decomposition of the attribute primitive . As shown by Thm. ?, any attribute primitive admits a solution, and rather expectedly, a solution may not be unique.
We show existence of a solution by construction. Let be a longest sequence such that for any , is a minimal coalition with maximal utility in (i.e., and ).
We claim that is a solution in . Indeed, for any , any proper subset of would have payoff strictly smaller than by minimality of . Thus is cohesive. Moreover, if for some , then does not have maximal utility in . Hence is expansion-free.
Let be an attribute primitive where and . We may define in such a way that
For all and ,
For all , ,
Consider . Note that and ; is cohesive and is expansion-free as . Note also that and ; is cohesive and is expansion-free as
4Solving Decomposition Games
Based on our game model, the operation in Procedure ? is reduced to the following problem:
INPUT: An attribute primitive
OUTPUT: A solution of the game
Here, we measure computational complexity with respect to the number of requirements in . The proof of Theorem ? already implies an algorithm for solving the problem: check all subsets of to identify a minimal set with maximal utility; remove it from and repeat. However, it is clear that this algorithm takes exponential time. We will demonstrate below that a polynomial-time algorithm for this problem is, unfortunately, unlikely to exist.
We consider the decision problem : Given and a number , is there a solution of in which the highest utility of a coalition reaches ? Recall that the payoff function of is defined assuming constants and . The theorem below holds assuming .
The proof is via a reduction from the maximal clique problem, which is a well-known NP-hard problem. Given an undirected graph , we construct an attribute primitive such that any cohesive coalition in reveals a clique in . Suppose . The requirements of consist of scenarios: . In particular, all requirements are non-functional. We define an edge relation on such that
iff for some and
If then for any .
Any is attached to at most one edge in .
Note that such a relation exists as any node is only connected with at most other nodes in . Intuitively, a set of requirements serves as a “meta-node” and corresponds to the node in . In constructing , we may define the general scenarios in such a way that
for any and .
for any .
for any but
For every and , put in a constraint . Thus the relevance between and is
Furthermore if , then for any we set . Suppose induces a complete subgraph of . We define the meta-clique coalition of as
By the above definition, for any , take such that .
Thus . Taking out any element from results in a strict decrease in utility, and hence is cohesive.
Now take any coalition that contains two requirements , such that . Let and . Note also that for any . Therefore we have
The last inequality above is by assumption that . Thus is not cohesive.
By the above argument, a coalition is cohesive in iff is the meta-clique coalition for some clique in . Furthermore, a decomposition is a solution in iff can be partitioned into sets where each is a clique, and for all . In particular, has a clique with nodes if and only if has a solution that contains a coalition whose utility reaches . This finishes the reduction.
Theorem ? shows that, in a sense, identifying a “best” solutions in a DG is hard. The main difficulty comes from the fact that one would examine all subsets of players to find an optimal cohesive coalition. This calls for a relaxed notion of a solution that is computationally feasible. To this end we introduce the notion of -cohesive coalitions. Fix and enforce this rule: Binding can only take place on or less players. That is, a coalition is -cohesive whenever is greater than the utility of any subsets with at most players.
Remark. In a sense, the value in the above definition indicates a level of expected cohesion in the decomposition process. A higher value of implies less restricted binding within any coalition, which results in higher “sensitivity” of design elements to conflicts. In a software tool which performs ADD based on DG, the level may be used as an additional parameter.
Let be a set of requirements. A coalition is called maximally -cohesive in if , is -cohesive and for any . Suppose the operation computes a maximally -cohesive set in . The algorithm (Proc. ?), which uses (Proc. ?) as a subroutine, computes a -cohesive solution of . Note that the operation maintains a list , which when returned, denotes a decomposition. Note also that the returned satisfies the following condition:
We call this a maximally -cohesive decomposition.
Let for any . Suppose for . By assumption is maximally -cohesive in . For any finite set such that , we have . Hence is also -cohesive.
The algorithm calls to produce a maximally -cohesive decomposition , and then performs several iterations to “combine” the coalitions in . By Lemma ?, the decomposition after each iteration is -cohesive. There is a point when for all we have . At this moment, the while-loop will terminate and is expansion-free. The time complexity is justified as there are subsets of with size . Thus computing a maximally -cohesive decomposition takes time .
5Case Study: Cafeteria Ordering System
To demonstrate applicability of our game model in real-world, we build a DG for a cafeteria ordering system (COS). A COS permits employees of a company to order meals from the company cafeteria online and is a module of a larger cafeteria management system. The requirements of the project have been produced through a systematic requirement engineering process and is well-documented (See full details from ). Since COS is a subsystem within a larger system, the requirements also incorporate interfaces with other subsystems of the overall system. The initial attribute primitive has 60 requirements with , and 7 design constraints. Non-functional requirements conflict with each other, e.g., the general scenario conflicts with the general scenario . Also the requirements exhibit some complex relationships, e.g. .
We demonstrate the complicated interactions among requirements using a complete graph where nodes are all requirements in ; see Fig. ?. The edges are in two colours: gets blue if and red if . (For completeness, we include descriptions of constraints and requirements in the APPENDIX.)
We run the algorithm to identify a -cohesive solution for different levels of expected cohesion. In order to clearly identify sub-components, we give a higher penalty between conflicting requirements: , , , . We choose . As argued above, setting a higher value of should in principle improve the quality of the output decomposition, although this also means a longer computation time. We implement our algorithm using Java on a laptop with Intel Core i7-3630QM CPU 2.4GHz 8.0GB RAM. The running time for different values of is: 503 milliseconds for and approximately seconds for .
|-Cohesive Solution||-Cohesive Solution|
|Coalition 4||SI1.1 SI1.2||Order.Menu.Available SI1.1 SI1.2|
Cohesion level . The -cohesive solution consists of 5 coalitions. An examination at the requirements in each coalition reveals: Coalition 0 relates to usability and ensures availability of user interactions; it apparently corresponds to a user interface module. Coalition 1 is performance-oriented and is separated from the usability requirements; it thus corresponds to a back-end module that handles all the internal operations. Coalition 2 deals with the payroll system outside COS and defines a controlling interface from COS to payroll. Coalition 3 consists of several functional requirements that control life cycle of the COS. Coalition 4 is an interface to access the inventory system outside COS.
It is clear that this solution separates the control, user inputs and computation modules, and fits the MVC (Model-View-Controller) architectural pattern. In addition, there is a design constraint that requires the use of Java and Oracle database engine. So, we instantiate the design elements as in Fig. ?.
Cohesion level . The -cohesive solution also contains five coalitions, with a similar structure as the -cohesive counterpart. There are, nevertheless, several important differences: Firstly, the performance () scenarios now belong to coalitions 0. This means that some performance-related computation is moved to the front-end. This is reasonable as this lightens the computation load of the back-end and thus improving performance and availability. Secondly, the functional requirement is moved to coalition 4, which is the interface between COS and the inventory system. This requirement specifies that the menu should only display those food items that are available in inventory.
Bass, Klein and Bachman introduce ADD as a general framework for developing conceptual architecture in . They argue that non-functional requirements should drive decision making throughout the entire design process. Furthermore, as non-functional requirements often provide a high-level view of a software system, ADD should follow an iterative decomposition process. They further improve their method in  by clarifying how ADD is carried out in a real life project. The technique of evaluating tradeoff between quality attributes in these mentioned works is largely empirical-based. Kazman et. al. first investigate tradeoff between quality attributes in . They collect and analyse design elements that affect multiple quality attributes. This approach aims to mitigate risks residing in a software architecture and refine design through this process. The study is further investigated in  which gives a quantitative tradeoff analysis for non-functional requirements, and prioritises non-functional requirements during the ADD process. In , a different approach is provided to elicit non-functional requirements. The work follows the paradigm in  but generates more detailed and concrete designs; it computes tradeoff between non-functional requirements based on relationships between non-functional and functional requirements. There are also other algorithmic methods for software architecture design from the perspective of component decomposition. For example, in , the authors propose a hierarchical clustering algorithm to decompose functional requirements and non-functional requirements. They label each component with a set of attributes and identify similarities between components based on their common attributes. Hence their approach does not put emphasis on the enhancement and conflict between attributes.
7Conclusion and Future work
The use of computational games in software architecture design is a novel technique aimed to contribute to this line of direction. We proposed a game-based approach that, not only builds on established software architecture research (ADD), but is also shown — through a case study — to provide reasonable design guidelines to a real world application. We suggest that this framework would be useful in the following:
Designing a software system that involves a large number of functionalities and quality attributes, which will result in a complicated architecture design
Designing a software system that hinges on the satisfaction of certain core quality attributes
Evaluating and analysing the rationale of an architecture design in a formal way; identifying potential risks with a design.
It is noted that the framework described here assumes the completion of requirement analysis. In real life requirements are usually identified as the software is implemented (e.g. the agile software development methodology). It would thus be interesting to develop a dynamic version of the game model, which supports architectural design using incremental refinements. Another future work is to develop a mechanism which maps coalitions generated by the algorithm to appropriate attribute primitives. This would then lead to a full automation of the ADD process linking requirements to conceptual architecture designs.
CO-2: The system shall use the current corporate standard Oracle database engine.
CO-3: All HTML code shall conform to the HTML 5.0 standard.
BR-2: Deliveries must be completed between 11:00am and 2:00pm local time.
BR-3: All meals in a single order must be delivered to the same location.
BR-8: Meals must be ordered within 14 calendar days of the meal date.
BR-11: If an order is to be delivered, the patron must pay by payroll deduction.
BR-33: 256-bit encryption or network transmissions that involve financial information
Order.Place: Placing a meal order
.Register: Confirm that the Patron is registered for payroll reduction.
.No: If the patron is not registered for payroll deduction, the COS shall give the Patron options to register now and continue placing an order
.Date: The COS shall prompt the Patron for the meal date (See BR-8)
.Cutoff: If the meal date is today and is after the cutoff time, inform the Patron that it’s too late The Patron can either change the meal date or cancel the order.
Order.Deliver: Delivery or pickup
.Select: The Patron specifies whether the order is to be picked up or delivered
.Location: If the order is to be delivered and there are still available delivery times for the meal date, the Patron shall provide a valid delivery location.
.Notimes: Notify the Patron if there are no available delivery times. The Patron shall either cancel or pick up the order in the cafeteria.
.Times: Display the remaining available delivery times for the meal date, allowing the Patron to request one of the times shown
Order.Menu: Viewing a menu
.Date: Display a menu for the date that the Patron specified.
.Available: The menu for the specified date shall display only those food items for which at least one unit is available in the cafeteria’s inventory and which can be delivered
Order.Units: Ordering multiple meals and multiple food items
.Multiple: Permit the user to order multiple identical meals
.TooMany: If the Patron orders more units of a menu item than are presently in the cafeteria’s inventory, inform the maximum number of units that can order.
Order.Confirm: Confirming an order
.Display: When the Patron indicates no wish to order any more food items, display the ordered itmes, prices, and the payment amount
.Prompt: Prompt the Patron to confirm the meal order.
.Response: The Patron can confirm, edit, or cancel the order.
.More: Let the Patron order additional meals for the same or for a different date.
Order.Pay: Meal order payment
.Method: When the Patron indicates that he is done placing orders, the COS shall ask the user to select a payment method
.Deliver: Se BR-11
.Pickup: If the meal is to be picked up in the cafeteria, the Patron shall choose to pay by payroll deduction or by cash at the time of pickup
.Deduct: If Patron selects payroll deduction, issue a payment request to Payroll
.OK: If the payment request is accepted, display confirmation a message.
.NG: If the payment request is rejected, display the reason for the rejections.
Order.Done: Finishing the process after the Patron confirms the order
.Store: Assign the next available meal order number to the meal and store the meal order
.Inventory: Send a message to the inventory system with the number of units
.Menu: Update the menu for the current order’s order date to reflect any items that are now out of stock in the cafeteria inventory
.Times: Updates the remaining available delivery times for the date of this order
.Patron: Send email message to the Patron with the meal order and payment info
.Cafeteria: Send an email message to the Cafeteria Staff with the meal order information
.Failure: If any step of Order.Done fails, roll back the transaction and notify the user
UI2: Provide a help link from each displayed webpage to explain how to use that page.
UI3: The webpages shall permit complete navigation and food item selection
SI1.1: Transmit the quantities of food items ordered to the Cafeteria Inventory System through a programmatic interface.
SI1.2: Poll the Inventory System to determine whether a requested item is available.
SI1.3: When the Cafeteria Inventory System notifies the COS that a specific food item is not available, the COS shall remove that food item from the menu for the current date.
CI1: Send an email or text message to the Patron to confirm order acceptance
CI2: Send an email or text message to the Patron to report any problems
We have 6 general scenarios: USE, PER, SEC, SAF, AVL, ROB. Each of them associates multiple scenarios.
USE1: Allow a Patron to retrieve the previous meal ordered with a single interaction.
USE2: 95% of new users shall be able to order a meal without errors on their first try.
PER1: Accommodate 400 users and up to 100 concurrent users during the peak usage time, with an estimated average session duration of 8 minutes.
PER2: 95% of webpages generated shall download completely within 4 seconds from the time the user requests the page over a 20 Mbps or faster Internet connection.
PER3: Display confirmation messages to users within an average of 3 seconds and a maximum of 6 seconds after the user submits information to the system.
SEC1: All network transactions that involve financial information or personally identifiable info shall be encrypted per BR-33.
SEC2: Users shall be required to log on for all operations except viewing a menu.
SEC4: The system shall permit Patrons to view only orders that they placed.
SAF1: The user shall be able to see all ingredients in any items, with allergic reactions.
AVL1: The COS shall be available at least of the time between 5am and midnight and at least of the time, excluding scheduled maintenance windows.
ROB1: If the connection between the user and the COS is broken prior to a new order being either confirmed or terminated, the COS shall enable the user to recover an incomplete order and continue working on it.
- Alebrahim, A., Hatebur, D., Heisel, M. (2011): A method to derive software architectures from quality requirements. In Software Engineering Conference (APSEC), 2011 18th Asia Pacific (pp. 322-330). IEEE.
- Bass, L.(2007): Software architecture in practice. Pearson Education India.
- Bass, L., Klein, M., Moreno, G. (2001): Applicability of general scenarios to the architecture tradeoff analysis method (No. CMU/SEI-2001-TR-014). Carnegie-Melon Univ., Soft. Eng. Inst.
- Bass, L., Klein, M., and Bachmann, F.(2002):Quality attribute design primitives and the attribute driven design method. Springer.
- Branzei, R., Dimitrov, D., Tijs, S. (2008): Models in cooperative game theory (Vol. 556). Springer Science & Business Media.
- Garlan, D. (2003): Formal modeling and analysis of software architecture: Components, connectors, and events. In Formal Methods for Software Architectures (pp. 1–24). Springer.
- Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H., Carriere, J. (1998, August): The architecture tradeoff analysis method. In Engineering of Complex Computer Systems, 1998. ICECCS’98. Proceedings. Fourth IEEE International Conference on (pp. 68-78). IEEE.
- Lung, C. H., Xu, X., Zaman, M. (2007): Software architecture decomposition using attributes. International Journal of Software Engineering and Knowledge Engineering, 17(05), 599–613.
- Papadimitriou, C. (2001, July): Algorithms, games, and the internet. In Proceedings of STOC 2001 (pp. 749-753). ACM.
- Roughgarden, T., Tardos, E., Vazirani, V. V. (2007): Algorithmic game theory (Vol. 1). Cambridge: Cambridge University Press.
- Shoham, Y., Leyton-Brown, K. (2008): Multiagent systems: Algorithmic, game-theoretic, and logical foundations. Cambridge University Press.
- Wiegers, K., Beatty, J. (2013): Software requirements. Pearson Education.
- Wojcik, R., Bachmann, F., Bass, L., Clements, P., Merson, P., Nord, R., Wood, B. (2006): Attribute-Driven Design (ADD), Version 2.0 (No. CMU/SEI-2006-TR-023). Carnegie-Melon Univ., Soft. Eng. Inst.
- Woods, E., Hilliard, R. (2005): Architecture Description Languages in Practice Session Report. 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05). p. 243.
- Zhu, L., Aurum, A., Gorton, I., Jeffery, R. (2005): Tradeoff and sensitivity analysis in software architecture evaluation using analytic hierarchy process. Software Quality Journal, 13(4), 357–375.