OOAD and UML

In this Business Analysis Training session, you will learn Structured vs. Object Orient Analysis and Design SAD vs. OOSAD. Topics covered in this session are:
• SAD Phases
• OOAD Phases
• SAD vs. OOAD software development
• Adopted Books
• UML in practice
• Conclusions & Recommendations
To learn more about this course, visit this link: https://www.mindsmapped.com/courses/business-analysis/business-analysis-fundamentals-with-hands-on-training/

1. Page 1Classification: Restricted
Business Analysis
Training
Structured vs. Object Orient Analysis and Design
SAD vs. OOSAD

2. Page 2Classification: Restricted
Agenda
•SAD Phases
•OOAD Phases
•SAD vs. OOAD software development
•Adopted Books
•UML in practice
•Conclusions & Recommendations

3. Page 3Classification: Restricted
Key Differences Between Structured and
Object-Oriented Analysis and Design
Structured Object-Oriented
MethodologySDLC Iterative/Incremental
Focus Processs Objects
Risk High Low
Reuse Low High
MaturityMature and widespreadEmerging (1997)
Suitable forWell-defined projects with
stable user requirements
Risky large projects
with changing user
requirements

4. Page 4Classification: Restricted
Key Differences Between Structured and
Object-Oriented Analysis and Design
Phase Structured Object-Oriented
AnalysisStructuring Requirements
•DFDs
•Structured English
•Decision Table / Tree
•ER Analysis
Requirement Engineering
•Use Case Model (find Uses Cases, Flow of
Events, Activity Diagram)
•Object Model
•Find Classes & class relations
•Object Interaction: Sequence &
collaboration Diagram, State Machine
Diagram,
•Object to ER Mapping
Design •DB design
•(DB normalization)
•GUI Design
•(forms & reports)
•Physical DB design
•Design elements
•Design system Architecture
•Design classes: Checking The Model,
Combine Classes, Splitting Classes,
Eliminate Classes
•Design components
•GUI design

5. Page 5Classification: Restricted
Definitions
•Systems Analyst
•Responsible for analysis and design of information systems
•Software
•Computer programs and associated documentation such as
requirements, design models and user manuals
•Software Engineering
•IEEE standard 610-12 (1999) defines software engineering as "the
application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the
application of engineering to software.

6. Page 6Classification: Restricted
SW Project phases
•Any project in the world has the following phases:
•Planning
•Analysis: system requirements are studied and structured
•Design: recommended solution is converted into logical and then
physical system specifications
•Logical design–all functional features of the system chosen for
development in analysis are described independently of any
computer platform
•Physical design–the logical specifications of the system from logical
design are transformed into the technology-specific details from
which all programming and system construction can be
accomplished
•Implementation
•Testing
•Maintenance

7. Page 7Classification: Restricted
Outline
•SAD Phases
•OOAD Phases
•SAD vs. OOAD software development
•Adopted Books
•UML in practice
•Conclusions & Recommendations

8. Page 8Classification: Restricted
Structured Analysis and Design (SAD)
A. Analysis Phase
1.Determine system requirements
2.Structuring system process requirements
3.Logical requirements (logical modeling)
4.Structuring system data requirements
B. Design Phase
1.Database design (DB normalization)
2.Forms and report design (GUI design)

9. Page 9Classification: Restricted
Structured Analysis and Design (SAD)
A. Analysis Phase
1.Determine system requirements:
•Interviewing: individuals and/or group
2.Structuring system process requirements
•Data Flow Diagram (DFD) –logical process modeling
•DFD levels (process decomposition)
•Context diagram
•4 type of DFD
•Current physical: Adequate detail only
•Current logical: Enables analysts to understand current system
•New logical: Technology independent, Show data flows, structure,
and functional requirements of new system
•New physical: Technology dependent

10. Page 10Classification: Restricted
DFD Symbols
Comparison of DeMarco
and Yourdon
and Ganeand Sarson
DFD symbol sets

11. Page 11Classification: Restricted
Diagram Depiction of Project Scope
Context-level data flow diagram showing project scope for Purchasing
Fulfillment System (Pine Valley Furniture)

