CMIS 470 Structured Systems Design

CMIS 470Structured Systems Design Object-Oriented Analysis and Design – Terms, UML, Class Diagrams, Use Cases Week 4

Plan for the week • Object terms • Unified Modeling Language history • Use Case Diagrams • Class Diagrams

Object-Oriented Analysis & Design • Object-oriented analysis • 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

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

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.

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?

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.

Example! Appointment scheduling example

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

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.

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.

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.

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

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.

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

O-O Diagrams

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.

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.

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.

Use-Case contains: • Actor • Event/Use Case • Association • System boundary

Example! • Patient Admission system

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.

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.

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

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.

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?

Documentation examples • Patient Admission • Student fitness registration • Placing a special order

Documentation • 1.

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.

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

Examples • Order Entry • Appointment scheduling

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?

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

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

Three kinds of Methods • Constructor • Query • Update

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

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

Multiplicity

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

For Next Class Meeting… • Read pages 250-263 in book • OO homework 1 DUE

CMIS 470 Structured Systems Design