Contemporary Software Engineering Practices Together With Enterprise

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


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


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



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


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


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


The Single Responsibility Principle There should never be more than one

reason for a class to change Responsibility reason to change


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


Layered Architectures Enterprise Java Beans Remote Method Invocations Distributed Transactions Big monolitic application servers


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?


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!


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


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


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


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)


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


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]

Date post:	27-Jun-2015
Category:	Technology
Upload:	kenan-sevindik
View:	1,439 times
Download:	0 times