1. Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom jasonoh@cs.clemson.edu 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. CpSc 372 A Different View Models analysis classes  Data  Processes Models class collaborations Object-Oriented Analysis Class diagrams Packages CRC cards Sequence diagrams modeled using Modeling Tools: modeled using Object-oriented analysis results in an analysis model that describes a system of collaborating objects. Every object encapsulates a set of data elements, and exports a set of operations for working with those elements.

3. CpSc 372 Categorization Categorization is one of the most important tools in our intellectual toolbox. How do we manage (intellectually) a large number of related items? In object-oriented analysis, we categorize classes using analysis packages. We group the items into categories of items that share common characteristics or satisfy common goals.

4. CpSc 372 Analysis Packages An analysis package is a collection of related analysis classes grouped under a representative name. classes package name UML notation accessibility modifiers Java, C#, and VB.NET use a similar notion for categorizing implementation classes.

5. CpSc 372 CRC Cards Class-responsibility-collaborator (CRC) cards provide another way to organize a system’s classes. The class  Just a simple name Its responsibilities  Description of attributes and operations Its collaborators  Other classes that help satisfy responsibilities Each class is represented by an index card that identifies: “One purpose of CRC cards is to fail early, to fail often, and to fail inexpensively. It is a lot cheaper to tear up a bunch of cards than it would be to reorganize a large amount of source code.”– C. Horstmann

6. CpSc 372 CRC Cards: Example (See Pressman Chapter 8, Section 8.7.4, pg. 208) Class: FloorPlan Description: The FloorPlan class … Responsibilities:Collaborators: Defines floor plan name/type Manages floor plan positioning Scales floor plan for display Incorporates walls, doors, and windows Wall, Door, Window Shows position of video cameras Camera

7. CpSc 372 Model Validation with CRC Cards All participants are given a set of CRC cards  Cards that collaborate should be separated Each use-case is read by the facilitator  When a named class is reached, a token is passed to the person holding the corresponding CRC card The token holder reads the responsibilities on their card  The team determines whether the class’s responsibilities satisfy the use-case  Card responsibilities and collaborations are validated Responsibilities and collaborations are updated A CRC model can be validated by the project team using the following procedure:

8. CpSc 372 An Alternate View CRC cards provide one way to model collaborations. Easy to develop and maintain Easy for stakeholders to understand High-level view of responsibilities and interactions Acid-test validation UML sequence diagrams provide an alternative view, focusing on method interactions. More difficult to develop and maintain Not always easy for stakeholders to understand More detailed view of interactions More detailed validation 1 st 2 nd

9. CpSc 372 UML Sequence Diagrams time objects invocations activations returns

10. CpSc 372 Try It! What would checking-out look like?

11. Analysis Modeling Exercises CpSc 372: Introduction to Software Engineering Jason O. Hallstrom jasonoh@cs.clemson.edu

12. CpSc 372 Exercise: Data Flow Diagrams Create a level 0 data flow diagram for a basic automated teller machine (ATM). You can ignore administrative scenarios. What would the level 1 data flow diagram look like?

13. CpSc 372 Exercise: Use-Case Diagrams Create a use-case diagram for a basic automated teller machine (ATM). You can ignore administrative scenarios.

14. CpSc 372 Exercise: Use-Cases Detail the “withdraw cash” use-case identified in your use-case diagram. Your use-case should identify: The primary actor The goal in context Any preconditions The trigger The scenario Any exceptions

15. CpSc 372 Exercise: Activity Diagrams Create an activity diagram for the “withdraw cash” use-case.