12. Page 12Classification: Restricted
Context Diagram
Context diagram of Hoosier Burger’s food-ordering system

13. Page 13Classification: Restricted
Developing DFDs (Cont.)
•Level-0 diagram is a data flow diagram that represents a system’s major
processes, data flows, and data stores at a high level of detail.
•Processes are labeled 1.0, 2.0, etc. These will be decomposed into more
primitive (lower-level) DFDs.

14. Page 14Classification: Restricted
Level-0 Diagram
Level-0 DFD of Hoosier Burger’s
food-ordering system

15. Page 15Classification: Restricted
Data Flow Diagramming Rules

16. Page 16Classification: Restricted
Data Flow Diagramming Rules (Cont.)

17. Page 17Classification: Restricted
Decomposition of DFDs
•Functional decomposition is an iterative process of breaking a system
description down into finer and finer detail.
•Creates a set of charts in which one process on a given chart is
explained in greater detail on another chart.
•Continues until no subprocesscan logically be broken down any further.

18. Page 18Classification: Restricted
Decomposition of DFDs (Cont.)
•Primitive DFD is the lowest level of a DFD.
•Level-1 diagramresults from decomposition of Level-0 diagram.
•Level-n diagram is a DFD diagram that is the result of nnested
decompositions from a process on a level-0 diagram.

19. Page 19Classification: Restricted
Level-1 DFD
Level-1 DFD shows
the sub-processes
of one of the
processes in the
Level-0 DFD.
This is a Level-1 DFD
for Process 4.0.
Processes are labeled 4.1, 4.2, etc.
These can be further decomposed in
more primitive (lower-level) DFDs if
necessary.
Level-1 diagram showing the decomposition
of Process 4.0 from the level-0 diagram for
Hoosier Burger’s food-ordering system

20. Page 20Classification: Restricted
Level-nDFD
Level-nDFD shows
the sub-processes
of one of the
processes in the
Level n-1DFD.
This is a Level-2
DFD for Process
4.3.
Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest
level of the hierarchy, it is called a primitive DFD.
Level-2 diagram showing the decomposition of
Process 4.3 from the level-1 diagram for Process
4.0 for Hoosier Burger’s food-ordering system

21. Page 21Classification: Restricted
Four Different Types of DFDs
•Current Physical
•Process labels identify technology (people or systems) used to process
the data.
•Data flows and data stores identify actual name of the physical media.
•Current Logical
•Physical aspects of system are removed as much as possible.
•Current system is reduced to data and processes that transform them.

22. Page 22Classification: Restricted
Four Different Types of DFDs (Cont.)
•New Logical
•Includes additional functions.
•Obsolete functions are removed.
•Inefficient data flows are reorganized.
•New Physical
•Represents the physical implementation of the new system.

