Additional UML and Non-UML Diagrams

1
Business AnalysisITEC-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
DevelopInstance 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
ExampleA Package Diagram for ATM System
11
Example AOL Student ProjectCity Search
ApplicationVisio\UseCase_AOL.vsd

• Functional Division of Responsibilities
• Team 1 Data Acquisition and Management Functions
• Team 2 AOL User Front End

12
Example AOL ProjectTeam 1 Package Data
Acquisition
13
Example AOL ProjectTeam 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
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 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 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 10.1 If not enough funds, notify user 10.2 Go to last step 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 Update customer account balance Dispense cash and print receipt Log out and thank you customer
Post-conditions Etc.
ExampleWithdrawFundsUse Case
17
ExampleWithdrawFundsActivityDiagram
18
(No Transcript)
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) andmethods
  (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 objects 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
Inheritance Types and StructureGen-Spec (Is a)
and Whole-Part (Is part of)
Properties
Multiplicities (similar to cardinality) Not
Needed Needed
Methods orOperations
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 RelationalDatabase OO Database OtherTerms Used
Entity Table Class
Instances Records Objects Rows, Tuples
Relationship Relationship Relationship
Cardinality Cardinality Multiplicity
Attributes Fields Properties Columns
N/A N/A Operations, Methods Programs, Procedures
28
Example Course Registration OO Database Model
Classes (like entities in ERDs)
Relationships (like ERDs) 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 ERDs)
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..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 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 DiagramsDataflow 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

label
Data Source/Sink (external)
Data Store
Data Flow
Process
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 systems major processes
• Which are the primary individual processes at the
  highest possible level
• This is called functional decomposition

38
Level-0 DiagramFood Ordering System
39
Level-1 Diagram for Process P1Food 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