CS211 Lecture: Use Cases and Initial Functional Testslast revised August 21, 2007Objectives:1. To become familiar use cases / use case diagrams / use case flows of events2. To become familiar with early specification of functional test casesMaterials: 1. Projectable: Figure 3.5 in book2. Video projection: Address Book and ATM examples on the web3. Projectable: Figure 3.6 in the bookI. IntroductionA. As we pointed out at the start of the course, there are many different processes that can be followed in software development (e.g. waterfall life cycle, RUP, etc).B. Regardless of what process is followed, however, certain tasks will need to be done as part of the development process per se - whether all at once, iteratively, or incrementally. In fact, activities like these will be part of any situation in which one uses his/her professional skills to help solve someone else’s problem - not just when creating software or even in a computer field.1. Establishing Requirements: The goal of this is to spell out what constitutes a satisfactory solution to the problem.2. Analysis. The goal of this is to understand the problem. The key question is “What?”.3. Design. The goal of this is to develop the overall structure of a solution to the problem in terms of individual, buildable components and their relationships to one another. The key question is “How?”.4. Implementation. The goal of this task is to actually build the system as designed.5. Installation / Maintenance / RetirementAll of these must be done in a context of commitment to Quality Assurance - ensuring that the individual components and the system as a whole do what they are supposed to do (which may involve identifying their shortcomings and fixing them.)1C. Last class addressed establishing requirements. Today’s focus is on analysis. The goal of the analysis is a thorough understanding of the problem.1. Obviously, this must take place in the mind of the analyst(s); but it also must be documented in some form, especially if - as is often the case - people other than the analyst(s) are involved in later phases of the project.2. Typically, this documentation takes the form of one or more models of the system being analyzed.a) A model is simply a representation of a system.b) For complex problems, more than one model is often needed - each focusing on a different aspect of the system.D. Over the years, software engineers have developed a large array of analysis tools that can be used for modeling a system.1. Each tool is useful for modeling certain aspects of a system; and different sets of tools will be appropriate for different problems. Frequently, in fact, several different tools will be utilized to capture different aspects of a given problem.Example: A carpenter learns to use a wide variety of tools, though he may need only a few for any particular project.2. Some of these tools are discussed in the software engineering course or other courses3. There are also numerous publications and workshops that deal with various tools.4. In this lecture we will consider use cases, As we shall see, use cases are not only used for analysis, but will also serve to drive the remainder of the process. There is a certain “seamlessness” to OO methodologies in this regard.5. We will also talk about the early establishment of functional tests.6. Our next lecture will deal with a topic that sits right on the border between analysis and design; identifying classes.2E. The book uses the “Wheels” system as a continuing example. In addition, we will use two other continuing examples, plus the video store system you are building as a semester project. 1. One is already familiar to many of you - the development of a very simple address book which we used for the last project in CS112.SHOW ON WEB2. The other concerns developing software to simulate an automated teller machine (ATM).SHOW ON WEB GO TO REQUIREMENTS PAGENote: The requirements in this example are somewhat more detailed and specific than would typically be available at the outset of a project. Normally, much of the knowledge we need at this point comes from conversations with the client. This example document embodies some of the fruit of what would typically come from such study.What kind of requirements are these? ASKWhat kinds of non-functional requirements might be appropriate for a system like this?ASKDEMONSTRATION: Example system on the weba) Run itb) Show structure of pages3II. Use CasesA. The use case approach was developed by Ivar Jacobson. It is discussed at some length in the assigned chapter of the book.1. What aspect of a system does the use case model? (QC question a)ASKIt’s functionality. [ answer p. 36 top ]Note: the book discusses use cases as part of the requirements specification stage of system design. I am treating it as part of analysis. The difference really reflects the fact that there is not a clear line between requirements and analysis - in fact, some writers speak of “requirements analysis”2. The use case model consists of a set of complementary elements. Can you name them? (QC question b) What is each?ASK [ answer p. 40 first paragraph under Use Case Diagram ]a) The use case diagram - which we will discuss shortlyb) Scenarios - which we met in conjunction with requirements engineering, and will discuss further belowc) Actors An actor is a type of person - or sometimes another system - that must use the system that is to be built. (1) Actors are not specific people - they are specific roles filled by people. Thus, the same person may need to be regarded as two or more actors if he/she relates to the system in two or more roles.(2) Actors are not part of the system - they are outside the system boundary and use the system.(3) Example: who are the actors for the Wheels system?ASK(a) Adminstrator(b) Receptionist4(c) (Figure 3.14 also shows a Customer as an actor, but the explanatory text makes it clear that this would only make sense in a very high level view which considers the adminstratr and receptionist part of the system.) In general, the customer would not be considered an actor because the customer does not use the system directly; rather, the customer interacts with the receptionist who actually uses the system.(4) Example: who would be the actors for the video store system you are building?ASK(a) The store clerk(b) The managerNote that the requirements distinguish these roles by specifying