23. Page 23Classification: Restricted
SAD –Analysis phase (Cont.)
3.Logical requirements (logical modeling)
•Use structured English to represent DFD because DFD does not show
logic
•Use decision table / tree (logical choice in conditional statement
4.Structuring system data requirements
•ER diagram

24. Page 24Classification: Restricted
Modeling Logic with Decision Tables
•Decision table: a matrix representation of the logic of a decision which
specifies the possible conditions for the decision and the resulting actions.
•Best used for complicated decision logic.

25. Page 25Classification: Restricted
Modeling Logic with Decision Tables (Cont.)
Complete decision table for payroll system example

26. Page 26Classification: Restricted
Modeling Logic with Decision Tables (Cont.)
•Condition stubs: that part of a decision table that lists the conditions
relevant to the decision
•Action stubs: that part of a decision table that lists the actions that result
for a given set of conditions

27. Page 27Classification: Restricted
Modeling Logic with Decision Tables (Cont.)
•Rules: that part of a decision table that specifies which actions are to be
followed for a given set of conditions
•Indifferent condition: in a decision table, a condition whose value does not
affect which actions are taken for two or more rules

28. Page 28Classification: Restricted
Modeling Logic with Decision Tables (Cont.)
•Procedure for Creating Decision Tables
•Name the condition and the values that each condition can assume.
•Name all possible actions that can occur.
•List all possible rules.
•Define the actions for each rule.
•Simplify the table.

29. Page 29Classification: Restricted
Modeling Logic with Decision Tables (Cont.)
Reduced decision table for payroll system example

30. Page 30Classification: Restricted
SAD –Analysis phase (Cont.)
B. Design Phase
1.Database design (DB normalization)
2.Forms and report design (GUI design)

31. Page 31Classification: Restricted
DB Normalization
•Normalization: the process of converting complex data structures into
simple, stable data structures
•The result of normalization is that every nonprimarykey attribute
depends upon the whole primary key.
•First Normal From (1NF)
•Unique rows, no multivalued attributes
•All relations are in 1NF
•Second Normal Form (2NF)
•Each nonprimarykey attribute is identified by the whole key (called
full functional dependency)
•Third Normal Form (3NF)
•Nonprimarykey attributes do not depend on each other (i.e. no
transitive dependencies)

32. Page 32Classification: Restricted
Object-Oriented Analysis and Design (OOAD)
•Based on objects rather than data or processes
•Object: a structure encapsulating attributes and behaviors of a real-world
entity
•Object class: a logical grouping of objects sharing the same attributes and
behaviors
•Inheritance: hierarchical arrangement of classes enable subclasses to
inherit properties of superclasses

33. Page 33Classification: Restricted
Outline
•SAD Phases
•OOAD Phases
•SAD vs. OOAD software development
•UML in practice

34. Page 34Classification: Restricted
OOSAD
A. Analysis Phase
•Structuring requirements (Use cases)
•Conceptual data modeling (class diagram)
•Object relationship modeling
•Class diagram → ER diagram
•Analysis classes
•Class stereotypes
•Sequence diagram
•Communication diagram
•activity diagram
•State machine diagram

35. Page 35Classification: Restricted
OOSAD
B. Design Phase
•Physical DB design
•Design elements
•Design classes
•Design components
•Design system Architecture
•GUI design

36. Page 36Classification: Restricted
Visual modeling with rational rose text book
•Focus on Rational Unified Process (RUP)
•Talk about 4+1 architectural view Later on the textbook
•Rational Rose Example

37. Page 37Classification: Restricted
OOAD project phases (my reading and experience)
•Analysis
•Requirement gathering, analysis, and modeling (Requirement Engineering)
•Use Case Model find Uses Cases, Flow of Events, Activity Diagram)
•Object Model
•Find Classes & class relations,
•Object Interaction: Sequence & collaboration Diagram, State Machine
Diagram,
•Object to ER Mapping
•Design
•Physical DB design
•Design elements
•Design system Architecture
•Design classes: Checking The Model, Combine Classes, Splitting Classes,
Eliminate Classes
•Design components
•GUI design

38. Page 38Classification: Restricted
Use Cases Examples

39. Page 39Classification: Restricted
Use Case Diagram in the Course Registration SystemStudent
Billing system
Register For Courses
Maintain Course Information
Maintain Professor InformationMaintain Student Information
Create Course Catalog
Registrar
Select Courses to teach
Request Course Roster
Professor

40. Page 40Classification: Restricted
Use Case: Clinic System Example

41. Page 41Classification: Restricted
Use Case: Bank System Example

42. Page 42Classification: Restricted
Activity Diagram Examples

43. Page 43Classification: Restricted
Swimlanes Registrar Professor
Select courses
to teach
Create
curriculum
Create
catalog
Place catalog
in bookstore
Open
registration
Close
registration
[ Registration time period expired ]
Mail catalog
to students
Activity Diagram for Registration System

44. Page 44Classification: Restricted
Activity Diagram for Back System

45. Page 45Classification: Restricted
Activity Diagram for Shipment System

46. Page 46Classification: Restricted
Finding classes (thinking in objects)
(Registration System)
Entity
class
Boundary class (GUI
interface)
RegistrationManager
addStudent(Course, Student)
Control class
Course
name
numberCredits
open()
addStudent(Student)
Entity
class

