The Spiral Model

The spiral model, originally proposed by Boehm , is an evolutionary software

process model that couples the iterative nature of prototyping with the controlled and

systematic aspects of the linear sequential model. It provides the potential for rapid

development of incremental versions of the software. Using the spiral model, software

is developed in a series of incremental releases. During early iterations, the

incremental release might be a paper model or prototype. During later iterations,

increasingly more complete versions of the engineered system are produced.

A spiral model is divided into a number of framework activities, also called task

regions.6 Typically, there are between three and six task regions. A spiral model

 that contains six task regions:

• Customer communication—tasks required to establish effective communication

between developer and customer.

• Planning—tasks required to define resources, timelines, and other projectrelated

information.

• Risk analysis—tasks required to assess both technical and management

risks.

• Engineering—tasks required to build one or more representations of the

application.

• Construction and release—tasks required to construct, test, install, and

provide user support (e.g., documentation and training).

• Customer evaluation—tasks required to obtain customer feedback based

on evaluation of the software representations created during the engineering

stage and implemented during the installation stage.

Each of the regions is populated by a set of work tasks, called a task set, that are

adapted to the characteristics of the project to be undertaken. For small projects, the

number of work tasks and their formality is low. For larger, more critical projects,

each task region contains more work tasks that are defined to achieve a higher level

of formality

.

As this evolutionary process begins, the software engineering team moves around

the spiral in a clockwise direction, beginning at the center. The first circuit around

the spiral might result in the development of a product specification; subsequent

passes around the spiral might be used to develop a prototype and then progressively

more sophisticated versions of the software. Each pass through the planning region

results in adjustments to the project plan. Cost and schedule are adjusted based on

feedback derived from customer evaluation. In addition, the project manager adjusts

the planned number of iterations required to complete the software.

Unlike classical process models that end when software is delivered, the spiral

model can be adapted to apply throughout the life of the computer software. An alternative

view of the spiral model can be considered by examining the project entry point

axis. Each cube placed along the axis can be used to represent

the starting point for different types of projects. A “concept development

project” starts at the core of the spiral and will continue (multiple iterations occur

along the spiral path that bounds the central shaded region) until concept development

is complete. If the concept is to be developed into an actual product, the process

proceeds through the next cube (new product development project entry point) and

a “new development project” is initiated. The new product will evolve through a number

of iterations around the spiral, following the path that bounds the region that has

somewhat lighter shading than the core. In essence, the spiral, when characterized

in this way, remains operative until the software is retired. There are times when the

process is dormant, but whenever a change is initiated, the process starts at the appropriate

entry point .

The spiral model is a realistic approach to the development of large-scale systems

and software. Because software evolves as the process progresses, the developer and

customer better understand and react to risks at each evolutionary level. The spiral model

uses prototyping as a risk reduction mechanism but, more important, enables the developer

to apply the prototyping approach at any stage in the evolution of the product. It

maintains the systematic stepwise approach suggested by the classic life cycle but incorporates

it into an iterative framework that more realistically reflects the real world. The

spiral model demands a direct consideration of technical risks at all stages of the project

and, if properly applied, should reduce risks before they become problematic.

But like other paradigms, the spiral model is not a panacea. It may be difficult to

convince customers (particularly in contract situations) that the evolutionary approach

is controllable. It demands considerable risk assessment expertise and relies on this

expertise for success. If a major risk is not uncovered and managed, problems will

undoubtedly occur. Finally, the model has not been used as widely as the linear

sequential or prototyping paradigms. It will take a number of years before efficacy of

this important paradigm can be determined with absolute certainty.

Walkthrough & Inspection

Review is "A process or meeting during which artifacts of software product are examined by project stockholders, user representatives, or other interested parties for feedback or approval”. Software Review can be on Technical specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specific to work product, it can be conducted at any stage of the software development life cycle.

