Showing posts with label package. Show all posts
Showing posts with label package. Show all posts

Wednesday, 13 July 2011

Package Diagram

Classes represent the basic form of structuring an object-oriented System. Although they are wonderfully useful, we need something more to structure large Systems, which may have hundreds of classes.
A package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units. Its most common use is to group classes.

In a UML model, each class is a member of a single package. Packages can also be members of other packages, so we are left with a hierarchic structure in which top-level packages get broken down into sub packages with their own sub packages and so an until the hierarchy bottoms out in classes. A package can contain both sub packages and classes.

Each package represents a namespace, which means that every class must have a unique name within its own package.
Suppose, if we want to create a class called Date, and a Date class is already in the System package, we can have Date class as long as we put it in a separate package. To make it clear which is which, we can use a fully qualified name, that is, a name that Shows the owning package structure. We use double colons to Show package names in UML, so the dates might be System::Date and myPackage::Util::Date.

In diagrams, packages are shown with a tabbed folder. We can simply Show the package name or show the contents too. At any point, we can use fully qualified names or simply regular names. Showing the contents with class icons allows us to Show all the details of a class, even to the point of showing a class diagram within the package. Simply listing the names makes sense when all we want to do is indicate which classes are in which packages. UML allows classes in the package can be public or private.
 
The contents of a package can be drawn inside the package or outside the package attached by a line. If we draw the elements inside the package, write the name of the package in the folder tab.
Element Visibility

Elements in a package may have public or private visibility . Elements with public visibility are accessible outside the package. Elements with private visibility are available only to other elements inside the package. We can model public or private visibility in UML by writing a plus or minus symbol in front of the element's name

Package Dependency

Sometimes a class in one package needs to use a class in another package. This causes a dependency between packages : if an element in package A uses an element in package B, then package A depends on package B
Understanding the dependencies among packages is useful for analyzing the stability of software. In fact, the most common use of UML package diagrams is to give an overview of the core packages in our software and the dependencies among them. Packages can assist with organizing classes as deployment modules and in creating the build scripts.
Importing a package
When a package imports another package, elements in the importing package can use elements in the imported package without having to use their fully scoped names. This feature is similar to a Java import, in which a class can import a package and use its contents without having to provide their package names.
In an import relationship, the imported package is referred to as the target package. To show the import relation, draw a dependency arrow from the importing package to the target package with the stereotype import.
The package users imports security, so classes in users may use public classes in security without having to specify the package name


A package can also import a specific element in another package instead of the whole package. When importing a package, only public elements of the target package are available in the importing namespace.


 
The users package imports only the MyClassA element from the myPackage package
 
When to Use Package Diagrams

Package diagrams are extremely useful on larger-scale systems to get a picture of the dependencies between major elements of a system. These diagrams correspond well to common programming structures. Plotting diagrams of packages and dependencies helps to keep an application's dependencies under control.
 


 

 

Monday, 4 July 2011

Java package

Package Definition

A package is a collection of related classes.
It helps Organize your classes into a folder structure and make it easy to locate and use them.
More importantly,It helps improve re-usability.

Syntax:-
package <package_name>;

Package declaration

The first statement, other than comments, in a Java source file, must be the package declaration.
Following the optional package declaration, you can have import statements, which allow you to specify classes from other packages that can be referenced without qualifying them with their package.

Default package. Altho all Java classes are in a directory, it's possible to omit the package declaration. For small programs it's common to omit it, in which case Java creates what it calls a default package. Sun recommends that you do not use default packages.

Example of using package

Example1 : Creating the package:
package p1;
class c1{
public void m1(){
System.out.println("Method m1 of Class c1");
}
public static void main(String args[]){
c1 obj = new c1();
obj.m1();
}
}

Example 2 : Creating the sub packages:
package p1.p2;
class c2{

public void m2(){
System.out.println("Method m2 of Class c2");
}
public static void main(String args[]){
c2 obj = new c2();
obj.m2();
}
}


Compiling the above Classes

When a class is placed in a package the class file must be located in a sub-directory under one of the directories listed in the CLASSPATH. The sub-directory structure must map exactly onto the package name.
Given a CLASSPATH=/lib the above class must reside in one of:
./p1 
/lib/p1

Or  in case of example2 :
./p1/p2
or /lib/p1/p2

The javac compiler creates class files in the current directory by default, even if they are specified as belonging to a package. To get around this, use the -d flag to the compiler . Which will create the necessary directories under the /lib directory, if your classpath is /lib.

Take example1, Save the file as Demo.java.
Compile the file as,
javac – d . Demo.java
Run the code as
java p1.c1

Taking example2:
Save the file as Demo2.java.
Compile the file as
javac – d . Demo2.java

Run the code as
java p1.p2.c2

Importing a package


To create an object  of a class (bundled in a package), in your code, you have to use its fully qualified name.
Ex.
java.awt.event.actionListner object = new java.awt.event.actionListner();

But , it could become tedious to type in the long dot-separated package path name for every class you want to use. Instead it is recommended you use the import statement.

Syntax
import <package_name>;

Once imported , you can use the class without mentioning its fully qualified name.

import java.awt.event.*; // * signifies all classes in this package
import javax.swing.JFrame // here only the JFrame class is imported
//Usage
JFrame f = new JFrame; // without fully qualified name.

To import package

// Using packages created in earlier assignment
package p3;
import p1.*; //imports classes only in package p1 and NOT in the sub-package p2
&nbsp;
class c3{
public void m3(){
System.out.println("Method m3 of Class c3");
}
public static void main(String args[]){
c1 obj1 = new c1();
obj1.m1();
p1.p2.c2 obj2 = new p1.p2.c2();
obj2.m2();
}
}

Save the file as Demo2.java . Compile the file using the command
javac –d .Demo2.java

Execute the code using the command
java p3.c3

Packages - points to note:


  • To avoid naming conflicts packages are given names of the domain name of the company in reverse Ex :  com.guru99. com.microsoft, com.infosys etc.
  • When a package name is not specified , a class is into the default package (the current working directory) and the package itself is given no name. Hence you were able to execute assignments earlier.
  • While creating a package, care should be taken that the statement for creating  package must be written before any other import statements
  • When importing packages with * format, only classes in that packages are imported and not sub packages.

Monday, 23 May 2011

Java interview questions on packages

Which package is always imported by default?
No. It is by default loaded internally by the JVM. The java.lang package is always imported by default.

Can I import same package/class twice? Will the JVM load the package twice at runtime?
One can import the same package or same class multiple times. Neither compiler nor JVM complains anything about it. And the JVM will internally load the class only once no matter how many times you import the same class.

Does importing a package imports the sub packages as well? E.g. Does importing com.bob.* also import com.bob.code.*?
No you will have to import the sub packages explicitly. Importing com.bob.* will import classes in the package bob only. It will not import any class in any of its sub package’s.

Explain the usage of Java packages.
A Java package is a naming context for classes and interfaces. A package is used to create a separate name space for groups of classes and interfaces. Packages are also used to organize related classes and interfaces into a single API unit and to control accessibility to these classes and interfaces.
For example: The Java API is grouped into libraries of related classes and interfaces; these libraries are known as package.

Are the imports checked for validity at compile time? e.g. will the code containing an import such as java.lang.BOB compile?
Yes the imports are checked for the semantic validity at compile time. The code containing above line of import will not compile. It will throw an error saying, cannot resolve symbol.