IA316 Mapping Data into Component Classes for Enterprise Application Server

1
IA316 Mapping Data into Component Classes for
Enterprise Application Server
Gerald Cadden E-Business Consultant Riverton
Corporation gcadden_at_riverton.com
2
Introduction

• Today the need for companies to do business and
  compete in the world of cyberspace is ever
  increasing.
• This increasing pressure to do business through
  an electronic medium such as Intranets,
  Extranets, and the Internet is causing companies
  to change their business models, goals and
  objectives, company structure, and of course the
  speed and way in which they write and maintain
  applications.

3
Introduction contd

• The focus of todays discussion will be
  concentrated at the level of
• 1. Turning business requirements into components
• 2. Writing and maintaining the components
• 3. Managing change in a dynamic business
  environment
• However some background on the driving forces
  that influence these areas might be useful.

4
Agenda

• To turn business requirements into components,
  develop and maintain them, some basic ingredients
  are required.
• Part 1 Development Approaches
• The changing face of development
• Development techniques Iterative vs Waterfall
• Part 2 The Basics of Iterative Development
• Some basic steps involved in iterative
  development
• What makes the iterative process happen
• The basic iterative process

5
(No Transcript)
6
Demo Synopsis Requirements for Ordering system

• Sales order system
• Needs to handle the creation of customer invoice
• Consists of the following
• Use Case view
• Manage Customer, Manage Orders, Manage Invoicing
• Use Cases
• Create Customer, Take Orders, Produce Invoice
• Workflow
• Use Case View Manage Invoicing
• Use Case Produce Invoice

7
Part 1 Development Approaches
8
The changing face of development

• Most significant influences driving change
• The internet, Wider use of Intranets, Extranets
• Business need to respond to changing market
  condition quickly, to stay competitive.
• If the market conditions that dictate the
  business logic of an application are very dynamic
  you should use a component approach

9
The changing face of development contd

• If you need to be able to change business logic
  to meet enhancements to ensure competitiveness,
  then using components will facilitate this

10
Development Techniques

• Traditional
• Waterfall Method
• New
• Iterative Analysis

11
Waterfall Method
12
Waterfall Method Drawbacks

• Waterfall isnt flexible
• Documents are the focus product
• There are few signs of progress until the end of
  the project
• Analysts dont have all the skills needed to
  judge requirements
• Design specifications written in isolation -
  often missing the business voice
• Test building is done in isolation

13
Iterative Method
Holistic Project View
Visioning
Deploy Version 1
Requirements Scoping Planning
Iteration 5
Iteration 4
Iteration 3
Internal Release 4
Iteration 2
Internal Release 3
Iteration 1
Internal Release 2
Internal Release 1
14
Iterative Method
Many Mini Waterfalls
Analysis
...
Design
Construct
Test
...
Iteration 1
Iteration n
Iteration 3
Iteration 2
15
Iterative Method Gains

• An iterative approach simplifies large system
  development
• Iterations are based upon use cases
• Use cases are prioritized based on complexity and
  risk levels
• Design and construction begins with the
  highest-priority Iteration
• Each iteration consists of additional use cases
  decided upon in advance
• Each iteration results in a running executable
  increment

16
Part 2 The Basics of Iterative Development
17
What Makes Iterative Process Happen

• The Right Tools
• You can use MS Word
• Or a specific tool designed for this type of work
• The Right Skills
• Employees need knowledge
• Services and Professional Knowledge
• You have to learn somewhere!!!!

18
The Basic Iterative Process

• Requirements Gathering
• Requirements Analysis
• Detailed Design
• Implementation

19
Requirements Gathering
20
Requirements gathering

• Requirements gathering - what is it?
• Breaks the business requirements into sets of
  defined system tasks that will implement the
  business requirements
• Users point of view, not the data!
• Requirements are modeled from users! point of
  view, not the developers, or the databases.
• Expressed in language the users are familiar with!

21
Requirements gathering contd

• Benefits
• More complete, common understanding, centralized
  information, user and business ownership
• Disadvantages
• Longer process, logistic issues, facilitation and
  mediation skills needed.

22
Requirements gathering methods