Purpose of conducting review is to minimize the defect ratio as early as possible in Software Development life cycle. As a general principle, the earlier a document is reviewed, the greater will be the impact of its defects on any downstream activities and their work products. Magnitude cost of defect fixing after the release of the product is around 60-100x. Review can be formal or informal. Informal reviews are referred as walkthrough and formal as Inspection.

Walkthrough: Method of conducting informal group/individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre planned or can be conducted at need basis and generally people working on the work product are involved in the walkthrough process.
The Purpose of walkthrough is to:
· Find problems
· Discuss alternative solutions
· Focusing on demonstrating how work product meets all requirements.IEEE 1028 recommends three specialist roles in a walkthrough:
Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author)
Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session.
Author: who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items.

Walkthrough Process: Author describes the artifact to be reviewed to reviewers during the meeting. Reviewers present comments, possible defects, and improvement suggestions to the author. Recorder records all defect, suggestion during walkthrough meeting. Based on reviewer comments, author performs any necessary rework of the work product if required. Recorder prepares minutes of meeting and sends the relevant stakeholders and leader is normally to monitor overall walkthrough meeting activities as per the defined company process or responsibilities for conducting the reviews, generally performs monitoring activities, commitment against action items etc.

Inspection: An inspection is a formal, rigorous, in-depth group review designed to identify problems as close to their point of origin as possible., Inspection is a recognized industry best practice to improve the quality of a product and to improve productivity, Inspections is a formal review and generally need is predefined at the start of the product planning, The objectives of the inspection process are to
· Find problems at the earliest possible point in the software development process
· Verify that the work product meets its requirement
· Ensure that work product has been presented according to predefined standards
· Provide data on product quality and process effectiveness
· Inspection advantages are to build technical knowledge and skill among team members by reviewing the output of other people
· Increase the effectiveness of software testing.
IEEE 1028 recommends three following roles in an Inspection:
Inspector Leader: The inspection leader shall be responsible for administrative tasks pertaining to the inspection, shall be responsible for planning and preparation, shall ensure that the inspection is conducted in an orderly manner and meets its objectives, should be responsible for collecting inspection data
Recorder: The recorder should record inspection data required for process analysis. The inspection leader may be the recorder.
Reader: The reader shall lead the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work product and highlighting important aspects
Author: The author shall be responsible for the software product meeting its inspection entry criteria, for contributing to the inspection based on special understanding of the software product, and for performing any rework required to make the software product meet its inspection exit criteria.
Inspector: Inspectors shall identify and describe anomalies in the software product. Inspectors shall be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering). Only those viewpoints pertinent to the inspection of the product should be present. Some inspectors should be assigned specific review topics to ensure effective coverage. For example, one inspector may focus on conformance with a specific standard or standards, another on syntax, and another for overall coherence. These roles should be assigned by the inspection leader when planning the inspection.
All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over any member of the inspection team shall not participate in the inspection
Inspection Process: Following are review phases:
· Planning
· Overview
· Preparation
· Examination meeting
Planning:
· Inspection Leader perform following task in planning phase
· Determine which work products need to be inspected
· Determine if a work product that needs to be inspected is ready to be inspected
· Identify the inspection team
· Determine if an overview meeting is needed.
The moderator ensures that all inspection team members have had inspection process training. The moderator obtains a commitment from each team member to participate. This commitment means the person agrees to spend the time required to perform his or her assigned role on the team. Identify the review materials required for the inspection, and distribute materials to relevant stake holders
Overview: Purpose of the overview meeting is to educate inspectors; meeting is lead by Inspector lead and is presented by author, overview is presented for the inspection, this meeting normally acts as optional meeting, purpose to sync the entire participant and the area to be inspected.
Preparation: Objective of the preparation phase is to prepare for the inspection meeting by critically reviewing the review materials and the work product, participant drill down on the document distributed by the lead inspector and identify the defect before the meeting
Examination meeting: The objective of the inspection meeting is to identify final defect list in the work product being inspected, based on the initial list of defects prepared by the inspectors [identified at preparation phase and the new one found during the inspection meeting. The Lead Auditor opens the meeting and describes the review objectives and area to be inspected. Identify that all participants are well familiar with the content material, Reader reads the meeting material and inspector finds out any inconsistence, possible defects, and improvement suggestions to the author. Recorder records all the discussion during the inspection meeting, and mark actions against the relevant stake holders. Lead Inspector may take decision that if there is need of follow up meeting. Author updates the relevant document if required on the basis of the inspection meeting discussion
Rework and Follow-up: Objective is to ensure that corrective action has been taken to correct problems found during an inspection.

Image Sequence in ImageJ

Creates a new image window or stack. A dialog box allows you to specify the image title, type, dimensions and initial content.

Name is the title that will be used for the Window. Type is the image type: 8-bit grayscale, 16-bit grayscale (unsigned), 32-bit (float) grayscale or RGB color. Fill With (White, Black or Ramp) specifies how the image is initialized. Width and Height specify the image dimensions in pixels. Set Slices to a value greater than one to create a stack.

Image▷Hyperstacks▷New Hyperstack…↓, Image Types and Formats↑

import ij.IJ;
import ij.ImagePlus;
import ij.WindowManager;

public class TestImp {

    public static void main(String[] args) {

        IJ.run("Image Sequence...", "open=C:\tempfiles");

        // "open=C:\tempfiles number=2 starting=1 increment=1 scale=100 file=[] or=[] sort");

        ImagePlus imagePlus = WindowManager.getCurrentImage();

        System.out.println(imagePlus.getStackSize());

    }
}

Regarding calibration in the dicom image using ImageJ

1. I assume you have these in DICOM format. In ImageJ it is simple to import a single DICOM image and the calibration is done for you (the DICOM header contains fields for slope and intercept (usually 1 and -1024)). Since you have a stack this is probably not much good. For importing tomographic studies I use the "Import Dicom sequence" plugin available here: http://www.iftm.de/telemedizin/dcmimex.htm

From what I remember it is not the most straight-forward plugin to install but will nicely import a sequence of DICOM images as a stack. It does not, however, seem to calibrate the gray levels into hounsfield units. To do this choose Analyse->Calibrate. Choose "Straight line" as the function, type -1024 in the left box and 0 in the right box. When you press OK you get a straight-line graph of the calibration and a label with straight line formula y = a + bx. a should be -1024 and b should be 1. If they are then we have a calibration to HU.

To demonstrate the HU calibration, move the cursor around the image and observe the "value" in the IJ status bar. The value is in HU and the gray level appears in brackets.

2. Images typically only contain 256 gray levels when displayed, even though the image may contain values of any number (eg CT from -1024 to ~32k). So gray levels have to be "binned" in an image, just like in a histogram. So the column labelled "level" is the gray level displayed in the image and the "bins" are demonstrated in the second column. The size of the bin is dictated by the min and max pixel levels.

I hope I pitched that at the right level. Enjoy ImageJ ;-)

