business analysis itec 630 fall 2009 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Business Analysis ITEC-630 Fall 2009 PowerPoint Presentation
Download Presentation
Business Analysis ITEC-630 Fall 2009

Loading in 2 Seconds...

play fullscreen
1 / 40

Business Analysis ITEC-630 Fall 2009 - PowerPoint PPT Presentation

  • Uploaded on

Business Analysis ITEC-630 Fall 2009. Additional 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Business Analysis ITEC-630 Fall 2009' - JasminFlorian

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
business analysis itec 630 fall 2009

Business AnalysisITEC-630 Fall 2009

Additional UML and Non-UML Diagrams

Professor J. Alberto Espinosa



  • Develop familiarity with some UML modeling diagrams
  • Develop familiarity with important non-UML modeling diagrams
  • Using MS Visio for modeling
important uml diagram models
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
the use case modeling process
The Use Case Modeling Process

Develop Base Use Case Descriptions


Elaborated Use Case Descriptions


Model Extend, Include & Generaliz


Map Use Cases to Object Models

DevelopInstance Scenarios


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

  • 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
how to group use cases into packages
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
example aol student project city search application visio usecase aol vsd
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
activity diagrams
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
object oriented analysis
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.
objects and classes
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
methods or operations
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
  • Objects inheritoperations 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”)
inheritance types and structure gen spec is a and whole part is part of
Inheritance Types and Structure:Gen-Spec (Is a) and Whole-Part (Is part of)


Multiplicities (similar to cardinality):

Not Needed Needed

Methods orOperations




Generalization-Specialization (Is a)

Aggregation or Whole-Part (Is part of)

Two Types of Inheritance

object oriented oo database modeling
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
example course registration oo database model
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)

example atm oo database model
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)

non uml system modeling methods
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)





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


Data Source/Sink (external)

Data Store

Data Flow


[Gane-Sarson Symbols]


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

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

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”

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