Transcript Class Diagrams

Business Analysis and
Data Design
ITEC-630 Fall 2008
UML and Non-UML Diagrams
Professor J. Alberto Espinosa
Objectives



Develop familiarity with some UML modeling diagrams
Develop familiarity with important non-UML modeling diagrams
Using MS Visio for modeling
2
Important
UML Diagrams
3
Important UML
Diagram Models



Use Case Diagrams (done)
Packages – organizing the Use Cases (& other
models)
Activity Diagrams
– Diagrams that explain Use Case workflows (sometimes useful,
but use case text is often preferred)
– Some times also used to diagram dependencies between Use
Cases
– And for business process models

Class Diagrams – describe the types of objects in a
system and the static relationships among them
4
The Use Case
Modeling Process
Done
Develop Base Use
Case Descriptions
Done
Elaborated Use
Case Descriptions
Done
Model Extend,
Include & Generaliz
Map Use Cases to
Object Models
Develop
Instance Scenarios
Prepare for
Use Case
Modeling
Initial Use
Case
Modeling
Expand Use
Case Model
Next
Test Use
Cases &
Doc
Organize
the Use
Cases
Ongoing Use Case Management
5
Packages
6
Packages





Packages are a key aspect of UML
A package contains a group or related Use Cases or model
They are most useful to organize Use Cases and other models
when the get too large or complex to represent in a simple diagram
A package diagram is one that shows “packages” of artifacts (e.g.,
Use Cases, Class Diagrams, etc.) and their respective
dependencies
A dependency between any two entities exist when events, actions
or definitions in one entity influence events, actions or definitions in
the other entity
7
How to Group Use
Cases into Packages





It is better to group Use Cases by business functionality (e.g.,
account management, ATM operation) than by sub-system
A system architect may later combine several Use Case packages
into 1 sub-system, or split a package into more than 1 sub-system
It helps document the scope of each business function supported
by the system
Focus on what makes the most sense for primary actors
Two important principles to keep in mind:
– Maximize cohesion (i.e., business function similarity) within packages
– Minimize coupling (i.e., dependencies) between packages
8
Example: Loan Processing Application Packages
Submit Loan Request
Evaluate Loan Request
Request Information on Loan
Program
Enter Validated Credit References
Generate Approval Letter
Book a New Loan
Close Out Loan
Enter Loan Payment Information
Inquiry on Loan Account Status
Generate Late Notice
Generate Standard Payment
Notice
Refer Delinquent Loan for Debt
Collection
Loan Account Maintenance and Care
Generate Loan Agreement
Loan Submission and Origination
Retrieve Customer Credit Profile
Generate Account Activity Sheet
Report on Portfolio Performance
Measures
Forward Summarized Loan
Information
Report on Delinquent Loans
Loan Portfolio Analysis and Reporting
Request Credit Report
Perform Credit Analysis
Credit Management
9
ATM System
Package Diagram
Example:
A Package
Diagram for
ATM System
Customer Account Management
Customer Transactions
ATM Service
10
Example: AOL Student Project
City Search Application
Visio\UseCase_AOL.vsd
Team 2 Package
Team 1 Package


Functional Division of Responsibilities
Team 1: Data Acquisition and Management Functions
Team 2: AOL User Front End
11
Data Management System
(Package 1)
Team 2 Package::(2) AOL Database Sources
(1) Update Database
Example:
AOL Project
Team 1
Package –
Data
Acquisition
Data Partner
(1) External Database Sources
(1) Maintain Business
Types & Attributes
(1) Business Data Entry Clerk
Other Sources
(1) Process Usage
Queries
(1) Maintain
Synonym Table
(1) Data Quality Mgt Team
(1) Verify Data
12
Example: AOL Project
Team 2 Package – Front End
Data Management System
(Package 2)
(2) Sponsored Link
Update
Yellow Pages User
(2) Report Account
Statistics
(2) Business Accounts Mgt Rep
(2) Web User
AOL City Guide User
(2) Manage Users
(2) Conduct a
Search
(2) Switchboard
(2) AOL Database Sources
13
Activity Diagrams
14
Activity Diagrams



General: they describe sequencing of activities
Particularly useful to visualize business workflows
and processes
Sometimes used with Use Cases:
– To diagram the flow of events within a Use Case
– To model dependencies between Use Cases