Converting CT Data to Hounsfield Units

According to Wikipedia, the Hounsfield scale was invented in 1972 by Godfrey Newbold Hounsfield. His scale is a quantitative measure of radiodensity and is used to evaluate CAT scans. Pixels in an image obtained by CT scanning are displayed in terms of relative radiodensity. 

The pixel value is displayed according to the mean attenuation of the tissue that it corresponds to on a scale from -1024 to +3071 on the Hounsfield scale. Water has an attenuation of 0 Hounsfield units (HU) while air is -1000 HU, bone is typically +400 HU or greater and metallic implants are usually +1000 HU. 

To convert from the normal units found in CT data (a typical data set ranges from 0 to 4000 or so) you have to apply a linear transformation of the data. The equation is:

   hu = pixel_value * slope + intercept

The real question is where do you find the slope and intercept used in the conversion?

Normally, these values are stored in the DICOM file itself. The tags are generally called the Rescale Slope and Rescale Intercept, and typically have values of 1 and -1024, respectively.

To show you how to obtain these values, I downloaded a sample CT data set, named CT-MONO2-16-ankle.dcm. This file was created on a GE Medical Systems scanner. After unpacking the compressed file, and adding a dcm file extension to the name (a convenience), I opened the file and dumped the elements to the display.

   IDL> dicomObj = Obj_New('IDLffDICOM', 'CT-MONO2-16-ankle.dcm')
   IDL> dicomObj -> DumpElements
      0 : (0002,0000) : UL : META Group Length : 4 : 188 
      1 : (0002,0001) : OB : META File Meta Information Version : 2 : 0 1 
      2 : (0002,0002) : UI : META Media Stored SOP Class UID : 26 : 1.2.840.10008.5.1.4.1.1.7
     ...
     ...
     50 : (0028,1052) : DS : IMG Rescale Intercept : 6 : -1024 
     51 : (0028,1053) : DS : IMG Rescale Slope : 2 : 1 
     52 : (0028,1054) : LO : IMG Rescale Type : 2 : US
     53 : (7FE0,0000) : UL : PXL Group Length : 4 : 524296 
     54 : (7FE0,0010) : OW : PXL Pixel Data : 524288 : 4080 4080 4080 4080 4080 ...

