1. CMIS 470 Structured Systems Design
Anne Powell, Ph.D.
CMIS 470 Structured Systems Design
Object-Oriented Analysis and Design – Terms, UML, Class Diagrams, Use Cases
Week 4
SIUE

2. Plan for the week Object terms Unified Modeling Language history
CMIS 470
Anne Powell, Ph.D.
Plan for the week
Object terms
Unified Modeling Language history
Use Case Diagrams
Class Diagrams
SIUE

3. Object-Oriented Analysis & Design
Defines all of the types of objects that do the work of the system
Shows how objects interact
Object-oriented design
Defines all additional object types needed to communicate with people and devices in the system
Refines each type of object for implementation

4. Object-Oriented Approach
Views information systems as collections of interacting objects that work together to accomplish tasks
Objects - things in the computer system that can respond to messages
No processes, programs, data entities, or files

5. Classes and Objects A class is a category of similar objects.
Each object is an instance of a class – that is, one specific member of the class.
Class is the template – it contains all the shared attributes and behaviors found in each object of the class.

6. Objects
An object is a person, place, event, or thing about which we want to capture data and define processes.
Where have you heard this definition before?

7. Objects versus Entity Objects can have behaviors.
Behaviors are methods or operations that serve to specify what actions the object can perform.
Object instance is assigned a unique identifier.
Entities have primary and foreign keys.
However, objects have attributes like entities.

8. Example!
Appointment scheduling example

9. Characteristics of OO Approach
Methods and Messages
Encapsulation (Information Hiding)
Hierarchical Inheritance
Polymorphism

10. Behaviors / Methods / Messages
Behaviors specify what the object can do.
A method is nothing more than an action or process that an object can perform. Methods are very much like a function or procedure in a traditional programming language.
A message is the information sent to objects to trigger methods. Essentially a function or procedure call from one object to another object.

11. Encapsulation / Information Hiding
Combining of processes and data into a single object.
All attributes and methods are all together/incorporated in definition of object.
Makes it easier to create new object classes – knows what to do when you want to create a new patient.

12. Hierarchical Inheritance
Classes can have “children”
Parent is “base” or “super” class
Child is “derived” or “sub” class
Similar to subtypes and supertypes of entities.

13. Polymorphism
The same message can be interpreted differently by different classes of objects.

14. Unified Modeling Language (UML)
The Three Amigos – Booch, Jacobson, and Rumbaugh
Objective was to provide a common vocabulary of object-based terms and diagramming techniques for any systems development project from analysis through implementation.

15. UML diagrams 9 diagrams Used throughout SDLC
Use consistent syntax and notation.
Key building block is the use-case.

16. O-O Diagrams Use-Case Captures business requirements for system Class
Illustrates relationships between classes modeled in system
Object
Illustrates relationships between objects; used when actual instances of the classes will better communicate the model
Sequence
Models the behavior of classes within a use-case (temporal sequence)
Collaboration
Models the behavior of classes within a use-case (non-temporal sequence)
Statechart
Examines the behavior of one class within a use-case
Activity
Illustrates the flow of activities in a use-case
Component
Illustrates the physical structure of the software
Deployment
Shows the mapping of software to hardware components

17. Use-Case
Requires you to break system into use cases, small logical pieces of the system and deal with each separately.
In contrast, DFDs and ERDs encompass the entire system in one diagram.

18. Use-Case Diagrams
Graphical specification of the system’s behavior from the perspective of the user(s).
Describes what the system does without describing how the system does it.
They are used to identify and communicate the high-level business requirements for the system.

19. Patient Admission System
A patient will call in to schedule an appointment or cancel an appointment. The office employee should be able to look up the patient’s name to determine if this is an existing patient. The office employee should also be able to lookup any existing unpaid bills the patient may have with the doctor’s office. The system will look up available times and dates for an appointment. When a day/time works for the patient, the system will add a new appointment.
Before available days and times can be recorded, an employee of the doctor’s office will need to create a master schedule. This master schedule will list all the doctor’s schedules and the days and times the office will be open for appointments.
A doctor can alter his or her schedule. When this occurs, the doctor will inform the employee of any days/times when he/she is not available. In addition, the doctor can add days/times when he/she is available to see patients.

20. Use-Case contains:
Actor
Event/Use Case
Association
System boundary

21. Example!
Patient Admission system

22. Example – Student fitness class
When a student wants to add a new class, the manager will check the fitness class schedule for availability. The manager will notify the student of an opening, and the student will pay the fee if there is an opening. The student is then registered for the class.
As new instructors are hired, their availability to teach a class will be recorded. Information on the type of class the instructor is certified to teach as well as the times he/she is available is recorded.
At times, the fitness class schedule must be changed. When this occurs, the manager will change the fitness schedule, and will then notify the instructors and students who are affected by the change.

23. Another example – Placing an order over the internet
Using the web, customers should be able to search for products and identify if the item is available. They should be able to order the item. The functionality that the system should have is listed below:
Search through the inventory of products
Place an order
Receive marketing material on all products
User should be able to place item into shopping cart
User should be able to provide customer information including billing information.

24. Steps in creating a Use-Case
1. Identify use-cases (find major functions)
2. Draw the system boundary
3. Place use-cases on the diagram (6-8 use-cases per diagram)
4. Identify the actors
5. Add associations

25. In addition…
Text documents to document use-cases since use-case diagram does not describe how those use cases are carried out by the actors.
When describing the use-case, you should focus on its external behavior – how it interacts with the actors, rather than how the use case is performed inside the system.

26. Steps in Documentation
1. Create a use case template that has areas labeled Basic Course and Alternative Courses.
2. Ask “What happens?”
3. Ask “And then what happens?”
4. Ask “What else can happen?

27. Documentation examples
Patient Admission
Student fitness registration
Placing a special order

28. Documentation 1.

29. Documentation 1.

30. TIPS Think usage scenario rather than functional requirements.
Describe usage rather than attributes and methods.
Don’t write use-case too tersely.
Don’t ignore system responses.
Don’t forget alternative courses of action.

31. Includes statement When one use-case needs to use another use-case
Two types
Internal – only other use-cases reference
Both external actors and internal use-cases reference

32. Examples
Order Entry
Appointment scheduling

33. Class Diagrams Static Model
During analysis, classes refer to the people, places, events, and things about which the system will capture information.
What is this similar to?

34. Class Diagram vs ERD
What would the class diagram contain that the ERD does not?

35. How to Draw the Class Each class is drawn using three part-rectangles.
Let’s draw a class diagram for the Patient Admission System.

36. Three kinds of Methods
Constructor
Query
Update

37. Relationships in Class Diagram
Again, similar to relationship in ERD.
However, maintained internally by system rather than by primary keys or foreign keys.

38. Multiplicity Just another name for cardinality
… and a different way to show it

39. Multiplicity Instance Represen-tation Description Exactly one 1
A department has one and only one boss.
Zero or more
0..*
An employee has zero to many children.
One or more
1..*
A boss is responsible for one or more employees.
Zero or one
0..1
An employee can be married to zero or one spouse.
Specified range
2..4
An employee can take between two to four vacations each year.
Multiple, disjoint range
1..3, 5
An employee is a member of one to three or five committees.

40. Creating a Class Diagram
1. Identify classes
2. Identify attributes and methods
3. Draw relationships between the classes.

41. For Next Class Meeting…
CMIS 470
Anne Powell, Ph.D.
For Next Class Meeting…
Read pages in book
OO homework 1 DUE
SIUE