1. Week 10: Object Modeling (1)Use Case Model
MSIS 670: Object-Oriented Software Engineering
Week 10: Object Modeling (1)Use Case Model
In this module, basic concepts and brief outline for UML are explained. You have learned, or are learning or are going to learn, some materials in OO technology. For instance, Visual Basic utilizes the object-oriented programming concept; JAVA and C++ are examples of OOPL (object-oriented programming languages); and some conceptual reference to the OODBMS in the advanced database class. Although the interests of hiring industries for systems specialists in this area is very high, I don’t think it is not yet time to completely convert to OO techniques in the systems analysis and design field. Technical requirements (desirable skills) for Information Systems graduates are still in structured analysis and design, data flow diagrams, data modeling. Yet, more and more interviewing people are expressing their interest in students who has OOD skills, which NKU graduates fell behind UC graduates a little, but not far behind. The intention of this module is therefore, to invite you to experience the world of OOA and OOD so that you have pointers as to where to look for necessary information to explore the new world. I would not be surprised, if OOA and OOD are taught in MSIS 630 when you come back to school for another degree.
Fall 2007

2. Figure 1: UML Models using Use-Case Driven Approach (Rosenburg, 1999)
Again, Figure 1is the big picture that shows the key elements of the UML. The approach evolved from an application of theory presented by Booch, Rumbaugh, and Jacobson. Most of activities are iterative and incremental.
The object-modeling approach in a Nutshell (Page-Jones, 2001):
Identify your use cases using use case models.
Identify your real-world domain objects and the generalization and aggregation relationships among those objects (domain model or object model). Start drawing a high level class diagram.
If it’s feasible, do some rapid prototyping of the proposed system. Or gather whatever substantive information you have about the legacy system you are reengineering.
Use a state diagram to show the real-time behavior
Perform robustness analysis for each use case scenario (activity diagram and collaboration diagram). Update your domain model / class diagram with new objects and attributes as you discover them. (Analysis Phase Complete)
Identify the messages, draw a sequence diagram with use case text running down the left side and design information on the right.
Finish the class diagram by adding detailed design information (e.g., visibility values and patterns). (Design Phase Completed).
Figure 1: UML Models using Use-Case Driven Approach (Rosenburg, 1999)
10/20/2007

3. Performing Object Oriented Analysis (OOA)
OOA requires that we identify the objects, their data attributes, associated behavior, and relationships which support the required business system functionality.
We perform object modeling to document the identified objects, the data and behavior they encapsulate, plus their relationships with other objects.
The purpose of OOA is to gain a better understanding of the system and its functional requirements. We perform object modeling to document the identified objects, the data and behavior they encapsulate, plus their relationships with other objects.
There are many references you can read on object modeling and object-oriented analysis. However, the scope of OO technology is too broad to be covered in this class. For the purpose of this class, I want you to understand the basic concepts of object modeling and know where to look at when you need it.
10/20/2007

4. Performing OOA (cont.)
Two general activities when performing object oriented analysis:
Gathering requirements through use case analysis
Finding and identifying the business objects.
Organizing the objects and identifying their relationships in class diagrams
10/20/2007

5. Gathering Requirements
A system’s requirements consist of a document (or a collection of documents) that describes the functionality that system provides.
Use case models show discrete groups of system users as they interact with the system.
10/20/2007

6. Dynamic Modeling: Use Case Model
Use case modeling breaks down the entire scope of system functionality into many smaller statements of system functionality called use cases or business events.
A use case: a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task.
The concept of a use case is similar to that of a process in Data Flow Diagrams (DFDs). Usually a use case is very small behavior that makes up a task all together. (In the end, a use case might be implemented as a class = program)
10/20/2007

7. Use Case Model Composition
Figure 2: Use case model composition
The use case model includes the actors, the system, and the use cases themselves. The set of functionality of a given system is determined through the study of the functional requirements of each actor, expressed in the use cases in the form of 'families' of interactions . Actors are represented by little stick people who trigger the use cases, which are represented as ellipses contained within the system.
An actor represents a role played by a person or a thing that interacts with a system. Actors are determined by observing the direct users of a system those who are responsible for its use or its maintenance as well as the other systems that interact with the one under study. The same physical person may play the role of several actors (vendor, client). Additionally, several people may all play the same role and therefore act as the same actor (all the customers). The name of the actor describes the role played by the user.
10/20/2007

8. Developing Use Case Diagrams
Identify actors
Determine how these actors will get value from the system
Provide a simple and accessible view of the users and their use of the system
Developing Use-Case Diagrams
Use cases are always initiated by an actor (or another use case)
Use cases represent complete functionality of the system
10/20/2007

9. 10/20/2007 Figure 3: Member Services System Use Case Model Diagram
The use case model diagram for the Member Services System is shown in the figure above. It was created using Popkin Software’s System Architect and represents the relationships between the actors and use cases defined for each business subsystem.
Documenting the Use Case Course of Events
For each use case identified, use case’s normal course of events must be documented.
A use case’s normal course of events is a step by step description starting with the actor initiating the use case until the end of the business event.
At this point we only include the major steps which happen the majority of the time (its normal course).
Exception conditions or conditional branching logic will be documented in a later step.
10/20/2007

10. A B C D E F 10/20/2007 Figure 4: Sample Use Case Description
The figure above is a use case description for the Member Services System’s Submit Promotion Order use case. Notice it includes the following items:
The name of actor who initiated the use case.
A high level description of the use case.
A normal event course describing the use case’s major steps, from beginning to end of this interaction with the actor.
Pre condition describing the state the system is in before the use case is executed.
Post condition describing the state the system is in after the use case is executed.
An assumptions section, which includes any non-behavioral issues, such as performance or security, that are associated with the use case, but are difficult to model within the use case’s course of events. D E F
10/20/2007

11. Relationships Between Use Cases
Communicates
b. Uses
Figure 5: Use-case relationships
Use case models represent use cases, actors, and relationships between use cases and actors. UML defines three types of links between actors and use cases:
The Communicates Relationship
The participation of the actor is signaled by a solid line between the actor and the use case. This is the only relationship between actors and use cases.
The Uses (Includes) Relationship
A uses relationship between use cases means that an instance of the source use case also includes the behavior described by the target use case.
The Extends Relationship
An extends relationship between use cases means that the source use case extends the behavior of the destination use case.
c. Extends
10/20/2007

12. Use of Includes and Extends Relationships
Includes (uses): the base (abstract) use case depends on the included use case because it absorbs its behavior
Extends: the base (abstract) use case does not include the subordinate use case, instead, the extension use case depends on the base use case
Use cases may participate in relationships with other use-cases
Two types
Include
One use case references another use case
Extend
Adds new behaviors or actions to a use case
10/20/2007

13. Use-case diagram for a university registration system
Figure 6: Use-case diagram for a university registration system
The use case model diagram for the university registration system is shown in the figure above.
Documenting the Use Case Course of Events
For each use case identified, use case’s normal course of events must be documented.
A use case’s normal course of events is a step by step description starting with the actor initiating the use case until the end of the business event.
At this point we only include the major steps which happen the majority of the time (its normal course).
Exception conditions or conditional branching logic will be documented in a later step.
10/20/2007

14. Class Exercise 1: Use Case Diagram
(see handout)
10/20/2007