1. Business Analysis ITEC-630 Fall 2009
Additional UML and Non-UML Diagrams
Professor J. Alberto Espinosa

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
Develop Base Use Case Descriptions
Done
Elaborated Use Case Descriptions
Done
Model Extend, Include & Generaliz
Done
Map Use Cases to Object Models
Develop Instance Scenarios
Next
Prepare for Use Case Modeling
Initial Use Case Modeling
Expand Use Case Model
Test Use Cases & Doc
Organize the Use Cases
Ongoing Use Case Management

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

10. Example: A Package Diagram for ATM System

11. Functional Division of Responsibilities
Example: AOL Student Project City Search Application Visio\UseCase_AOL.vsd
Functional Division of Responsibilities
Team 1: Data Acquisition and Management Functions
Team 2: AOL User Front End

12. Example: AOL Project Team 1 Package – Data Acquisition

13. Example: AOL Project Team 2 Package – Front End

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. Example: Withdraw Funds Use Case
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
Customer slides card in and out
Machine prompts customer for password
Customer enters password
If password is incorrect Go back to step If password is incorrect 3 times Retain card and notify user Go to last step
System authenticates customer
System presents user with a choice menu
Customer selects Withdraw Funds option
System asks customer for amount to withdraw
Customer enters amount
Check funds in customer account If not enough funds, notify user Go to last step
Check availability of cash in ATM If not enough cash, notify user Notify ATM Service Go to last step
Update customer account balance
Dispense cash and print receipt
Log out and thank you customer
Post-conditions
Etc.
Example: Withdraw Funds Use Case

17. Example: Withdraw Funds Activity Diagram

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:
Constructor – creates a new object in the class (equivalent to Insert SQL query or C in CRUD matrix)
Query – accesses data in an object’s attributes, no side effects (equivalent to Select SQL query or R in CRUD matrix)
Update – alters the content of an object, with side effects (equivalent to Update SQL query or U in CRUD matrix)
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. Aggregation or Whole-Part (Is part of)
Inheritance Types and Structure: Gen-Spec (Is a) and Whole-Part (Is part of)
Properties
Multiplicities (similar to cardinality):
Not Needed Needed
Methods or Operations
Class
Inheritance
Sub-Class
Generalization-Specialization (Is a)
Aggregation or Whole-Part (Is part of)
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
Relational Database
OO Database
Other Terms Used
Entity
Table
Class
Instances
Records
Objects
Rows, Tuples
Relationship
Cardinality
Multiplicity
Attributes
Fields
Properties
Columns
N/A
Operations, Methods
Programs, Procedures

28. Example: Course Registration OO Database Model
Classes (like entities in ERD’s)
Relationships (like ERD’s) w/multiplicities (like cardinality)
+ Operations or Methods
+ Inheritance
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
Multiplicity (UML term) = Cardinality (database term) How many instances of one class can be associated with another class (0 or 1); 1 (only 1), 0..* (0 or many), * (many, but not 0)

30. Popular non-UML Diagrams

31. 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)

32. Process Diagrams: Dataflow Diagrams

33. 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
label
label
Data Source/Sink (external)
Process
Data Store
Data Flow
[Gane-Sarson 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

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 Diagram Food Ordering System

39. Level-1 Diagram for Process P1 Food Ordering System

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