Activity diagrams are also used for other models,
such as:
– Business process models
– Test cases
15
Use Case ID
UC-100
Use Case
Withdraw Funds
Actors
(P) Customer
Description
Customer logs in, selects withdraw funds, enters amount, gets cash
Pre-conditions
Welcome screen is on
Flow of Events
1.
2.
3.
4.
Post-conditions
Etc.
Example:
Withdraw
Funds
Use Case
Customer slides card in and out
Machine prompts customer for password
Customer enters password
If password is incorrect
4.1 Go back to step 2
4.2 If password is incorrect 3 times
4.2.1 Retain card and notify user
4.2.1 Go to last step
5. System authenticates customer
6. System presents user with a choice menu
7. Customer selects Withdraw Funds option
8. System asks customer for amount to withdraw
9. Customer enters amount
10.Check funds in customer account
10.1 If not enough funds, notify user
10.2 Go to last step
11.Check availability of cash in ATM
11.1 If not enough cash, notify user
11.2 Notify ATM Service
11.3 Go to last step
12.Update customer account balance
13.Dispense cash and print receipt
14.Log out and thank you customer
16
Example:
Withdraw
Funds
Activity
Diagram
17
Loan Submission and
Origination (see slide 9)
Using an Activity Diagram to
Model Use Case Sequence
Begin Loan
Origination
Request Info on Loan Program
Submit Loan Request
Proceed to Loan
Account Maintenance
Book New Loan
Enter Credit References
Generate Loan Agreement
Evaluate Loan Request
Generate Approval Letter
18
Class Diagrams
(Static Structure)
19
Object-Oriented Analysis




OO is most prevalent software system development
paradigm today
There are OO analysis, design and programming
methods
These are different, but related concepts and methods
OO analysis aims to discover and describe objects
(their properties/attributes and behaviors/methods) in
the system domain – what they are, their attributes,
their behaviors (i.e., methods), how they collaborate
with and relate to each other, etc.
20
Objects and Classes






An object is a person, place, event or other thing
A class is a category or grouping of similar objects
(e.g., professors)
We say that an object is an “instance” of a class
(e.g., A. Espinosa)
An object has attributes (i.e., data) and
methods (or operations) (i.e., programs)
Objects inherit attributes and methods from their class
Classes inherit attributes and methods from super-classes
21
Methods or Operations

Methods or Operations are procedures/programs (written
in an OO programming language) to update, manipulate or
query data in object attributes

They are functions or services available to all objects of the
class in which the methods are defined – 4 main types:
1. Constructor – creates a new object in the class (equivalent to
Insert SQL query or C in CRUD matrix)
2. Query – accesses data in an object’s attributes, no side effects
(equivalent to Select SQL query or R in CRUD matrix)
3. Update – alters the content of an object, with side effects
(equivalent to Update SQL query or U in CRUD matrix)
4. Scope – applies to the whole class or a range of objects rather
than a single object
22
Inheritance

Objects inherit operations and properties
from their respective class

Classes can be created under other classes

Sub-classes inherit operations and properties
from super-classes

Thus, OO models have an “inheritance
structure”
– Gen-Spec or Generalization (“is a”)
– Whole-Part or Aggregation (“is part of”)
23
Inheritance Types and Structure:
Gen-Spec (Is a) and Whole-Part (Is part of)
Properties
Methods or
Operations
Courses
Courses
-Course Number
-Semester
-Course Name
-Credit Points
-Instructor ID
+Add New Course()
+Modify Course()
+Update Course()
+Print Course List()
+Print Instructors List()
-Course Number
-Semester
-Course Name
-Credit Points
-Instructor ID
+Add New Course()
+Modify Course()
+Update Course()
+Print Course List()
+Print Instructors List()
Multiplicities
(similar to
cardinality):
Not Needed
Needed
Class
Inheritance
Sub-Class
1
0..*
0..*
Campus Course
Videoconference Cours
Roster
Book List
-Building Number
-Room Number
+Print Room Use Report()
-Location
-Room Number
-Equipment Neede
-Session Manager
-Contact Number
+Print Equipment Use Report()
+Print Room Use Report()
-Student ID
-Student Name
-EMail Address
+Print Roster()
+Print Enrollment Report()
-Book ISBN
-Book Title
-Author
-Publisher
+Print Book Use Report()
+Inquire Books for a Course()
Generalization-Specialization (Is a)
Aggregation or
Whole-Part (Is part of)
Two Types of Inheritance
24
Object-Oriented
Databases
25
Object Oriented (OO)
Database Modeling
 OO
Database Models or Class Diagrams are like ERDs
– An object is like an instance of an entity
or a record (i.e., row) in a database table
– A class is like an entity in an ERD or a table in the
database
– Attributes are called properties
 But
