Business Applications with Object-Oriented Paradigm (Modeling Concepts)

1
Business Applications with Object-Oriented
Paradigm (Modeling Concepts)

• Jason C.H. Chen, Ph.D.
• Professor of MIS
• School of Business
• Gonzaga University
• Spokane, WA 99258

2
What is Business Model?

• A business model is a set of planned activities
  (sometimes referred to as business processes)
  designed to result in a profit in a marketplace.
• The business model is at the center of the
  business plan.
• An e-commerce business model aims to use and
  leverage the unique qualities of the Internet and
  the www.

Source E-Commerce business, technology,
society, Laudon and Traver, A/W
N
3
Why New Models?

• We need some new models
• for how we go about exploring IT for competitive
  advantage,
• for IT infrastructure how we create it and manage
  it
• for how we acquire, manage and deploy the skills
  that are needed to run that infrastructure

4
Essentials for a Successful Enterprise
Value propositions
1. Business model
2. Core competencies
Strategic intent
Strategy
Positioning
3. Execution
IT Role?
N
5
Four Important Entities for a Successful
Enterprise

6
PARADIGMS(Definition)

• A paradigm is a way of viewing things and
  thinking about things.

7
Paradigm Shift

• Traditional vs. New Approach

• Functional vs. Object-Oriented

8
PARADIGMS SHIFT

• In the last two decades (mid 1970s to the
  present) popular paradigms have been used

Process Modeling
Data Modeling
O-O Modeling
DFD
UML, OMT
ER, E-ER
9
PARADIGMS SHIFT

• In the last two decades (mid 1970s to the
  present) popular paradigms have been used

Process Modeling
Data Modeling
O-O Modeling
DFD
UML, OMT
ER, E-ER
10
OBJECT-ORIENTED METHODOLOGY

• The technique of object-oriented (OO) methodology
  really has emerged only in the last seven to
  eight years (early 1990s).
• The O-O methods organize both information and the
  processing that manipulates the information,
  according to the real-world objects that the
  information describes.

11
I. OBJECT-ORIENTED CONCEPTS
12
What is an OBJECT ?
13

14
An OBJECT is ...

• Object Data structure Behavior
• (attributes) (operations)
• where Behavior is in a single entity.

15
An OBJECT is ...

• Object Data structure Behavior
• (attributes) (operations)
• where Behavior is in a single entity.

16
(No Transcript)
17
(No Transcript)
18
Why O-O? (Advantages / Objectives)

• Understanding problems
• Communicating with application experts
• Modeling enterprises
• Preparing documentation
• Designing programs and databases

19
Definition of O-O vs. Conventional Programming

• O-O organizing software as a collection of
  discrete objects that incorporate both data
  structure and behavior.
• Conventional programming data structure and
  behavior are only loosely connected.

20
II. What is OBJECT-ORIENTED Programming
Language (OOP)?

• OOP Objects Inheritance Polymorphism

21
II. What is OBJECT-ORIENTED Programming
Language (OOP)?

• OOP Objects Inheritance Polymorphism

22
Object-Based vs. Object-Oriented Languages

• An object-based language is one in which data and
  operations can be incorporated (encapsulated) in
  such a way that data values can be isolated and
  accessed through the specified class functions.
• An object-oriented language provides inheritance
  and polymorphism in addition to the features in
  an object-based language.

23
PROGRAMMING IN THE LARGE

• In order to deal with large-scale programming, we
  must have some way of attacking a problem in a
  systematic way and managing its complexity ...

24
Systems/Software (Development) Life Cycle
(SLC/SDLC)

• A method that provides information systems
  professionals with step-by-step procedures to
  develop their projects/systems.
• SOFTWARE ENGINEERING ...

25
Phases of Systems/Software (Development) Life
Cycle (SLC/SDLC)

• Conceptualization
• (Requirements) Analysis
• Design
• Implementation
• Testing and Verification
• Operation, Follow-up, and Maintenance

26
1. Conceptualization

• Prepare a complete and unambiguous problem
  statement.
• Users and analysts sign the requirements document.

27
2. (Requirements) Analysis

• Understand the problem develop a system behavior
  model and determine problem input, output, and
  other relevant data elements.
• Name each identified data element and develop a
  model of the essential characteristics
  (attributes and operations) for each element.

28
3. Design

• Using the system and data models developed during
  requirements analysis, perform a top-down design
  of the system.
• For each system component, identify key data
  elements and subordinate functions using
  structure charts.

29
4. Implementation

• Write algorithms and pseudocode descriptions of
  individual functions.
• Code the solution.
• Debug the code.

30
5. Testing and Verification

• Test the code, verifying that it is correct. Each
  data modeling component should be tested
  separately, before all components are tested as
  an integrated whole.
