1. Analysis Modeling CpSc 372: Introduction to Software Engineering
Jason O. Hallstrom
Authorship Disclaimer. These slides are intended to serve as teaching instruments for an undergraduate course in Software Engineering. While the slides were formatted by Dr. Hallstrom, the content is compiled from other sources, including the readings listed on the course website, Dr. Pressman’s Software Engineering textbook, and various internet materials. In almost every case, the ideas belong to someone other than Dr. Hallstrom. Indeed, text is often quoted verbatim without an explicit citation (to improve the readability of the slides). The original authors retain all copyrights. If you are interested in citing any of the material in these slides, please contact Dr. Hallstrom for the original source(s). DO NOT CITE THIS PRESENTATION. THE CONTENT SHOULD NOT BE ATTRIBUTED TO DR. HALLSTROM. SEE DR. HALLSTROM IF YOU HAVE ANY QUESTIONS.

2. The Analysis Model
The analysis model consists of a wide variety of diagrammatic forms used to bridge an important gap.
System
Description
Design
Model
Analysis
System information
System function
System behaviors
Purpose:
Describe what the customer wants built
Establish the foundation for the software design
Provide a set of validation requirements

3. Some Rules of Thumb Make sure all points of view are covered
Every element should add value
Keep it simple
Maintain a high level of abstraction
Focus on the problem domain
Minimize system coupling

4. Analysis Modeling Approaches
Structured Analysis:
Object-Oriented Analysis
Models data elements
Attributes
Relationships
Models processes that transform data
Models analysis classes
Data
Processes
Models class collaborations
Techniques from both approaches are typically used in practice.

5. A Roadmap
We are going to examine some of the key tools used for creating an analysis model.
General
Use-cases
Use-case diagrams
Activity diagrams
Swimlane diagrams
These tools are not specific to either structured analysis or OO analysis.
Structured Analysis
OO Analysis
Data object diagrams
ERD diagrams
Data flow diagrams
Process specifications
Class diagrams
Packages
CRC cards
Sequence Diagrams

6. Use-Cases Key Points: Example:
“[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).”
–Ivar Jacobson
Key Points:
A scenario that describes a thread of usage for achieving a functional requirement
Actors represent roles people, devices, or external systems play
System internals are ignored
Example:
See Pressman Chapter 8, Section 8.5.1, pg. 190

7. The Key Elements of a Use-Case
A descriptive name for the scenario
e.g., “Customer Checkout”, “Browse Products”
The primary actor in the scenario
Who is interacting with the system?
The primary actor’s goal
What is the actor trying to accomplish?
Scenario pre-conditions
What assumptions are being made?
Scenario trigger
How was the scenario initiated?
The “sunny day” scenario
In the best case, how does the user interact with the system?
Exceptions
What might go wrong?
Remember why we’re interested in use-cases!

8. Developing a Use-Case
What are the main tasks or functions that are performed by the actor?
What system information will the actor acquire, produce or change?
Will the actor have to inform the system about changes in the external environment?
Does the actor wish to be informed about unexpected changes? …

9. Example: The Online Bookstore
Consider the following excerpt from the initial scope document of a system that will be used by a local bookseller.
The Online Bookstore System (OBS) will be a web-based application that allows customers to browse and purchase online product offerings. The application will support the notion of an online shopping cart, similar to other online retailers such as Amazon.com. The checkout features of the system will be integrated with our credit card transaction processor, as well as our internal billing system. The system will also provide an administrator-view that will allow authorized employees to view and administer products, customers, and orders.
Based on this description, what are the key use-cases?

10. Activity Diagrams
For complex use-cases, the process flow may be difficult to understand.
Activity diagrams provide a graphical view of the interactions in a use-case.
Example:
See Pressman Chapter 8, Section 8.5.2, pg. 192

11. Swimlane Diagrams
In some cases, it help to indicate which actors (or analysis classes) are responsible for which activities.
A swimlane diagram serves this purpose.
Example:
See Pressman Chapter 8, Section 8.5.3, pg. 193

12. Use-Case Diagrams You’ll probably have a lot of use-cases!
Use case diagrams (UCD) provide a diagrammatic table of contents, and a high-level overview of the system.
Diagrams Show:
Actors
Use-cases
Relationships among them
Example UCD