Scenarios Considered: Bus Ticket Booking
Sr. No.
Scenario
Description
1
Purchasing
Customer purchase ticket
2
Make itinerary
Customer prepares travel plan
3
Register and authenticate user
The system register and validate the user.
4
Make purchase
Customer make purchase through payment.
5
Validate purchase
System validate the payment
6
Reserve a bus seat
System reserve a bus seat
7
Print ticket
User print travel ticket
Table 6.1: Bus Ticket Purchase Scenario
5.4.1 Method Inputs:
Method inputs are constituted by the requirements and the scenarios; the inputs are given through use cases. Use cases include six functional requirements and two non-functional requirement. …show more content…
These requirements are taken at the highest level possible. The initial concerns for the architecture design are derived from these requirements. The concerns detected in the bus case study are only modules, which match a function-stereotype package level in UML.
Choosing a module to decompose.
The first time that a module is chosen, any of the modules of the initial proposed architecture can be selected, since they belong to the packet level. In the subsequent times the selection must take into account the unsatisfied requirements with higher priority. In our example, any package can be chosen, since it is the first time.
Choosing an architectural driver: An architectural driver is considered in [2] as “a combination of requirements that shape the architecture or the particular module of the system under consideration”.
Following are the artifacts of the Architecture Method activities:
(a) The initial proposed …show more content…
Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison- Wesley, 2003.
[4]. L. Bass, M. Klein, and L. Northrop. Identifying aspects using architectural rea- soning. In Proceedings Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, pages 51–57, Lancaster, 2004.
[ 5]. C.K. Chang and K. Tae-hyung. Distributed systems design using function-class de- composition with aspects. In Proceedings of the 10th IEEE International Workshop on Future Trends of Distributed Computing Systems, pages 148–153, 2004.
[6]. E. Baniassad and S. Clarke. Theme: An approach for aspect-oriented analysis and design. In Proceedings of the 26th International Conference on Software Engineer- ing (ICSE04) 0270-5257/04, IEEE, pages 158–167, 2004.
[7]. IEEE Architecture Working Group. Ieee recommended practice for architectural de-scription of software-intensive systems. Technical report, IEEE, 2000.
[8]. J. Ivers and et. al. Documenting component and connector views with uml 2.0. Technical Report CMU/SEI-2004, School of Computer Science, Carnegie Mellon University, 2004.
[9]. R.J.A. Buhr. Use case maps as architectural entities for complex systems. IEEE Trans-actions on Software Engineering, 24(112):1131–1155,