Presentation in JaMU Jogja (JUG Joglosemar) in Akakom, Yogyakarta.

1. JaMU April 2009
STMIK AKAKOM
Yogyakarta
Practical OOP in Java
A Case Study Approach
Thomas Wiradikusuma
wiradikusuma@gmail.com

2. Objective
To demonstrate practical Object
Oriented Programming in Java using
a case study.
Focus on OOP, Design
Pattern, the UML and Java
EE (Web).

3. Agenda
Quick tour on software engineering
Introduction to OOP
Introduction to Design Pattern
Introduction to the UML
Case study

4. A Journey to the Source
Everything begins from the source (code), based
on requirements. Source code gets compiled,
resulting in executable (actual deliverable).
Requirements getting more complex, at the same
time development must be faster, cheaper and
better.
Some order is required.

5. Hope for Silver Bullets
High-level language advancements
Object-oriented programming
Graphical programming (diagramming)
Incremental and iterative development
Rapid prototyping
Great designers
…

6. Object-oriented Programming
Essence: Abstraction
Principals:
Encapsulation
Inheritance
Polymorphism

7. Abstraction
Humans manage complexity
through abstraction.
For example, people do not
think a car as a set of tens
of thousands of individual
parts. They think of it as a
well-defined object with its
own unique behavior.
A powerful way to manage
abstraction is through the
use of hierarchical
classifications (layers).

8. Abstraction
Humans manage complexity
through abstraction.
For example, people do not
think a car as a set of tens
of thousands of individual
parts. They think of it as a
well-defined object with its
own unique behavior.
A powerful way to manage
abstraction is through the
use of hierarchical
classifications (layers).

9. Encapsulation
The mechanism that binds together
code and the data it manipulates.
Protective wrapper that prevents
the code and data from being
misused outside the wrapper.
Controlled through a well-defined
interface.
Allows migration of implementation
without breaking contract with
users of that class.
In Java, the basis of encapsulation
is the class.

10. Encapsulation
The mechanism that binds together
code and the data it manipulates.
Protective wrapper that prevents
the code and data from being
misused outside the wrapper.
Controlled through a well-defined
interface.
Allows migration of implementation
without breaking contract with
users of that class.
In Java, the basis of encapsulation
is the class.

11. Inheritance
The process by which one
object acquires the
properties of another object.
Supports the concept of
hierarchical classification.
Using inheritance, object
needs only define qualities
that make it unique. General
attributes are inherited from
its parent.
The concept of super class
and sub class.

12. Inheritance
The process by which one
object acquires the
properties of another object.
Supports the concept of
hierarchical classification.
Using inheritance, object
needs only define qualities
that make it unique. General
attributes are inherited from
its parent.
The concept of super class
and sub class.

13. Polymorphism
Feature that allows one
interface to be used for a
general class of actions.
The specific action is
determined by the exact
nature of the situation.
One interface, multiple
methods.
Allows creation of clean,
sensible, readable and
resilient code.

14. Polymorphism
Feature that allows one
interface to be used for a
general class of actions.
The specific action is
determined by the exact
nature of the situation.
One interface, multiple
methods.
Allows creation of clean,
sensible, readable and
resilient code.

15. Benefits of OO Approach
Objects are more “real-world”
Objects provide the flexibility and control
necessary to deal with evolving requirements
Object use facilitates collaboration
Objects help manage complexity
Reusability, maintainability and extensibility

16. Design Pattern
General repeatable solution to a commonly-
occurring problem in software design.
Old idea, made popular by Gamma et al (Design
Patterns -- Elements of Reusable Software,
1995).
Must be Useful, Useable, and Used.

17. Patterns vs Algorithms
Algorithms and data structures generally solve
more fine-grained computational problems like
sorting and searching.
Patterns are typically concerned with broader
architectural issues that have larger-scale
effects.

18. Patterns vs Frameworks
A software framework is a reusable mini-architecture
that provides the generic structure and behavior for
a family of software abstractions, along with a
context of memes/metaphors which specifies their
collaboration and use within a given domain.
A framework is usually not a complete application: it
often lacks the necessary application-specific
functionality.
Frameworks employ an inverted flow of control
between itself and its clients.

