Section 18.2.  Architectural View of the Use-Case Model

18.2. Architectural View of the Use-Case Model The architectural view of the use-case model presents the most important actors and use cases (or scenarios of these use cases). Many architecturally significant use cases come from risks of different kinds. Risks can be associated with functional requirements, nonfunctional requirements, or platform specifics. Thus, architecturally significant use cases encompass both application and infrastructure use cases. Groups of use cases in a system follow similar behavioral patterns. You naturally choose one representative use case per group to be part of the architecturally significant use cases, because once you solve that particular use case, you can solve the other use cases in the group. After all, they use the same design principles. This is also why, in the preceding chapters, we explored use cases that belong to different categoriesapplication use cases, application extension use cases, infrastructure use cases, and so forth. The architecturally significant use cases for the Hotel Management System are depicted in Figure 18-2. It shows both application and infrastructure use cases, albeit only the important ones. Note that the architectural view of the use-case model is not just a diagram. The use-case diagram itself does not say much. You need to describe the critical scenarios or at least a brief description of the use cases to help the reader understand what the architecturally significant use cases are about. Figure 18-2. Architecturally significant use cases. [View full size image] The Reserve Room use case is the most important use case, as the fundamental goal of the system is to provide online reservations to customers. Whereas the room reservations by customers are conducted over the Internet, customer check in is performed by counter staff at the hotel itself, and it involves an entirely different set of user interfaces (a thick client as opposed to a Web-based client). The Check In Customer use case is chosen as a representative of functionality provided to hotel staff. Together, the realizations of these three use cases exercise a large portion of the application and domain layers in the design model. In this case, Handle Authorization is deemed critical, since stakeholders are concerned with security. <Handle Distribution> is also critical, since stakeholders are concerned with scalability of the system. The <Perform Transaction> use case is not considered architecturally significant in this case. Nevertheless it is still depicted in Figure 18-2. This is because Handle Authorization and <Handle Distribution> are extension use cases and it is necessary to show the use case which they extend. In this case, it is the <Perform Transaction> use case. To simplify our discussion, we choose only one use case, Reserve Room, to drive the architectural views of the analysis model and design model. In an actual project, you will probably need to describe all the identified architecturally significant use cases.