• Sources of information
• Joint Application Design (JAD) Sessions, Business
  documents and forms, Monitoring users, One on One
  user discussions
• Use Case Analysis and UML
• UML (Unified Modeling Language) specifies
  requirements gathering using Use Cases, Use Case
  Views
• Workflow to be added to UML

23
The Requirements Gathering Components

• Use Case
• Provide a convenient way of defining the steps
  taken to complete a single task in the system,
  e.g. Create Customer
• Use Case View
• Allows Use Cases to be grouped in some logical
  meaningful expression to the business, e.g.
  Manage Customers
• See samples

Use Case
Use Cases
24
The Requirements Gathering Components contd

• WorkFlow
• Provides sequencing of Use Cases and validation
  of steps within the Use Case

25
Requirements Gathering The Business Rules

• Discrete pieces of information that influence or
  constrain the business in some way.
• Found in the Use Cases, Business documents and
  from User experience, Existing system code
• See samples in handout

26
Requirements Analysis
27
Requirements Analysis

• Create common understanding of terms
• Turn business concepts into business objects
  (Abstraction)
• Model the relationships between business objects
• Transition from Object Model to Conceptual Entity
  Relationship Model

28
Common Understanding of Terms

• Many varying definitions of objects, classes, etc
• Lets Define each type, then clarify when they
  evolve from one to the other
• Object Is a concept that is known or familiar to
  the business, I.e. Customer (Name, Attributes,
  Behavior)

29
Common Understanding of Terms contd

• Entity Is essentially the same business concept
  but should be used only in the terms of a
  relational data model, e.g. Customer (Name,
  Attributes)

30
Common Understanding of Terms contd

• Class\ Component Is the implementation of our
  business concept in code, e.g. NVO_Customer
  (Name, Methods), attributes become access methods
• Instance Is the representation of our business
  concept within the system at any time

Object
Becomes a
Class or Component
31
Business Concepts become Objects
Entity
Design/ Implementation
Analysis
Object (customer)
Becomes
Becomes
Abstraction
Class (NVO_customer)
Goes into
Instantiation
Instance (Customer)
Gets data
Represents
Customer
32
Business Concepts become Business Objects contd

• What makes up an object
• The basics of a business object are Name,
  Attributes, and Behavior
• They are not Entities. Entities go into a
  database and only address name, and attributes.
  An object takes things to another level.
• You can usually model attributes a.k.a Data but
  behavior makes the difference

Object
Entity
33
Business Concepts become Business Objects contd

• Where are they found
• Found in the use cases as Nouns and Verb
  sentences
• Business object types
• Persistent These are objects that become
  Entities and Components that primarily hold
  persistent information about the business. They
  end up living in the database and transaction
  servers.
• Service These are objects that become components
  which primarily model the behavior of the
  business. They are implemented in code and live
  on server machines or in a transaction server.

34
Business Concepts become Business Objects contd
Becomes Entity
Becomes Class \ Component
35
Demo!
Find the objects
36
Detailed Design
37
Model Relationships Between Business Objects

• The use case indicates the relationships between
  objects
• These can be recorded as business rules and
  modeled as relationships between objects
• E.G. A Customer submits Sales Order. A Sales
  Order is submitted by a Customer

38
Demo!
Identify Attributes
Model the relationships
39
Transition your Object model to an ER Model

• Generate the object models into Entity
  Relationship models and then the Database

40
Demo!
Turn the Object Model into
An ER Model then a Database
41
Model behavior

• Extract the business behavior
• Managing Business Rule Creation
• Define object interactions
• Model complex methods

42
Extract the Business Behavior

• Business behavior is discrete functionality and
  processes that constrain and manipulate the
  business.
• Found in Use Cases, and external business
  documentation

43
Extract the Business Behavior contd

• Captured in Business Rules as different types
  Fact, Constraints, Derivations, Definitions, and
  Requirements
• 90 of business rules fall into the categories
  Constraint, Derivation, Definition, Fact, and are
  implemented. Requirements are not implemented.

44
Business Rules - Facts

• Fact
• Sentence connecting business terms in ways that
  make business sense e.g. Customer submits an
  order
• Recorded as a Business Rule
• These form relationships between objects.