• Involve users and special testing teams in all
  system tests.

31
6. Operation, Follow-up, and Maintenance

• Run the completed system.
• Evaluate its performance.
• Remove new bugs as they are detected.
• Make required changes to keep the system up to
  date.
• Verify that changes are correct and that they do
  not adversely affect the systems operation.

32
Software Engineering Goals That Drive Object Use

• Why should we base our programming around
  objects?
• Advantages follow ...

33
1. Ease of Design and Code Reuse

• Once the code works properly, the use of objects
  increases your ability to reuse a design or code
  you created for one application within a second
  application.
• ...
• REUSABILITY

34
2. Increased Reliability

• Once proper testing has been previously performed
  on object libraries, the use of existing
  (working) code will improve your programs
  reliability.

35
3. Ease of Understanding

• By allowing designers and programmers to focus on
  smaller pieces of a system and providing a
  framework within which designers can identify
  objects, the operations performed on the objects,
  and the information objects must store, object
  use helps programmers focus on and understand key
  system components.

36
4. Increased Abstraction

• Abstraction lets designers and programmers look
  at the big picture--- temporarily ignore
  underlying details so they can work with system
  elements that are more easily understood. For
  example, by focusing only on the word processor
  objects earlier in this chapter, the
  implementation of a word processor became much
  less intimidating.

37
5. Increased Encapsulation

• Encapsulation groups all of the pieces of an
  object into one neat package. For example, the
  file class previously defined in this chapter
  combines the functions and data fields a program
  needs to work with a file.

38
5. Increased Encapsulation (Conti.)

• The programmer who is working with the file class
  does not need to know each piece of the class,
  only that they need to use the class within their
  program. The class, in turn, will bring with it
  all the necessary pieces.

39
6. Increased Information Hiding

• Information hiding is the ability for your
  program to treat a function, procedure, or even
  an object, as a black box, using the item to
  perform a specific operation without having to
  know what goes on inside. In Chapter 1, for
  example, your programs used I/O stream objects
  for input and output without having to understand
  how the streams work.

40
III. More on Objects Characteristics of Objects

• Identity
• Classification (Abstraction)
• Polymorphism
• Inheritance

41
III. More on Objects Characteristics of Objects

• Identity
• Classification (Abstraction)
• Polymorphism
• Inheritance

42
Characteristics of Objects

• Identity
• This means that data is quantified into discrete,
  distinguished entities called objects
• Can be either concrete or conceptual
• Classification (abstraction)
• Means that objects with the same data structure
  (attributes) and behavior (operations) are
  grouped into a class

43
Characteristics of Objects (Conti.)

• Polymorphism
• Means that the same operation (e.g., dial) may
  behave differently on different classes
• A specific implementation of an operation by a
  certain class is called a method
• Because an O-O operation is polymorphic, it may
  have more than one method implementing it

44
Characteristics of Objects (Conti.)

• Inheritance
• Is the sharing of attributes and operations among
  classes based on a hierarchical relationship
• A class can be defined broadly and then refined
  into successively finer subclasses. Each
  subclass incorporates, or inherits all of the
  properties of its superclass and adds its own
  unique properties

45
Objects vs. Classes

• Objects
• Definition An object is a concept, abstraction,
  or thing with crisp boundaries and meaning for
  the problem at hand.

46
Objects vs. Classes (Conti.)

• Purpose Objects promote understanding of the
  real world and provide a practical basis for
  computer implementation.
• All objects have identity and are
  distinguishable, and therefore, decomposition of
  a problem into objects depends on judgment and
  the nature of the problem.

47
Objects vs. Classes (Conti.)

• Classes
• Definition An object class describes a group of
  objects with similar properties (attributes),
  common behavior (operations), common
  relationships to other objects, and common
  semantics.

48

• The abbreviation class is often used instead of
  object class. The objects in a class share a
  common semantic purpose, above and beyond the
  requirement of common attributes and behavior.
• Objects -----------------------------gt Classes
• Abstract to
• (Specific)
  (General)
• Instances
  attributes
• 
  operations

49

• The abbreviation class is often used instead of
  object class. The objects in a class share a
  common semantic purpose, above and beyond the
  requirement of common attributes and behavior.
• Abstract
• (John,Mary ...) to
  (Person)
• Objects -----------------------------gt Classes
• (Specific)
  (General)
• Instances
  attributes
• 
  operations

50
WHAT IS O-O DEVELOPMENT?

• Systems Development Life Cycle (SDLC) include
  the phases of analysis, design, implementation,
  and maintenance.
• O-O Development Life Cycle focuses on
  identifying and organizing application-domain
  concepts, rather than their final representation
  in a programming language.

51
Modeling concepts not implementation.