47. Page 47Classification: Restricted
Class relations: Inheritance and Multiplicity
(Registration System)
1
0..*
0..*
1
1
1..*
4
3..10
0..4
1
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, Student)
name
numberCredits
open()
addStudent(Student)
major
location
open()
addStudent(Student}
tenureStatus
ScheduleAlgorithm
name
RegistrationUser

48. Page 48Classification: Restricted
Relationships
•Three types of relationships are:
•Association
•Aggregation
•Dependency

49. Page 49Classification: Restricted
public class BlogAccount{
// Attribute introduced thanks to the association with the BlogEntryclass
private BlogEntry[] entries;
// ... Other Attributes and Methods declared here ...
}
public class BlogEntry
{
// The blog attribute has been removed as it is not necessary for the
// BlogEntryto know about the BlogAccountthat it belongs to.
// ... Other Attributes and Methods declared here ...
}

50. Page 50Classification: Restricted
Object-Relational Modeling
•Purposes of Object-Relational Modeling
•Create entity classes
•Produce database structures
•Enhance and finalize the attributes in the data model

51. Page 51Classification: Restricted
Object-Oriented Extensions to Relational
Modeling
•Generalization
•Multivalued attributes (OK to violate atomicity requirement of 1NF)
•Aggregation
•Object identifiers
•Pointers
•Behaviors
•Richer set of data types
Object-relational Data Model

52. Page 52Classification: Restricted
Translating Conceptual Data Model to Object-
Relational Model
•Translate classes
•Translate relationships
•Normalize object relations
•Merge object relations

53. Page 53Classification: Restricted
Supertype/subtype relationships

54. Page 54Classification: Restricted
These are implemented as one-to-one
relationships
Mapping Supertype/subtype relationships to
relations

55. Page 55Classification: Restricted
Sequence Diagram
•A sequence diagram displays object
interactions arranged in a time
sequence
: Student
registration
form
registration
manager
math 101
1: fill in info
2: submit
3: add student to math 101
4: add student
5: are you open?
6: add student
math 101
section 1

56. Page 56Classification: Restricted
public class MessageReceiver
{
public void foo( )
{
// Do something inside foo.
}
}
public class MessageCaller
{
private MessageReceivermessageReceiver;
// Other Methods and Attributes of the class are declared here
// The messageRecevierattribute is initialized elsewhere in
// the class.
public doSomething(String[] args)
{
// The MessageCallerinvokes the foo( ) method
this.messageReceiver.foo( ); // then waits for the method to return
// before carrying on here with the rest of its work
}
}

57. Page 57Classification: Restricted
: Registrar
course form :
CourseForm
theManager :
CurriculumManager
aCourse :
Course
1: set course info
2: process
3: add course
4: new course
Collaboration Diagram
•A collaboration diagram displays
object interactions organized
around objects and their links to
one another

58. Page 58Classification: Restricted
58

59. Page 59Classification: Restricted

60. Page 60Classification: Restricted
Sequence Diagram for Bank System

61. Page 61Classification: Restricted
Showing Components Working Together

62. Page 62Classification: Restricted
Focusing on the key
components and
interfaces in your
system
Focusing on component
dependencies and the
manifesting artifacts is useful
when you are trying control
the configuration or
deployment of your system

63. Page 63Classification: Restricted
Assembly connectors show components working together through
interfaces

64. Page 64Classification: Restricted
System Architecture

65. Page 65Classification: Restricted
Key Differences Between Structured and
Object-Oriented Analysis and Design
Structured Object-Oriented
MethodologySDLC Iterative/Incremental
Focus Processs Objects
Risk High Low
Reuse Low High
MaturityMature and widespreadEmerging
Suitable forWell-defined projects with
stable user requirements
Risky large projects
with changing user
requirements

66. Page 66Classification: Restricted
Software Engineering
The systems engineering process
Requirement
definitions
System design
Subsystem
development
System
integration
System
installation
System
evaluation
System
decomposition

67. Page 67Classification: Restricted
Thank You!