I found the Rescale Slope and Rescale Intercept as elements 51 and 50. As expected, they had values of 1 and -1024.

Next, I read the data from the DICOM file, and applied the transformation.

 
   IDL> imagePtr = (dicomObj -> GetValue('7FE0'x, '0010'x))[0]
   IDL> MinMax, *imagePtr 
        32   4080
   IDL> image_hu = *imagePtr * 1 + (-1024)
   IDL> MinMax, image_hu
        -992   3056

This image will appear upside down on my display, so I want to reverse the Y direction.

   IDL> image_hu = Reverse(image_hu, 2)

If I just want to see the bone structure (probably a good idea with this ankle image), I can display it like this.

   TV, BytScl(image_hu, Min=600, Max=3000)

The bone structure of the CT angle image, displayed in Hounsfield units.

 

Be sure to clean up your pointers and objects.

   IDL> Ptr_Free, imagePtr
   IDL> Obj_Destroy, dicomObj

How much memory do Enums take?

In Java, an enum is a full-blown class:

Java programming language enum types are much more powerful than their counterparts in other languages. The enum declaration defines a class (called an enum type). The enum class body can include methods and other fields.

In order to see the actual size of each enum, let's make an actual enum and examine the contents of the class file it creates.

Let's say we have the following Constants enum class:

public enum Constants {
  ONE,
  TWO,
  THREE;
}

Compiling the above enum and disassembling resulting class file with javap gives the following:

Compiled from "Constants.java"
public final class Constants extends java.lang.Enum{
    public static final Constants ONE;
    public static final Constants TWO;
    public static final Constants THREE;
    public static Constants[] values();
    public static Constants valueOf(java.lang.String);
    static {};
}

The disassembly shows that that each field of an enum is an instance of the Constants enum class. (Further analysis with javap will reveal that each field is initialized by creating a new object by calling the new Constants(String) constructor in the static initialization block.)

Therefore, we can tell that each enum field that we create will be at least as much as the overhead of creating an object in the JVM.

ZIP and UNZIP with Passwords in Java

Zip and Unzip are a very common activities for a computer user. A user normally uses the zip utility to compress a directory to create a zip file. There are many ready-made software such as winzip,7zip, and winrar that are available to achieve this. 

However, it is also possible to protect the zip file with a password so that the end user has to provide the password to unzip the zip file. This is the very common scenario that can be achieved by a zip utility tool. The significant part of my article is to provide you with the solution to achieve this using a Java program. While developing the project you may encounter a scenario in which you have to create a password-protected zip file that can be unzipped by any zip tool like winzip. Let me provide a complete scenario for your understanding.