they also include operations (or methods) and
inheritance
26
Terminology Equivalence
ERD or
Data Model
Relational
Database
OO Database
Other
Terms Used
Entity
Table
Class
Instances
Records
Objects
Relationship
Relationship
Relationship
Cardinality
Cardinality
Multiplicity
Attributes
Fields
Properties
Columns
N/A
N/A
Operations,
Methods
Programs,
Procedures
Rows, Tuples
27
Example: Course Registration OO Database Model
Enrollment
Courses
-CourseNumber (PK)
-Semester
-Course Name
-Credit Points
-Instructor ID
+Add New Course()
+Modify Course()
+Update Course()
+Print Course List()
+Print Instructors List()
Contains
1
0..*
-Semester (PK)
-CourseNumber (PK, FK)
-StudentID (PK, FK)
+EnrollStudent()
+UpdateEnrollment()
+DeleteEnrollment()
Enrolls
0..* 1
Student
-StudentID (FK)
-LastName
-FirstName
-EMail
+AddStudent()
+UpdateStudent()
+DeleteStudent()
Classes (like entities in ERD’s)
Relationships (like ERD’s)
w/multiplicities (like cardinality)
+ Operations or Methods
+ Inheritance
Campus Course
Videoconference Course
-Building Number
-Room Number
+Print Room Use Report()
-Location
-Room Number
-Equipment Neede
-Session Manager
-Contact Number
+Print Equipment Use Report()
+Print Room Use Report()
In sum, OO database
models are like class
diagrams, but also include
relationships like in data
models (or ERD’s)
28
Example: ATM OO Database Model
ATM
ATM Transaction Log
-ATM ID
-Transaction ID
-Transaction Type
-Transaction Date
+Record ATM Transaction()
0..* 1
-ATM ID
-ATM Location
-Operation Status
-Cash Balance
+Report Operation Status()
+Report Cash Balance()
+Update Cash Balance()
Checking Account
Savings Account
-Routing Number
-Second Signature
-Min Balance
-Interest Rate
«subclass» «subclass»
1
0..*
Customer
Customer Transactions
-Transaction ID
-Client ID
-Transaction Date
-Amount
-From Account
-To Account
-ATM ID
+Record Transaction()
Customer Account
0..*
1
-Client ID
-Account Number
-Account Type
-Account Balance
+Inquire Account Balance()
+Debit Amount()
+Credit Amount()
*
Multiplicity (UML term) = Cardinality (database term)
How many instances of one class can be associated with another class
0..1 (0 or 1); 1 (only 1), 0..* (0 or many), * (many, but not 0)
1
-Customer ID
-Last Name
-First Name
-Contact Info
-SSN
-Home ATM
-Last Withdrawal Date
-Last Deposit Date
-Last Funds Transfer Date
-Last Balance Inquiry Date
+Retrieve Customer Data()
+Record Last Transaction()
29
Popular
non-UML
Diagrams
30
Non-UML System Modeling Methods
Process-Oriented Methods (process-driven systems):
 Flowcharts
 Data Flow Diagrams (DFD)
 Structure Charts
Data-Oriented Methods (data-driven systems):
 Data Modeling: Entity Relationship Diagrams (ERD)
 Data Dictionaries
Control-Oriented Methods (real-time systems):
 State Transition Diagrams (STD)
31
Process Diagrams:
Dataflow Diagrams
32
Data Flow Diagrams (DFD)
Process oriented modeling method that shows how the data
moves through a system
 Most suitable for process oriented systems
 Good visual representation of a system
 Simple: only uses only 4 symbols
No.
label
label
Data
Source/Sink
(external)
label
label
Process
Data Store
Data Flow
[Gane-Sarson Symbols]
33
Data Flow Diagram Levels
DFDs start at a high level of abstraction
and proceed to more detailed levels:




Context Diagram
Level-0 Diagram
Level-1, 2, … n Diagrams
Primitive DFD
34
Context Diagram



Highest level view of the system
Contains ONLY one process, i.e., the “system”
It also shows all external data sources/sinks
(“electronic” or “manual”)


And all data flows between data sources/sinks
and the process
It contains NO data stores
35
DFD Context Diagram Example
Food Ordering System
Kitchen
Customer
P
Customer Order
Food Ordering
System
Food Order
Receipt
Reports
Restaurant
Manager
36
Level-0 Diagram




Expands the main process from context diagram
Represents the system’s major processes
Which are the primary individual processes at
the highest possible level
This is called “functional decomposition”
37
Level-0 Diagram
Food Ordering System
Kitchen
Customer
Customer Order
P1
Receipt
Receive &
Transf Cust
Food Ord
Food Order
P2
P3
Update Goods
Sold File
Inventory Data
Goods Sold
Formatted Goods Sold Data
D
Goods Sold File
Update
Inventory File
Formatted Inventory Data
Daily Goods Sold Amounts
D1
Inventory File
P4
Reports
Restaurant
Manager
Management Reports
Produce
Management
Reports
Daily Inventory Depletion Amts
38
Level-1 Diagram for Process P1
Food Ordering System
Customer Order 1
P1.1
Customer
Customer Order 5
Receive
Customer Order
P1.5
P3
Generate
Inventory Decr
Inventory Data
Update
Inventory File
Customer Order 2
Receipt
Customer Order 3
Customer Order 4
P1.2
P1.4
P1.3
Generate
Customer
Receipt
Generate
Goods Sold
Incr
Transform
Order to
Kitchen Fmt
Food Order
Kitchen
Goods Sold
P2
Update Goods
Sold File
39
Primitive DFD



Lowest level DFD
When further decomposing no longer necessary
What next?
– Describe the primitive in structured English
– Or using pseudo-code
– Turn over to programmers to start coding modules
40