19. Patterns vs Frameworks, cont’d
Design patterns may be employed both in the design and the documentation of a
framework. A single framework typically encompasses several design patterns. A
framework can be viewed as the implementation of a system of design patterns.
Frameworks and design patterns are distinct: a framework is executable
software, design patterns represent knowledge and experience about software.
Frameworks are of a physical nature, patterns are of a logical nature:
frameworks are the physical realization of one or more software pattern
solutions; patterns are the instructions for how to implement those solutions.
Major differences:
Design patterns are more abstract than frameworks.
Design patterns are smaller architectural elements than frameworks.
Design patterns are less specialized than frameworks.

20. Classification
Creational patterns, object creation mechanisms, example:
Factory method
Prototype
Singleton
Structural patterns, identify a simple way to realize relationships between entities, example:
Adapter
Decorator
Proxy
Behavioral patterns, identify common communication patterns between objects, example:
Chain of responsibility
Observer
Strategy

21. Unified Modeling Language
Standardized general-purpose modeling language
in the field of software engineering.
Combines the best practice from data modeling
concepts such as entity relationship diagrams
(ERD), business modeling (work flow), object
modeling and component modeling.

22. Connecting People
Allows developers to
communicate clearly.
Natural language is
cumbersome for complex
concepts. Code is too
detailed.
Need to see from “high
above.”
UML is the lingua franca
of analysis and design.

23. Classification

24. Worth a thousand words, but...
The most important part is the executable
(source code).
Diagrams are for communication and
documentation.
Be flexible, use the simplest that works.
Don’t be trapped with 100% roundtrip
engineering.

25. Java
Three in one:
Programming language
Virtual Machine
Platform
A product of Sun Microsystems
Open sourced in November 2006 under the GNU General
Public License
Used in a wide variety of computing platforms

26. Java Programming Language
C-like dialect
! public class Hello {
! ! public static void main(String args[]) {
! ! ! System.out.println(“Hello!”);
! ! }
! }
Object oriented
Interpreted and compiled
Widely used to teach Programming 101 in many courses

27. Java Virtual Machine (JVM)
Makes Java application portable
Code compiled into bytecode
JIT (Just In Time) native compiler
Available in a wide range of computer
architecture

28. Java Platform
Java Card, applet embedded in smart card
Java ME (Micro Edition), for cellphone
Java SE (Standard Edition), desktop application and
everything else
Java EE (Enterprise Edition), Java SE with additional
enterprise packages
JavaFX, emerging rich client platform, Flash-like
Android, from Google, not the “standard” one

29. Java EE
Widely used platform for server programming in the
Java programming language.
Differs from Java SE in that it adds libraries which
provide functionality to deploy fault-tolerant,
distributed, multi-tier Java software, based largely on
modular components running on an application server.
There are “non standard” (alternative) tools/
frameworks to complement Java SE to be “enterprise-
ready” (e.g. Spring Framework, EhCache, Mule ESB,
etc).

30. Frameworks
A system has many aspects: DB access, interoperability, security,
logging, caching, validation, theme, testing, scalability, etc. Very
hard and time consuming to build everything from scratch.
Don’t reinvent the wheel (the NIH syndrome)
Framework vs home-grown, framework is:
Proven
Abundant resource
Community/commercial support
Focus on “business problem”

31. Case study: Dewantara
Open source student information system.
Aims to be flexible, allowing it to be used in
varying educational institutions.
Java Web application (JPA, Spring, JSF).
JUG CodeCamp 2008 project.
Familiar domain for most of us (you go to school,
don’t you?).

33. Lecturer Student

34. Lecturer Student
Subject

35. Lecturer Student
Room Subject

36. Lecturer Student
Session
Room Subject

37. Klass
Lecturer Student
Session
Room Subject

38. Klass
Lecturer Student Parent
Session
Room Subject

39. Klass
Staff
Lecturer Student Parent
Session
Room Subject

40. Stakeholder Klass
Staff
Lecturer Student Parent
Session
Room Subject

41. Institution
Stakeholder Klass
Staff
Lecturer Student Parent
Session
Room Subject

42. Institution
Stakeholder Klass
Staff
User Lecturer Student Parent
Session
Room Subject

43. Institution
Stakeholder Klass
Staff
User Lecturer Student Parent
Role Session
Room Subject

44. Questions?
JUG Joglosemar jug-joglosemar.org
JUG Indonesia jug.or.id
Thomas Wiradikusuma
Blog jroller.com/wiradikusuma
Twitter twitter.com/wiradikusuma