In a system, some files are generated for a user and all the files are zipped with a password. The generated password protected zip file is sent to the user through email and the password for the zip file to open is sent to the particular user as an SMS to the user's mobile. 

 Similarly the end-user creates a password protected zip file and uploads to a online system with the user's password in a text field. In this case we have to develop a system where the system will be able to create a password protected zip file and should be able to extract all the files from a password protected zip file. Let me show you how you can achieve it.

Technicalities
However, Java provides the feature of creating a zip file and also provides the feature to unzip or decompress a zip file. But there is no default java API to create a password protected zip file and also there is no default java API to unzip a password protected zip file. To facilitate this feature of zip utility some developers have developed java API in this regard. We have to use their API to achieve this. We have to look into the following aspects of zip utility.

1. Java-enabled system should be able to generate a password protected zip file and that password protected zip file can be unzipped by any zip utility like winzip and others
2. Java-enabled system should be able to decompress or unzip a password protected zip file created by any zip utility like winzip and others.

The followings are the APIs you have to use for this objective:

1.To create a password protected zip file in java, you have to use “winzipaes”. It is avilable in Google code. You can download the .jar file and the source code from the following link.

"http://code.google.com/p/winzipaes/"

This API helps to add a password to a already created zip file. It means that if you want to create a password protected zip file, first you have to create a zip file and then you can add a password that zip file. It is a pure java API works with any operating system. You have to download the following jar file from the above URL.

passwordcompressor.jar

2.To unzip or decompress a password protected zip file, you have to use “sevenzipjbind”. It is available in sourceforge.net site. You can download the .jar files from the following link: http://sourceforge.net/projects/sevenzipjbind/files/. This API helps to extract all the files and folders from password protected zip file created by any zip utility tool. You have to download the following .jar files from the above URL.

sevenzipjbinding-AllPlatforms.jar
sevenzipjbinding.jar

3.For password protection, you have to use Bouncecastle cryptographic API. You can download the .jar file from the following link.
http://www.bouncycastle.org/
You have to download the following .jar files from the above URL.
bcprov-jdk15-145.jar

After downloading all the .jar files, put all the .jar files in your classpath. I have written a java program by using all these APIs to achieve all the above mentioned functionalities.

Have a look at the following code structure.

