UML Weekend Crash Course™ - To Parent Directory

Session 28—Analysis and Architectural Design of a Web Application 289
Performance: How rapidly must the system reply to user requests Web systems
sometimes have more performance limitations than standalone systems. The client
specifies constraints for the responsiveness of the system.
Scalability: How many concurrent users must the system be able to support now and
in the future Many Web systems can be bombarded with hundreds or thousands of
concurrent users. To keep the project cost lower, the clients decide that moderate
growth potential (scalability) is acceptable for now as long as the system is easily
adaptable to a more scalable solution in the future.
Security: How much and what kind of security protection is required Any kind of
networked system can potentially be very vulnerable to malicious attacks. As is true
with most requirements, the greater the security, the greater the cost of the software
and hardware. The client wants to ensure reasonable security and defines the
budget limitations accordingly.
Adaptability: How easy should it be to modify the system to meet new requirements
A more adaptable system will generally be far less expensive to maintain in
the long run and may survive longer before it becomes obsolete. However, developing
a system with high adaptability takes more time and money. The client has put
a very high priority on high adaptability because it expects that this is just the first
cautious step onto the Web and the company expects to add a lot more functionality
to this system later.
Cross-Ref
For a detailed description of the requirements gathering process and the
problem statement, see Session 4.
Creating the Use Case diagram
During the requirements-gathering phase for this project, you will again develop a Use Case
model. This model will not be fundamentally different for a Web system than it is for a non-
Web system. The Use Case model helps you to better understand who will use your system
and what features they will use. Figure 28-1 shows the Use Case diagram for the case study.
There is a Use Case for the user to create an account that will allow him to log in so that he
can store and query his appointments and contacts. The Upload Appointments and Contacts
Use Case will upload a copy of his appointment and contact data onto the Web server for
querying. The user has a general Use Case for querying his appointments and another for
querying his contacts.
Customers using wireless devices such as cell phones will require a different kind of
markup language and will require very different interfaces for the querying to make it
usable on these very limited devices. The requirements-gathering team decided that the
functional differences between traditional wired Web clients (like desktop and laptop
computers) and wireless Web clients (like cell phones) justified separate Use Cases.
However, because they are similar, you show a Use Case generalization to indicate that
the four specific querying Use Cases inherit from the two general querying Use Cases. All
the querying and uploading Use Cases are extended by the Log In Use Case, because the
user must be logged in to run any of these Use Cases.