Contemporary Software Engineering Practices Together
with Enterprise Java Technologies
Kenan Sevindik
İnnova Bilişim A.Ş.
Software Engineering Problems
Why so much spaghetti code is written?
“If we had chance to rewrite this project, several things would be much different!”
PrototypingPlan to Throw One Away (You Will Anyway) -- Brooks
Software Engineering Problems
Broken Window Theory Consider a building with a
few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.
Refactoring
Technique for restructuring an existing body of code
Altering its internal structure without changing its external behavior
A series of small behavior preserving transformations
Each transformation does little, but a sequence of transformations can produce a significant restructuring
Software Engineering Problems
Piecemeal Growth
Russian Mir Space Station designed for Reconfiguration Modular growth
Core module launched in 1986
Until 1996 several modules were added and system was rearranged as it has grown
Mir reenters the atmosphere over Fiji on 22 March, 2001
Why Master Plans Fail?
They are often rigid, misguided, and out of date Users need change with time You can't simply plan, you have to plan to be
able to adapt
Piecemeal Growth vs Large Lump Development Large-lump development is based on the
idea of replacement Piecemeal Growth is based on the idea of
repair Large-lump development is based on the
fallacy that it is possible to build perfect buildings
Piecemeal Growth vs Large Lump Development Piecemeal growth is based on the
healthier and more realistic view that mistakes are inevitable
Piecemeal growth is based on the assumption that adaptation between buildings and their users is necessarily a slow and continuous business
This adaptation cannot, under any circumstances, be achieved in a single leap
Agile Manifesto
Highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software
Welcome changing requirements, even late in development
Deliver working software frequently Business people and developers must work
together daily
Agile Manifesto
Build projects around motivated individuals The most efficient and effective method of
conveying information is face-to-face communication
Working software is the primary measure of progress
Agile processes promote sustainable development
Agile Manifesto
Continuous attention to technical excellence and good design enhances agility
Simplicity--the art of maximizing the amount of work not done--is essential
The best architectures, requirements, and designs emerge from self-organizing teams
At regular intervals, the team reflects on how to become more effective
Patterns in Architecture
“A Pattern Language: Towns, Buildings, Construction
Writtern by Christopher Alexander in 1977 Why many medieval cities are attractive and
harmonious? They were built to local regulations that required
specific features, but freed the architect to adapt them to particular situations
Patterns in Architecture
Patterns in Architecture
Provides rules and pictures, and leaves decisions to be taken from the precise environment of the project
Describes exact methods for constructing practical, safe and attractive designs at every scale from entire regions, through cities, neighborhoods, gardens, buildings,
rooms, built-in furniture
Patterns in Architecture
Design Patterns: Elements of Reusable Object-Oriented Software Influenced by “A Pattern
Language: Towns, Buildings, Construction
Written in 1994 A catalog of 23 software
design patterns A design pattern systematically
names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems.
Question
What is called for authors of this famous Design Patterns book?
Gang of Four
Design Patterns: Elements of Reusable Object-Oriented Software It describes
the problem, the solution, when to apply the solution, and its consequences.
It also gives implementation hints and examples.
The solution is a general arrangement of objects and classes that solve the problem.
The solution is customized and implemented to solve the problem in a particular context
Question
Where decorator pattern is used in JDK mostly?
java.io package
An Example: Decorator Pattern in Java IO Package Add new behaviours during runtime,
without subclassingjava.lang.
Object
java.io.Reader
java.io.InputStreamReader
java.io.BufferedReader
java.io.FileReader
java.io.LineNumberReader
An Example: Decorator Pattern in Java IO Package
ClientLineNumber
ReaderFileReader
read()
read()
maintainLineNumber()
An Example: Decorator Pattern in Java IO Package
Refactoring To Patterns
Patterns are where you want to be; refactorings are ways to get there from somewhere else
Refactoring to, towards, and away from patterns,
Main reason programmers over-engineer is that they don't want to get stuck with a bad design
But over time, the power of patterns may lead to lose sight of simpler ways to write code
Recommended Book
Refactoring To Patterns
By Joshua Kerievsky
Test Driven Development
Not a new idea at all Since the dawn of computing, programmers
specify input & output before writing functionality Consists of short iterations
First write a test code which checks for new functionality or desired improvement
Then implement production code to make test code pass Finally refactor software to accomodate changes for this
new functionality or improvement
Test Driven Development
JUnit Testing Tool & Framework
Developed by Kent Beck and Erich Gamma
Test infected!
“No Time For Testing” Death Spiral
Stress
Write and Run Tests
Recommended Book
Test Driven Development By Example
By Kent Beck
Test Driven Development and Continuous Refactoring Efficient evolution of working code by turning
programming into a dialogue: Ask: You ask a question of a system by writing a test Respond: You respond to the question by writing code
to pass the test Refine: You refine your response by consolidating ideas,
weeding out inessentials, and clarifying ambiguities Repeat: You keep the dialogue going by asking the next
question
Signs of Bad Design
Rigidity It is hard to change a part in the systemEvery change affects too many other parts
in the system Fragility
When you make a change, unexpected parts of the system break
Signs of Bad Design
Immobility It is hard to reuse parts in another application It cannot be disentangled from the current application
Viscosity When faced with a change, engineers usually find more
than one way to make the change Some of the ways preserve the design, others do not (they
are hacks!) When the design preserving methods are harder to
employ than the hacks, then the viscosity of the design is high
It is easy to do the wrong thing, but hard to do the right thing
Object Oriented Principles
Classes, methods , modules Abstraction, Encapsulation, Inheritance,
Polymorphism Are they really enough to develop quality
OO software? They are atomic units, we need much
coarse-grained elements
Why Object Term Is Selected? Ben Kristen Nygaard'un önce ögrencisi sayilirim. Simdi
"Simula" müzesine kaldirilan bir kara (aslinda yesil) tahtamiz vardi, onun önünde böyle seyleri günlerce tartisirdik.
Nesne object gibi ama "material" olma özelligini ima ediyor. Object kelimesinin arkasinda yatan orijinal fikir "individual" ve "identifiable" olmasi idi, ama terimin bilincli bir sekilde "ting" olarak secilmemesinin ana nedeni kavramlari kapsamamasi idi. Bir de object'in "process" (sürec, sadece aktivite tanimi) kavramina kontrast olarak secildigini de hatirlamak gerekir.
Kristen Nygaard'un Ole Johan Dahl (yani Simula ve OO kavramlarinin "formalisti") ile tartismalarindan su cümleyi cok iyi hatirliyorum: Bu "sey" hem fiziki hem kavramsal seyleri temsil edebilmeli. Kendisi sürec'e alternatif olmali ama bir süreci de temsil edebilmeli. Ingilizcedeki tanimimiz "a structural and behavioral representation of a conceptual or physical entity, identifiable as a separate individual entity".
Hatta "object" kelimesinin (ki Norveccesi de ayni, Objekt) seciminde bir bireye "odaklanma" (focus) yan anlami da önemli:
Programlama (ki o zaman Simula ve OO sadece simulasyon programlamak icin düsünülüyordu) cevreyi kavramsallastirmak, modellemek ile baslar, ve bu modelde nelere odaklanacak, neler model disi birakilacak bu da cok önemli (denirdi). Dolayisiyla objekt'ler model üniteleri olarak da "object of attention", yani secilip üzerine odaklanan objectler olarak da düsünülürdü. Ayrica "object"in "subject"ten faki, yani kavramsal da olsa "dissal" bir seyin temsili oldugu da kelimenin seciminde rol oynadi. Tabii daha benim bildigim ve bilmedigim 1000 cesit tartisma oldu bu konuda, ama sanirim tartismalarin tarzinda modelleme ünitesinin özellikleri yatiyordu hep.
Bunlar felsefi (ve tarihi) tartismalar belki ama tartismalarin altinda dilin ne derece düsünmeye yardimci olabilecegi veya engelleyebilecegi hipotezi yatiyor (Sapir-Whorf thesis).
Nesne bu kavramlari temsil ediyormu (kognitif olarak, yani otomatik bunu mu algiliyor insanlar "nesne" kelimesini duyduklarinda)? Degilse, bu kavramlari toplayan ve "icgüdüsel" temsil eden Türkce kelime nedir? Object'in Türkce cevirisindeki tartismalara aranizda sahit olan varmi? Bilmek isterdim.
Naci Akkök 29.08.2003
Object Oriented Principles
Open-Closed Principle Probably the most important OO principle Software entities should be open for
extension but closed for modification When requirements change, you extend
available behaviour, not change old code that already works
Object Oriented Principles
The Single Responsibility Principle There should never be more than one
reason for a class to change Responsibility reason to change
Object Oriented Principles
The Dependency Inversion Principle Abstractions should not depend upon
details Details should depend upon abstractions Layering and abstract layers Concrete classes should depend upon
those abstract layers
Aspect Oriented Programming
Is object oriented programming sufficient to develop modular, well-encapsulated software systems?
OOP supports encapsulation of concerns (interests of focus) to some degree
Some concerns simply cannot exist in one seperate module
Aspect Oriented Programming
They are scattered around whole system Cross cutting concerns they "cut"
across multiple modules in a program AOP provides some way to encapsulate
cross-cutting concerns in one place
Question
What is the name of first and most popular AOP language for Java?
AspectJ
Recommended Book
AspectJ in Action By Ramnivas Laddad
Evolution of Enterprise Java
J2SE, J2ME, J2EE J2EE targets server side enterprise
software development First J2EE version dates back to 1998
Question
When was Java first appeared? In 1994
Question
What was Java’s previous name? Oak
Evolution of Enterprise Java
Layered Architectures Enterprise Java Beans Remote Method Invocations Distributed Transactions Big monolitic application servers
Evolution of Enterprise Java
Trap of One Size Fits All Problem! How many projects do require distributed
transactions? Why so much complexity with EJBs?, we only
need to insert, delete, and update records in our database.
Can’t we run our application outside any application server?
Evolution of Enterprise Java
J2EE is driven by specifications committee It has its success, but drawbacks as well Enterprise Java community learned much
from their failures Return back to POJO driven development Apply techniques which have been proven in
the battlefield!
Evolution of Enterprise Java
Appearence of lightweight containers Containers should be non-invasive Applications can be run anywhere You don’t have to use EJBs to develop
enterprise Java applications There appeared successful open source
technologies alternative to J2EE standards
Evolution of Enterprise Java
They applied best practices learned over time
POJOs are in front Testability is favored Dependency Inversion Principle is
rediscovered
Recommended Book
Patterns of Enterprise Application Architecture
By Martin Fowler et al
Spring Application Framework
J2EE should be easier to use Promote program to interfaces remember
dependency inversion principle Use of ordinary Java objects fostered
whenever possible POJO driven development
OO design is more important than any implementation technology, such as J2EE
Spring Application Framework
JavaBeans offer great way of configuring applications
Testability is essential, any framework should help make your code easier to test
Don’t compete with existing good solutions, but foster integration with them
Spring Application Framework
A layered Java/J2EE Application framework Contains a lightweight container
POJOs are configured and managed within this environment
Promotes development of loosely-coupled components
Components can be developed and tested in isolation, and then can be deployed in any environment (Java/JEE)
Spring Application Framework
Provides AOP funcionality and close integration with AspectJ You can AOP enable any object managed by Spring Even you can apply your aspects to non Spring
managed code! Provides a common abstraction layer for
transaction management You can have declerative TX management without
EJBs You don’t need J2EE servers to have transaction
support
Spring Application Framework
Provides integration with several ORM tools, and JDBC mapping toolsToplink, Hibernate, iBatis SQL Maps
It has is own web MVC framework, provides integration with other popular web frameworks, like Struts, JSF etc
Support for Security, Remoting, Web Services...
Recommended Book
Expert One-On-One J2EE Development Without EJB
By Rod Johnson and Juergen Hoeller
Hibernate OR Mapping Framework
Persisting data usually means storing data in relational database using SQL
In an OO application, persistence allows an object to outlive the process that created it
State of the object can be stored to disk, and an object with the same state can be re-created at some point in the future
Hibernate OR Mapping Framework
Relational databases provide a tabular representation of persistent data
An application with a domain model doesn’t work directly with the tabular representation of the business entities
Object-relational paradigm mismatch
Object-Relational Paradigm Mismatch Different levels of granularity
User-Address-zipcode in domain model User table and address_zipcode column in relational
model
Problem of subtypes Inheritance in Java is type inheritance Tables in relational model doesn’t represent types Support for polymorphic associations and queries
Object-Relational Paradigm Mismatch
User
Address-street-no-zipcode
BillingDetails-accountNumber
CreditCard BankAccount
1..*
1
create table USERS (USERNAME varchar(15) not null primary key,NAME varchar(50) not null,ADDRESS varchar(100))create table BILLING_DETAILS (ACCOUNT_NUMBER varchar(10) not null primary key,ACCOUNT_NAME varchar(50) not null,ACCOUNT_TYPE varchar(2) not null,USERNAME varchar(15) foreign key references user)
Object-Relational Paradigm Mismatch Identity problem
How to check whether two objects are identical?
Java has two ways for this Object identity a==b Equals() check equality by value
Primary keys are used in database table
Object-Relational Paradigm Mismatch Association related problems
Associations between objects are directionalObject referencesForeign keys are used in databases, not
directionalThere are many-to-many associations in object
modelsOnly one-to-many and one-to-one associations
exist in relational model
Object-Relational Paradigm Mismatch
public class User {private Set billingDetails;...}
public class BillingDetails {private User user;...}
USER_ID bigint foreign key references USERS
USER_ID bigint unique foreign key references USERS
BILLING_DETAILS_ID bigint primary key foreign key references USERS
Object-Relational Paradigm Mismatch The problem of data navigation
Navigate from one object to other using object references
You need to determine navigation path before walking on it in relational model
Joins In object model you access deeper level objects only
when you need them Select N+1 problem in relational model Or bring too much data into memory
Recommended Book
Java Persistence with Hibernate
By Christian Bauer and Gaving King
Java Server Faces
It is a web presentation framework Based on MVC pattern Consists of
User interface component modelWell defined request processing life-cycle
Suitable for web sites where a lot of user interaction occurs
Java Server Faces
Event driven model in contrast to action based model in StrutsAction eventsValue changed eventsSelection events
Possible to develop reusable UI components
JSF MVC Model
Model
RendererUI
ComponentListener
Model
View Controller
Conclusion
Technology alone is not enough to develop quality software systems
Software engineering concepts, methods and practices need concrete application area to evolve
Tend in Enterprise Java world is towards much agile and adaptable systems
Contact Info
Kenan Sevindik Work :İnnova Bilişim A.Ş. Blog :http://ksevindik.blogspot.com E-Mail :[email protected]