Sunday, 18 August 2013

JPA Joined Strategy

In the joined strategy, each entity in the hierarchy is mapped to its own table. The root entity maps to a table that defines the primary key to be used by all tables in the hierarchy, as well as the discriminator column. Each subclass is represented by a separate table that contains its own attributes (not inherited from the root class) and a primary key that refers to the root table’s primary key. The non-root tables do not hold a discriminator column.

In the joined table inheritance, each class shares data from the root table. In addition, each subclass defines its own table that adds its extended state. The following example shows two child tables, EXTERNAT_VET and IN_HOUSE_VET, as well as parent table VET:


Table Creation:


VET table
CREATE TABLE VET 
(
VET_ID NUMBER NOT NULL
, NAME VARCHAR2(45 BYTE)
, QUALIFICATION VARCHAR2(45 BYTE)
, VET_TYPE VARCHAR2(10 BYTE)
, CONSTRAINT VET_PK PRIMARY KEY
(
VET_ID
)
ENABLE
);

EXTERNAT_VET  table
CREATE TABLE EXTERNAT_VET 
(
VET_ID NUMBER NOT NULL
, COUNTRY VARCHAR2(45 BYTE)
, VISITING_FEES NUMBER
, CONSTRAINT EXTERNAT_VET_PK PRIMARY KEY
(
VET_ID
)
ENABLE
);

IN_HOUSE_VET table
CREATE TABLE IN_HOUSE_VET 
(
VET_ID NUMBER NOT NULL
, SALARY NUMBER
, CONSTRAINT IN_HOUSE_VET_PK PRIMARY KEY
(
VET_ID
)
ENABLE
);

Sequences and Triggers Creation:

CREATE SEQUENCE VET_SEQ NOCACHE;

create or replace TRIGGER VET_TRG
BEFORE INSERT ON VET
FOR EACH ROW
BEGIN
IF :NEW.VET_ID IS NULL THEN
SELECT VET_SEQ.NEXTVAL INTO :NEW.VET_ID FROM DUAL;
END IF;
END;
/

Insert Test Data:

VET table
REM INSERTING into VET
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (1,'Ashitraj more','mvsc','IN_VET');
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (2,'Raj','bvsc','IN_VET');
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (3,'Steven','mvsc','EXT_VET');
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (4,'Rakesh','mvsc','IN_VET');
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (5,'John','mvsc','EXT_VET');
Insert into VET (VET_ID,NAME,QUALIFICATION,VET_TYPE) values (6,'vet','vet qualification','VET');

EXTERNAT_VET  table
REM INSERTING into EXTERNAT_VET
Insert into EXTERNAT_VET (VET_ID,COUNTRY,VISITING_FEES) values (3,'UK',500);
Insert into EXTERNAT_VET (VET_ID,COUNTRY,VISITING_FEES) values (5,'US',450);

IN_HOUSE_VET table
REM INSERTING into IN_HOUSE_VET
Insert into IN_HOUSE_VET (VET_ID,SALARY) values (1,35000);
Insert into IN_HOUSE_VET (VET_ID,SALARY) values (2,30000);
Insert into IN_HOUSE_VET (VET_ID,SALARY) values (3,29000);

Class Creation:


VET Class
@Entity
@Table(name = "VET")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "VET_TYPE")
@DiscriminatorValue("VET")
public class Vet implements Serializable {
private static final long serialVersionUID = 1L;

@Id
@Basic(optional = false)
@Column(name = "VET_ID")
private Integer vetId;
@Column(name = "NAME")
private String name;
@Column(name = "QUALIFICATION")
private String qualification;
//generate getters, setters, toString(), hashCode(),equals()
}

EXTERNAT_VET Class
@Entity
@Table(name = "EXTERNAT_VET")
@DiscriminatorValue("EXT_VIT")
public class ExternatVet extends Vet{

@Column(name = "COUNTRY")
private String country;
@Column(name = "VISITING_FEES")
private Integer visitingFees;
//generate getters, setters, toString(), hashCode(),equals()
}

IN_HOUSE_VET Class
@Entity
@Table(name = "IN_HOUSE_VET")
@DiscriminatorValue("IN_VET")
public class InHouseVet extends Vet{

@Column(name = "SALARY")
private Integer salary;
//generate getters, setters, toString(), hashCode(),equals()
}

JUnit Test Case:

public class InheritanceJUnit {

static EntityManagerFactory emf;
static EntityManager em;
static EntityTransaction trx;

@BeforeClass
public static void initEntityManager() throws Exception {
emf = Persistence.createEntityManagerFactory("JavaApplicationJPAPU");
em = emf.createEntityManager();
trx = em.getTransaction();
}

@AfterClass
public static void closeEntityManager() throws Exception {
em.close();
emf.close();
}

@Before
public void initTransaction() throws Exception {
trx.begin();
}

@After
public void endTransaction() throws Exception {
if (!trx.getRollbackOnly()) {
trx.commit();
}
}

@Test
@Ignore
public void testJoinedStrategyInsert() {

InHouseVet inVet = new InHouseVet();
inVet.setName("Invet name 10");
inVet.setQualification("invet Qualification 10");
inVet.setSalary(1010);
inVet.setVetId(10);
em.persist(inVet);
System.out.println("InHouseVet inserted");

ExternatVet extVet = new ExternatVet();
extVet.setName("extVet name 11");
extVet.setQualification("extVet Qualification 11");
extVet.setCountry("xy");
extVet.setVisitingFees(1111);
extVet.setVetId(11);
em.persist(extVet);
System.out.println("ExternatVet inserted");
}

@Test
@Ignore
public void testJoinedStrategySelect() {

Vet vet = em.find(Vet.class, 10);
assertNotNull(vet);

if (vet instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet;
System.out.println(externatVet);
} else if (vet instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet;
System.out.println(inHouseVet);
} else {
System.out.println("ERROR in Type");
}

Vet vet2 = em.find(Vet.class, 11);
assertNotNull(vet2);

if (vet2 instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet2;
System.out.println(externatVet);
} else if (vet2 instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet2;
System.out.println(inHouseVet);
} else {
System.out.println("ERROR in Type");
}

Vet vet = em.find(Vet.class, 6);
assertNotNull(vet);

if (vet instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet;
System.out.println(externatVet);
} else if (vet instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet;
System.out.println(inHouseVet);
} else if (vet instanceof Vet) {
System.out.println(vet);
} else {
System.out.println("ERROR in Type");
}
}

@Test
@Ignore
public void testJoinedStrategyUpdate() {

Vet vet = em.find(Vet.class, 10);
assertNotNull(vet);

if (vet instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet;
externatVet.setName("extVet Qualification 11 updated");
externatVet.setVisitingFees(101010);
em.merge(externatVet);
System.out.println(externatVet);
} else if (vet instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet;
inHouseVet.setName("Invet name 10 updated");
inHouseVet.setSalary(1010);
em.merge(inHouseVet);
System.out.println(inHouseVet);
} else {
System.out.println("ERROR in Type");
}

Vet vet2 = em.find(Vet.class, 11);
assertNotNull(vet2);

if (vet2 instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet2;
externatVet.setName("extVet Qualification 11 updated");
externatVet.setVisitingFees(111111);
em.merge(externatVet);
System.out.println(externatVet);
} else if (vet2 instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet2;
inHouseVet.setName("Invet name 11 updated");
inHouseVet.setSalary(1111);
em.merge(inHouseVet);
System.out.println(inHouseVet);
} else {
System.out.println("ERROR in Type");
}
}

@Test
@Ignore
public void testJoinedStrategyDelete() {

Vet vet = em.find(Vet.class, 10);
assertNotNull(vet);
em.remove(vet);
System.out.println("InHouseVet 10 : deleteds");

Vet vet2 = em.find(Vet.class, 11);
assertNotNull(vet2);

if (vet2 instanceof ExternatVet) {
ExternatVet externatVet = (ExternatVet) vet2;
em.remove(externatVet);
System.out.println("ExternatVet 11 : deleted");
} else if (vet2 instanceof InHouseVet) {
InHouseVet inHouseVet = (InHouseVet) vet2;
em.remove(inHouseVet);
System.out.println("InHouseVet 11 : deleteds");
} else {
System.out.println("ERROR in Type");
}
}

}

Tuesday, 13 August 2013

UML Use Case Diagram

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose. Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalities use cases are prepared and actors are identified.

The purposes of use case diagrams can be as follows:
  • Used to gather requirements of a system.
  • Used to get an outside view of a system.
  • Identify external and internal factors influencing the system.
  • Show the interacting among the requirements are actors.
