Upload
thora
View
26
Download
0
Embed Size (px)
DESCRIPTION
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. Important UML Diagrams. - PowerPoint PPT Presentation
Citation preview
AUUML and Non-UML Diagrams
Professor J. Alberto Espinosa
Business Analysis andData Design
ITEC-630 Fall 2008
2
Objectives Develop familiarity with some UML modeling diagrams Develop familiarity with important non-UML modeling diagrams Using MS Visio for modeling
3
Important UML Diagrams
4
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
5
The Use Case Modeling Process
Ongoing Use Case Management
Prepare for Use Case Modeling
Initial Use Case
Modeling
Expand Use Case Model
Test Use Cases &
Doc
Organize the Use Cases
DevelopInstance Scenarios
Map Use Cases to Object Models
Model Extend, Include & Generaliz
Develop Base Use Case Descriptions
Done Elaborated Use Case Descriptions
Next
Done
Done
6
Packages
7
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
8
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
9
Example: Loan Processing Application Packages
Submit Loan Request
Request Information on Loan Program
Generate Approval Letter
Evaluate Loan Request
Book a New Loan
Enter Validated Credit References
Generate Loan Agreement
Inquiry on Loan Account Status Generate Standard Payment Notice
Generate Late Notice
Enter Loan Payment InformationClose Out Loan
Refer Delinquent Loan for Debt Collection
Report on Delinquent LoansReport on Portfolio Performance Measures
Forward Summarized Loan Information
Generate Account Activity Sheet
Retrieve Customer Credit Profile
Request Credit Report
Perform Credit Analysis
Loan Submission and Origination
Loan Portfolio Analysis and Reporting Credit Management
Loan Account Maintenance and Care
10
Example:A Package Diagram for ATM System
ATM SystemPackage Diagram
Customer Account Management
ATM Service
Customer Transactions
11
Example: AOL Student ProjectCity Search Application
Visio\UseCase_AOL.vsd
Team 1 Package
Team 2 Package
Functional Division of Responsibilities Team 1: Data Acquisition and Management Functions Team 2: AOL User Front End
12
(1) External Database Sources
(1) Business Data Entry Clerk
(1) Verify Data
(1) Data Quality Mgt Team
(1) Maintain BusinessTypes & Attributes
(1) MaintainSynonym Table
(1) Update Database
(1) Process UsageQueries
Data Partner
Other Sources
Data Management System (Package 1)
Team 2 Package::(2) AOL Database Sources
Example: AOL Project
Team 1 Package –
Data Acquisition
13
Example: AOL ProjectTeam 2 Package – Front End
Data Management System (Package 2)
(2) Web User
(2) Business Accounts Mgt Rep
(2) Sponsored LinkUpdate
(2) Switchboard
(2) Report AccountStatistics
(2) Conduct aSearch
Yellow Pages User
AOL City Guide User
(2) AOL Database Sources
(2) Manage Users
14
Activity Diagrams
15
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
16
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.Customer slides card in and out2.Machine prompts customer for password3.Customer enters password4.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 customer6.System presents user with a choice menu7.Customer selects Withdraw Funds option8.System asks customer for amount to withdraw9.Customer enters amount10.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 receipt14.Log out and thank you customer
Post-conditions Etc.
Example:WithdrawFundsUse Case
17
Example:WithdrawFundsActivityDiagram
18
Submit Loan Request
Evaluate Loan Request
Request Info on Loan Program
Enter Credit References
Generate Approval Letter
Generate Loan Agreement
Book New Loan
Loan Submission and Origination (see slide 9)Using an Activity Diagram to Model Use Case Sequence
Begin Loan Origination
Proceed to Loan Account Maintenance
19
Class Diagrams(Static Structure)
20
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.
21
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
22
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
23
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”)
24
+Add New Course()+Modify Course()+Update Course()+Print Course List()+Print Instructors List()
-Course Number-Semester-Course Name-Credit Points-Instructor ID
Courses
+Add New Course()+Modify Course()+Update Course()+Print Course List()+Print Instructors List()
-Course Number-Semester-Course Name-Credit Points-Instructor ID
Courses
+Print Room Use Report()
-Building Number-Room Number
Campus Course
+Print Equipment Use Report()+Print Room Use Report()
-Location-Room Number-Equipment Neede-Session Manager-Contact Number
Videoconference Cours
+Print Roster()+Print Enrollment Report()
-Student ID-Student Name-EMail Address
Roster
+Print Book Use Report()+Inquire Books for a Course()
-Book ISBN-Book Title-Author-Publisher
Book List
1
0..*
1
0..*
Inheritance Types and Structure:Gen-Spec (Is a) and Whole-Part (Is part of)
Properties
Methods orOperations Class
InheritanceSub-Class
Generalization-Specialization (Is a)Aggregation or
Whole-Part (Is part of)
Multiplicities
(similar to
cardinality):Not Needed Needed
Two Types of Inheritance
25
Object-Oriented Databases
26
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
27
Terminology Equivalence
ERD or Data Model
RelationalDatabase
OO DatabaseOther
Terms Used
Entity Table Class
Instances Records Objects Rows, Tuples
Relationship Relationship Relationship
Cardinality Cardinality Multiplicity
Attributes Fields Properties Columns
N/A N/AOperations,
MethodsPrograms, Procedures
28
Example: Course Registration OO Database Model
+Add New Course()+Modify Course()+Update Course()+Print Course List()+Print Instructors List()
-CourseNumber (PK)-Semester-Course Name-Credit Points-Instructor ID
Courses
+Print Room Use Report()
-Building Number-Room Number
Campus Course
+Print Equipment Use Report()+Print Room Use Report()
-Location-Room Number-Equipment Neede-Session Manager-Contact Number
Videoconference Course
+EnrollStudent()+UpdateEnrollment()+DeleteEnrollment()
-Semester (PK)-CourseNumber (PK, FK)-StudentID (PK, FK)
Enrollment
+AddStudent()+UpdateStudent()+DeleteStudent()
-StudentID (FK)-LastName-FirstName-EMail
Student
1 0..*
Contains
0..* 1
Enrolls
+ Inheritance
+ Operations or Methods
Relationships (like ERD’s) w/multiplicities (like cardinality)
Classes (like entities in ERD’s)
In sum, OO database models are like class diagrams, but also include relationships like in data models (or ERD’s)
29
Example: ATM OO Database Model
+Report Operation Status()+Report Cash Balance()+Update Cash Balance()
-ATM ID-ATM Location-Operation Status-Cash Balance
ATM
+Retrieve Customer Data()+Record Last Transaction()
-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
Customer
+Inquire Account Balance()+Debit Amount()+Credit Amount()
-Client ID-Account Number-Account Type-Account Balance
Customer Account
+Record Transaction()
-Transaction ID-Client ID-Transaction Date-Amount-From Account-To Account-ATM ID
Customer Transactions
«subclass»
-Routing Number-Second Signature
Checking Account
-Min Balance-Interest Rate
Savings Account
«subclass»1
0..*
1*
0..* 1
+Record ATM Transaction()
-ATM ID-Transaction ID-Transaction Type-Transaction Date
ATM Transaction Log
0..* 1
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)
30
Popular non-UML Diagrams
31
Non-UML System Modeling MethodsProcess-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)
32
Process Diagrams:Dataflow Diagrams
33
Data Flow Diagrams (DFD)
label
No.
labellabel
label
Data Source/Sink
(external)
Process Data Store Data Flow
[Gane-Sarson Symbols]
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
34
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
35
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
36
DFD Context Diagram Example Food Ordering System
P
Food OrderingSystem
RestaurantManager
KitchenCustomer
Reports
Food Order
Receipt
Customer Order
37
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”
38
Level-0 DiagramFood Ordering System
P4
ProduceManagement
Reports
P3
UpdateInventory File
P2
Update GoodsSold File
P1
Receive &Transf CustFood Ord
RestaurantManager
KitchenCustomer
D Goods Sold File D1 Inventory File
Management Reports
Formatted Inventory Data
Daily Inventory Depletion Amts
Daily Goods Sold Amounts
Formatted Goods Sold Data
Inventory DataGoods Sold
Customer Order
Receipt
Food Order
Reports
39
Level-1 Diagram for Process P1Food Ordering System
P1.5
GenerateInventory Decr
P1.4
GenerateGoods Sold
Incr
P1.3
TransformOrder to
Kitchen Fmt
P1.2
GenerateCustomerReceipt
P1.1
ReceiveCustomer Order
P3
UpdateInventory File
P2
Update GoodsSold File
Kitchen
Customer
ReceiptCustomer Order 4
Customer Order 2
Customer Order 5
Customer Order 3
Food Order
Customer Order 1
Inventory Data
Goods Sold
40
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