Class10

Asper School of Business University of Manitoba

Systems Analysis & Design

Instructor: Bob Travica

Analyzing system data: Class diagram

Updated: October 2009

3510 Systems Analysis & Design * Bob Travica 2 of 16

Outline Problem domain classes Identifying things to be

represented in system Associations among things Multiplicity Attributes Generalization/Specialization

association Part-Whole association Associations between class objects


Problem domain classes Problem domain

Area of business a system supports Classes & objects are the way to

represent things that make business (products, orders, invoices, customers, employees…)

Identifying and analyzing things in problem domain = essential to defining systems requirements


Identifying things to be represented in system

Physical reality -Person who is a customer

customerNumbercustomerNamecustomerAddress…

Customer

addNew()change() …

System -a class Customer


Identifying things to be represented in system (cont.)

PEOPLE,

OPERATIONS,CONCEPTS,


Identifying things to be represented in system (cont.) List nouns users mention when

discussing system

Event table/use cases as source of potential things:

- Use cases (Create new sale) - Actors (salesperson, customer) - Triggers, data input (customer’s order)

Responses (invoice returned)


Identifying things to be represented in system – Master and Transaction Data

Useful way of thinking:

“Static, permanent things” that make business foundations (employee, department, task, job, inventory, supplier, customer…) master data

versus

“Dynamic, changing things” that make business operations (sales transactions, purchasing transactions, employees’ pay & education, execution of tasks, inventory) transaction data


Associations among things

Association = relationship between things Example: Customer places Order

Associations apply in both directions Order is placed by Customer


Associations among things (cont.)

“PLACES”

“WORKS IN”

CUSTOMER

EMPLOYEE

• Arrowheads are used only if reading violates usual direction of reading, which is left-to-right and top-down.

• Arrange symbols to support usual direction of reading.


Associations betweenMaster and Transaction Data

A rule of thumb in modeling class diagrams: Master data usually do not connect directly to each other but through transaction data


Customer Order

Order

ProductX

Master Data

Transaction Data

orders

places contains


Multiplicity (basic idea)

• Multiplicity: the number of classes or objects allowed on each side of a relationship (one to many, many to many, one to one)

CUSTOMER

EMPLOYEE

“WORKS IN”

Places 1 order, and can place more. But each order is placed by just one person.

Contains 2items or more

Works in 1 dept., while this dept. has other workers as well.


Understanding things -attributes

Think of a database record Specific details of things (pieces of

data) are called attributes Understanding attributes is part of

system analysis Key attribute: uniquely identifies a

thing: Social insurance number, product ID,

vehicle identification number


Attributes

Attributes

• By providing values to attributes, class is instantiated in objects (objects “carved” out of classes)

• Classes have attribute names (“skeleton”), objects have attributes specified – values

Values


Class elements

Class name

Class attributes Class behaviors

(methods, processes/functions working with data)

courseNumbercourseTitlecreditHours

Course

addCourse()

Class


Associations between classes:

Generalization/SpecializationClass (Superclass)

Subclasses of MotorVehicle

Subclasses of Car


Associations between classes:

Part-Whole

Part classes

Whole class


Associations between class objects

courseNumbercourseTitlecreditHours

Course

addCourse()

sectionNumberstartTimeroomNumber

Section

openSection()closeSection()

1 *has

• Typical relationship involving objects from two classes.

• Read: A course has sections, and a section belongs to a course.

Class10

Education

Transcript of Class10