How to draw Use Case Diagram?
Use case diagrams are considered for high level requirement analysis of a system. So when the requirements of a system are analyzed the functionalities are captured in use cases. So we can say that uses cases are nothing but the system functionalities written in an organized manner. Now the second things which are relevant to the use cases are the actors. Actors can be defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications. So in a brief when we are planning to draw an use case diagram we should have the following items identified:
  • Functionalities to be represented as an use case
  • Actors
  • Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.

The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionality performed.
  • Give a suitable name for actors.
  • Show relationships and dependencies clearly in the diagram.
  • Do not try to include all types of relationships. Because the main purpose of the diagram is to identify requirements.
  • Use note when ever required to clarify some important points.

These diagrams are used at a very high level of design. Then this high level design is refined again and again to get a complete and practical picture of the system. A well structured use case also describes the pre condition, post condition, exceptions. And these extra elements are used to make test cases when performing the testing.

The following are the places where use case diagrams are used:

  • Requirement analysis and high level design.
  • Model the context of a system.
  • Reverse engineering.
  • Forward engineering.



For example an online reservation system use case diagram had been introduced with the system boundaries separated by rectangular box, including two actors: the primary actor which is Customer can make all those use cases (Search flight use case, Make a reservation use case, Purchase a ticket use case, Check flight status use case, Cancel flight use case), other actor which is system actor Payment Process use a Validate credit card use case. This diagram show an extend relationship between Reschedule flight use case which extends Cancel flight use case and the Select seat use case which extends Purchase a ticket use case. A dependency relationship between Purchase a ticket Invoking use case include a Validate credit card Included use case

The following topics describe the relationships that you can use in use case diagrams:

Association relationships
In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.
Generalization relationships
In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use case diagrams.
Include relationships
In UML modeling, an include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use case model.
Extend relationships
In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of another use case (base). This type of relationship reveals details about a system or application that are typically hidden in a use case.

a good diagram i find while googling

Wednesday, 7 August 2013

UML Class Diagram

There are five key relationships between classes in a UML class diagram : dependency, aggregation, composition, inheritance and realization. These five relationships are depicted in the following diagram:
  • Dependency : class A uses class B
  • Aggregation : class A has a class B
  • Composition : class A owns a class B
  • Inheritance : class B is a Class A  (or class A is extended by class B)
  • Realization : class B realizes Class A (or class A is realized by class B)

What I hope to show here is how these relationships would manifest themselves in Java so we can better understand what these relationships mean and how/when to use each one. The above relationships are read as follows:

Dependency :
class A uses class B
Is represented when a reference to one class is passed in as a method parameter to another class. For example, an instance of class B is passed in to a method of class A:
public class A {

public void doSomething(B b) {

}

}

Aggregation :
class A has a class B
If class A stored the reference to class B for later use we would have a different relationship called Aggregation. A more common and more obvious example of Aggregation would be via setter injection:
public class A {

private B _b;

public void setB(B b) {
_b = b;
}

}

Composition :
class A owns a class B
Aggregation is the weaker form of object containment (one object contains other objects). The stronger form is called Composition. In Composition the containing object is responsible for the creation and life cycle of the contained object. Following are a few examples of Composition. First, via member initialization:
public class A {

private B _b = new B();

}

Second, via constructor initialization:
public class A {

private B _b;

public A() {
_b = new B();
} // default constructor

}

Third, via lazy init:
public class A {

private B _b;

public B getB() {
if (null == _b) {
_b = new B();
}
return _b;
} // getB()

}

Inheritance :
class B is a Class A  (or class A is extended by class B)
is a fairly straightforward relationship to depict in Java:
public class A {

...

} // class A

public class B extends A {

....

} // class B

Realization :
class B realizes Class A (or class A is realized by class B)
is also straighforward in Java and deals with implementing an interface:
public interface A {

...

} // interface A

public class B implements A {

...

} // class B


For more information about Association, Aggregation,and Composition visit this link.


Understanding Association, Aggregation, and Composition

In this article, we will try to understand three important concepts: association, aggregation, and composition. We will also try to understand in what kind of scenarios we need them. These three concepts have really confused a lot of developers and in this article.

For a little bit introduction on types of relationship visit this link

The UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways. There are three primary inter-object relationships: association, aggregation, and composition. Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity.

1. Association

The most abstract way to describe static relationship between classes(classifiers) is using the ‘Association’ link, which simply states that there is some kind of a link or a dependency between two classes or more.