Code for ZipUtil.java

	import java.io.File;
	import java.io.FileInputStream;
	import java.io.FileNotFoundException;
	import java.io.FileOutputStream;
	import java.io.IOException;
	import java.io.OutputStream;
	import java.io.RandomAccessFile;
	import java.util.Arrays;
	import java.util.zip.ZipEntry;
	import java.util.zip.ZipInputStream;
	import java.util.zip.ZipOutputStream;
	import de.idyl.crypto.zip.AesZipFileEncrypter;
	import net.sf.sevenzipjbinding.ExtractOperationResult;
	import net.sf.sevenzipjbinding.ISequentialOutStream;
	import net.sf.sevenzipjbinding.ISevenZipInArchive;
	import net.sf.sevenzipjbinding.SevenZip;
	import net.sf.sevenzipjbinding.SevenZipException;
	import net.sf.sevenzipjbinding.impl.RandomAccessFileInStream;
	import net.sf.sevenzipjbinding.simple.ISimpleInArchive;
	import net.sf.sevenzipjbinding.simple.ISimpleInArchiveItem;
	/**
	* This is a utility class having utility method for various kinds of zip and
	* unzip operation. This class performs the following operations. 1. Normal
	* zipping a directory 2. Zipping a directory with password 3. Normal unzipping
	* a zip file 4. Unzipping a password protected zip file
	*
	* @author Jay Thakkar
	*
	*/
	public class ZipUtil {
	/**
	* This method is used to write the contents from a zip file to a file
	*
	* @param file
	* of type {@link File}
	* @param zipIn
	* of type {@link ZipInputStream}
	*/
	private static void writeFile(File file, ZipInputStream zipIn) {
	try {
	OutputStream outStream = new FileOutputStream(file);
	byte[] buff = new byte[1024];
	int len;
	while ((len = zipIn.read(buff)) > 0) {
	outStream.write(buff, 0, len);
	}
	outStream.close();
	} catch (Exception e) {
	e.printStackTrace();
	}
	}
	/**
	* This method is used to extract the zip file to a destination directory
	*
	* @param srcZipfile
	* of type {@link File} indicating the source zip file
	* @param destinationDir
	* of type {@link File} indicating the destination directory
	* where the zip file will be extracted.
	* @throws IOException
	*/
	private static void extract(File srcZipfile, File destinationDir)
	throws IOException {
	ZipInputStream zipIn = null;
	try {
	zipIn = new ZipInputStream(new FileInputStream(srcZipfile));
	ZipEntry entry = null;
	while ((entry = zipIn.getNextEntry()) != null) {
	String outFilename = entry.getName();
	if (!new File(destinationDir, outFilename).getParentFile()
	.exists())
	new File(destinationDir, outFilename).getParentFile()
	.mkdirs();
	if (!entry.isDirectory())
	writeFile(new File(destinationDir, outFilename), zipIn);
	}
	System.out.println("Zip file extracted successfully...");
	} catch (Exception e) {
	e.printStackTrace();
	} finally {
	if (zipIn != null) {
	zipIn.close();
	}
	}
	}
	/**
	* This method is used to zip or compress a directory to create a zip file.
	*
	* @param directory
	* of type String indicating the source directory to be zipped
	* @param zos
	* of type {@link ZipOutputStream}
	* @param path
	* of type String indicating the path
	* @throws IOException
	*/
	private static void compressDir(String directory, ZipOutputStream zos,
	String path) throws IOException {
	File zipDir = new File(directory);
	String[] dirList = zipDir.list();
	byte[] readBuffer = new byte[2156];
	int bytesIn = 0;
	for (int i = 0; i < dirList.length; i++) {
	File f = new File(zipDir, dirList[i]);
	if (f.isDirectory()) {
	String filePath = f.getPath();
	compressDir(filePath, zos, path + f.getName() + "/");
	continue;
	}
	FileInputStream fis = new FileInputStream(f);
	try {
	ZipEntry anEntry = new ZipEntry(path + f.getName());
	zos.putNextEntry(anEntry);
	bytesIn = fis.read(readBuffer);
	while (bytesIn != -1) {
	zos.write(readBuffer, 0, bytesIn);
	bytesIn = fis.read(readBuffer);
	}
	} catch (Exception e) {
	e.printStackTrace();
	} finally {
	fis.close();
	}
	}
	}
	/**
	* This method is used to zip a directory
	*
	* @param dirName
	* of type String indicating the path of the directory to be
	* zipped
	* @param zipFileName
	* of type String indicating the file name for the zip file
	*/
	public static void zipDir(String dirName, String zipFileName) {
	if (zipFileName == null) {
	File tempFile = new File(dirName);
	zipFileName = tempFile.getAbsoluteFile().getParent()
	+ File.separator + tempFile.getName() + ".zip";
	}
	try {
	ZipOutputStream zos = new ZipOutputStream(new FileOutputStream(
	zipFileName));
	compressDir(dirName, zos, new File(dirName).getName()
	+ File.separator);
	zos.close();
	} catch (NullPointerException npe) {
	npe.printStackTrace();
	} catch (FileNotFoundException e) {
	e.printStackTrace();
	} catch (IOException ie) {
	ie.printStackTrace();
	}
	}
	/**
	* This method is used to create a password protected zip file.
	*
	* @param dirName
	* of type String indicating the name of the directory to be
	* zipped
	* @param zipFileName
	* of type String indicating the name of the zip file to be
	* created
	* @param password
	* of type String indicating the password
	*/
	public static void zipDirWithPassword(String dirName, String zipFileName,
	String password) {
	if (zipFileName == null) {
	File tempFile = new File(dirName);
	zipFileName = tempFile.getAbsoluteFile().getParent()
	+ File.separator + tempFile.getName() + ".rar";
	}
	zipDir(dirName, zipFileName);
	String tempZipFileName = new File(dirName).getAbsoluteFile()
	.getParent() + File.separator + "tempencrypted.rar";
	try {
	AesZipFileEncrypter enc = new AesZipFileEncrypter(tempZipFileName);
	enc.addEncrypted(new File(zipFileName), password);
	new File(zipFileName).delete();
	new File(tempZipFileName).renameTo(new File(zipFileName));
	} catch (IOException e) {
	e.printStackTrace();
	}
	}
	/**
	* This method is used to unzip a zip file to a directory
	*
	* @param sourceZipFile
	* of type String indicating the source zip file
	* @param destinationDir
	* of type String indicating the destination directory where the
	* zip file will be extracted.
	*/
	public static void unzipDir(String sourceZipFile, String destinationDir) {
	try {
	extract(new File(sourceZipFile), new File(destinationDir));
	} catch (Exception e) {
	e.printStackTrace();
	}
	}
	/**
	* This method is used to unzip a password protected zip file.
	*
	* @param sourceZipFile
	* of type String indicating the source zip file
	* @param destinationDir
	* of type String indicating the directory where the zip file
	* will be extracted.
	* @param password
	* of type String indicating the password.
	*/
	public static void unzipDirWithPassword(final String sourceZipFile,
	final String destinationDir, final String password) {
	RandomAccessFile randomAccessFile = null;
	ISevenZipInArchive inArchive = null;
	try {
	randomAccessFile = new RandomAccessFile(sourceZipFile, "r");
	inArchive = SevenZip.openInArchive(null, // autodetect archive type
	new RandomAccessFileInStream(randomAccessFile));
	// Getting simple interface of the archive inArchive
	ISimpleInArchive simpleInArchive = inArchive.getSimpleInterface();
	for (final ISimpleInArchiveItem item : simpleInArchive
	.getArchiveItems()) {
	final int[] hash = new int[] { 0 };
	if (!item.isFolder()) {
	ExtractOperationResult result;
	result = item.extractSlow(new ISequentialOutStream() {
	public int write(final byte[] data)
	throws SevenZipException {
	try {
	if (item.getPath().indexOf(File.separator) > 0) {
	String path = destinationDir
	+ File.separator
	+ item.getPath().substring(
	0,
	item.getPath().lastIndexOf(
	File.separator));
	File folderExisting = new File(path);
	if (!folderExisting.exists())
	new File(path).mkdirs();
	}
	OutputStream out = new FileOutputStream(
	destinationDir + File.separator
	+ item.getPath());
	out.write(data);
	out.close();
	} catch (Exception e) {
	e.printStackTrace();
	}
	hash[0] |= Arrays.hashCode(data);
	return data.length; // Return amount of proceed data
	}
	}, password); // / password.
	if (result == ExtractOperationResult.OK) {
	System.out.println(String.format("%9X | %s", hash[0],
	item.getPath()));
	} else {
	System.err.println("Error extracting item: " + result);
	}
	}
	}
	} catch (Exception e) {
	e.printStackTrace();
	} finally {
	if (inArchive != null) {
	try {
	inArchive.close();
	} catch (SevenZipException e) {
	System.err.println("Error closing archive: " + e);
	e.printStackTrace();
	}
	}
	if (randomAccessFile != null) {
	try {
	randomAccessFile.close();
	} catch (IOException e) {
	System.err.println("Error closing file: " + e);
	e.printStackTrace();
	}
	}
	}
	}
	}

view raw ZipUtil.java hosted with ❤ by GitHub