• Definition
• A model is an abstraction of a reality.
• Abstraction is the process of temporarily
  ignoring underlying details so we can focus on
  the most important features (or big picture) of
  the large problem at hand.

52

• The real payoff comes from addressing front-end
  conceptual issues, rather than back-end
  implementation issues.
• An O-O development approach encourages software
  developers to use and think in terms of the
  application domain through most of the software
  engineering life cycles. It is only when the
  inherent concepts of the applications are
  identified, organized, and understood that the
  details of data structures and functions can be
  addressed effectively.

53
(No Transcript)
54
What is the Methodology?

• Methodology is a series of concepts with
  techniques and notations associated with each
  step.

• Concepts
• Techniques
• Notations
• Steps

55
Differences from Functional Methodology

• O-O Methodology vs. Conventional (Functional)
  Methodology

56
1. Conventional Methodology

• primary emphasis is placed on specifying and
  decomposing system functionality

57
Pros and cons (Conventional)

• PROS it seems the most direct way of
  implementing a desired goal.
• CONS the resulting system can be fragile
  because if the requirements change, a system
  based on decomposing functionality may require
  massive restructuring.

58
2. O-O Methodology

• Focuses first on identifying objects from the
  application domain, then fitting procedures
  around them.

59
Pros and Cons (OO)

• PROS O-O software holds up better as
  requirements evolve, because it is based on the
  underlying framework of the application domain
  itself, rather than the ad-hoc functional
  requirements of a single problem.
• CONS it is a rather indirect way to describe
  the problem for those user have used conventional
  techniques.

60
OBJECT-ORIENTED THEMES

• Abstraction.
• Encapsulation (Information Hiding)
• Combining Data and Behavior
• Sharing / Inheritance
• Emphasis on Object Structure, Not Procedure
• Polymorphism

61
OBJECT-ORIENTED THEMES

• Abstraction.
• Encapsulation (Information Hiding)
• Combining Data and Behavior
• Sharing / Inheritance
• Emphasis on Object Structure, Not Procedure
• Polymorphism

62
1. Abstraction

• Concealing irrelevant details from the user.
• Abstraction is the process of temporarily
  ignoring underlying details so we can focus on
  the big picture of the large problem at hand

63

• Focusing on the essential, inherent aspects of
  an entity and ignoring its accidental properties
  -- in systems development, this means focusing on
  what an object is and does, before deciding how
  it should be implemented.
• Advantage preserving the freedom to make
  decisions as long as possible by avoiding
  premature commitments to details.

64
2. Encapsulation

• Information hiding the process of designing
  functions, procedures, or classes as black
  boxes. Therefore, to use a function, procedure,
  or class, a designer does not need to know the
  boxs inner workings

65

• Preventing a program from becoming so
  interdependent that a small change has massive
  ripple effects. The Implementation of an object
  can be changed without affecting the applications
  that use it - reusable code.
• Encapsulation is not unique to O-O languages but
  the ability to combine data structure and
  behavior in a single entity makes encapsulation
  cleaner and more powerful than is conventional
  languages that separate data structure and
  behavior.

66
3. Combining Data and Behavior

• Conventional procedural O-O Approach
• approach
• data structure hierarchy class hierarchy
• procedure hierarchy
• 
  Polymorphism

67
3. Combining Data and Behavior

• Conventional procedural O-O Approach
• approach
• data structure hierarchy class hierarchy
• procedure hierarchy
• 
  Polymorphism

68
4. Inheritance/ Sharing

• O-O techniques promote sharing at several
  different levels.
• Inheritance of both data structure and behavior
  allows common structures to be shared among
  several similar subclasses without redundancy.

69

• PROS
• The sharing code using inheritance is one of the
  main advantages of O-O language.
• More important than savings in code is the
  conceptual clarity from recognizing that
  different operations are all really the same
  thing -- this reduces the number of distinct
  cases that must be understood and analyzed.
• O-O development not only allows information to be
  shared within an application, but also offers the
  prospect of reusing design and code on future
  projects.

70
5. Emphasis on Object Structure, Not Procedure
Structure

• Object-oriented technology stresses specifying
  what an object is, rather than how it is used.

71
6. Polymorphism

• Poly - many Morphic - forms
• Many forms
• An object (e.g., telephone) that is capable of
  having two or more forms (during the run time)
  with the same name (e.g., dial).

72
E-R Model vs. O-O Model
A collection of entities that share common
properties or characteristics
Class
Attributes operations
A single occurrence of an entity type/class
73
Conclusion -- Synergy
74
(No Transcript)
75
OBJECT ORIENTATIONS CONTRIBUTIONS . . .
76
OBJECT ORIENTATIONS CONTRIBUTIONS
77
WHATS NEXT?

• Unified Modeling Language(UML)

78
(No Transcript)
79
Ready for the Next Run?