An association defines a relationship between two or more classes. Binary associations are relationships between exactly two classes and a n-ary association is an association between three or more classes.

1.1. Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB instance, or returns instance of ClassB.


1.2. Strong Association

ClassA may also be linked to ClassB in order to show that it holds reference to ClassB instance.


2. Aggregation (Shared Association/Relation Aggregation)

Is a specialized association. It is specified by an aggregation association with a hollow diamond. A part in this type of aggregation can participate in several aggregates. In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, taking special notice that ClassB can also be aggregated by other classes in the application.


Aggregation protects the integrity of an assembly of objects by defining a single point of control, called the aggregate, in the object that represents the assembly. Aggregation also uses the control object to decide how the assembled objects respond to changes or instructions that might affect the collection.


A part classifier can belong to more than one aggregate classifier and it can exist independently of the aggregate. For example, an Engine class can have an aggregation relationship with a Car class;at the same time an Engine class can have an aggregation relationship with an Order class which indicates that the engine is part of the Car and the Order. Aggregations are closely related to compositions.

3. Composition (Not-Shared Association/Real Aggregation)

Is a stronger form of aggregation where the parts cannot exist without the whole. The parts can only participate in one composite. In a composition association relationship, data usually flows in only one direction (that is, from the whole classifier to the part classifier). Composition is shown as an association with a filled solid diamond nearest the class constituting the whole.



In cases where in addition to the part-of relationship between class Person and booth class Hand and class Leg - there’s a strong life cycle dependency between those classes, meaning that when class Person deleted then booth class Hand and class Leg are also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link.

NB:

Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class,  thus changes in the composed class cannot be propagated to the rest of the system. Consequently, usage of composition limits complexity growth as the system grows.

Aggregation v.s. Association:

The association link can replace the aggregation link in every situation, while aggregation cannot replace association in situations were there is only a ‘weak link’ between the classes.

Summarizing:

To avoid confusion henceforth for these three terms, I have put forward a table below which will help us compare them from three angles: owner, lifetime, and child object.

Association
Aggregation
Composition
Owner
No owner
Single or Multiple owner
Single owner
Life time
Have their own lifetime
Owner's life time
Child object
Child objects all are independent
Child objects belong to a single/multiple parent
Child objects belong to a single parent

Step by step Association, Aggregation, and Composition decision making

References:

ibm ,tutorialspoint, codeproject, sintef9013

How to link Java Classes to UML Class Diagram in JDeveloper

1.       Create an Aplication
2.       Create a Java Project  with type Custom Project
3.       Create UML project with type UML Project
3.1.    To Make UML Class Diagram:
3.1.1.  Create a new “Java Class Diagram”
3.1.2. Drag and drop the UML element into this diagram
3.1.3. Use a suitable relationship between each element
3.2.    To Link the UML to the Classes bi-directionally  and generate the classes from diagram
3.2.1. Select the UML Project
3.2.2. Right Click Select “Project Properties”
3.2.3. Go to “Project Source Paths”
3.2.4. Click Remove button to delete the original “src“ folder
3.2.5. Click add button and go through the source folder of the JAVA Project, and save this path

4.       Now your Application had a link between diagram and Classes 

Friday, 19 July 2013

LaserJet 1010 Windows 7 X64 Drivers solution

I had problems with LJ 1010 on Windows 7 x64, none of the drivers found on the internet worked.

Solution:

  1. Go to "Install new printer"
  2. In Windows control center then choose "Local printer"
  3. Then "DOT4_001 (Generic IEEE....)"
  4. Then choose "HP Jaserjet 3055 PCL5"



solution drawbacks:
The only thing I still miss is ability to print booklets. It prints only on one side and where native 1010 drivers for XP did pause before printing on the other side of paper it just stops printing... But at least I can change print options and print several pages per sheet.

Back again to my old printer. . .

Wednesday, 10 July 2013

JDeveloper Crashing


while restoring the JDeveloper to work the IDE hung giving this screen

The solution is to:
  1. End JDeveloper process
  2. Rename the system folder
  3. Re-Run JDeveloper and wait until new system folder creation done successfully
  4. Navigate to this Folder 
  5. o.ide
  6. Replace this file with the newly created one
  7. runStatus.xml
  8. Delete newly created system folder and rename the old one with its original name
  9. Run the JDeveloper
  10. Enjoy your configured IDE