CMIS 470 Structured Systems Design

Post on 19-Jan-2016

38 views 0 download

description

CMIS 470 Structured 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 - PowerPoint PPT Presentation

Transcript of 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 DiagramsUse-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

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.

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

MultiplicityInstance Represe

n-tationDescription

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.

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