45
Business Rules - Constraints

• Constraint
• A business rule that constrains the behavior of
  objects equates to constraints implemented in the
  application e.g. Order total cannot be greater
  that 50,000
• Typically implemented as methods on objects

46
Business Rules - Derivations

• Derivations
• Is something that is derived, can be logical e.g
  IF..THENELSE, Boolean e.g. TRUE or FLASE, Math
  e.g. Order total is the sum of amount of all
  order items.
• Typically implemented as a method on an object

47
Business Rules - Definition

• Definition
• Sentence intended to define a business term e.g.
  Customer is legal entity someone that orders a
  product
• Recorded as a Business Rule, which defines the
  object and attributes
• Typically become the definition for the object
  .e. g Customer

48
Business Rules - Requirements

• Requirements
• These are rules designed to capture information
  that is only informative to the business and
  usually not implemented in the application e.g.
  All the order forms received should be filed
  and stored (outside the system capabilities)
• Not usually implemented, i.e. Informational

49
Managing Business Rule Creation

• The process for identifying a business rule
• 1. Read use case and documentation for possible
  business rules
• 2. Write the business rule
• 3. Define its type (Fact, Constraints,
  Derivations, Definitions, and Requirements)
• 4. Review business rules with other team members
• 5. Consolidate duplicates
• 6. Decide on implementation method I.e. Method,
  Relationship
• 7. Decide on the object that implements the
  business.

50
Define Object interactions

• Modeling object interactions allows you to see
  how the objects will communicate and which
  methods will be involved
• Identifies any missing requirements i.e. business
  rules needed
• Identifies the appropriate place for a method
• Shows the calls, and expected returns
• Identify the need for Service objects
• Identifies communications between interface
  object and business objects

51
Define Object interactions contd
Persistent objects
Service object
Interface object
Object call
Return
Self Call
52
Model Complex Methods

• When methods are complex it can be helpful to
  model the method for clarity
• Activity diagrams provide structure chart like
  modeling
• Can be used as reference when writing or
  validating the code written to implement the
  method

53
Transition from model to code

• Object becomes a class \ component
• In analysis we work with objects, when these are
  generated they become classes \ components
• What language do I use?
• Things to consider skills of the team, Object
  Oriented, Rich functionality (remote calls,
  transaction server functions), Inheritance,
  Polymorphism, Platform independence, Viable
  future, Industry standards, Supporting frameworks

54
Transition from model to code

• Generation of code Vs writing from scratch
• Writing from scratch can mean long development
  cycles
• Having code generated reduces development cycles
  and allows developers to be free of menial code
  writing
• Code generated should meet industry standards
• Power of a framework
• Provide pre - built functionality, Resolve menial
  coding tasks (navigation),
• Handles mechanics of system and lets you
  concentrate on the business functionality

55
Implementation
56
Write the code

• IDE Selection
• Many good IDEs available some points for
  selection
• Ease of use
• Rich functionality
• Integration with other tools
• Comprehensive help
• Reputable company

57
IDE Selection contd

• Solid support
• Bug freehmmm
• Available skilled individuals
• Available training and literature
• Industry awards

58
Write the code contd

• Power of Java
• True OO
• Supports inheritance both dynamic and static
• Platform independent
• All the advantages of C with out the complexity
• Constrains the developer to good standards
• Well accepted in industry

59
Power of Java contd

• Supported by large companies (Sun, IBM,
  Microsoft), Industry standards
• Available frameworks
• Available training and literature
• Evolved to fully support enterprise applications
  (J2EE).

60
Demo!
Generate the object and
Elaborate the code
61
Deploy the code

• Available Architectures
• 2 - TIER
• Move on with the times
• Limited support for re - use
• 3 - TIER
• Supports re - use but lacks supporting features
  like connection pooling, component instance
  management, threads

62
Deploy the code
Any Client

• N - TIER \ Transaction Servers provide
• Full component re -use
• Component instance management
• Connection pooling
• Transactions
• Threads
• Security
• Load balancing

Application Servers
Page Engine
Component Transaction Engine
63
Demo!
Deploy the Components
64
Demo!
Run the Application