An insurance broker receives an inquiry from a client regarding by-law insurance. Give reasons why such an inquiry might have been made. What losses would such insurance cover?
Answer:
One of the exclusion of Basic Fire Policy says the by-law expenses are not covered. It means loss arising in any way from the enforcement of any by-law or other law regulating zoning or the demolition, repair or construction of buildings, making it impossible to repair or reinstate the property as it was just before the loss, is excluded.
Expenses imposed by-law are independent of any insured peril. Insureds would be subject to by-laws even if the loss was caused by an uninsured peril or even if there is no insurance. Therefore, insurers are not obliged to assume such expenses.
If insureds wish to be indemnified of by-law expenses, they need to add to their policies some additional coverage by endorsement, which insurers receive additional premium and insureds receive boardened financial protection and they will recover the additional costs that by-laws impose on them.
Tuesday, September 26, 2006
Insurance on Property - 1.4
Give an example of circumstances in which the heat process exclusion in the Basic Fire Policy does not apply to part of a loss.
Answer:
Loss or damage to goods undergoing a process involving the application of heat is excluded if it results from the process. However, we cannot exclude such goods automatically from the policy. A fire starting elsewhere in an insured's premises eventually may destroy goods undergoing a heat process. The exclusion would not operate in such circumstances.
Only the goods actually undergoing the process are excluded. The exclusion would not apply to other property burned when a fire spreads beyond the excluded property.
Once a computer center suffered a fire. The root cause was one of the terminals. That terminal was undergoing a process involving the application of heat. That terminal should be excluded. At the same time, for other terminals and computers, even they were all generating heat, they should not be excluded and loss on these equipments should be covered.
Answer:
Loss or damage to goods undergoing a process involving the application of heat is excluded if it results from the process. However, we cannot exclude such goods automatically from the policy. A fire starting elsewhere in an insured's premises eventually may destroy goods undergoing a heat process. The exclusion would not operate in such circumstances.
Only the goods actually undergoing the process are excluded. The exclusion would not apply to other property burned when a fire spreads beyond the excluded property.
Once a computer center suffered a fire. The root cause was one of the terminals. That terminal was undergoing a process involving the application of heat. That terminal should be excluded. At the same time, for other terminals and computers, even they were all generating heat, they should not be excluded and loss on these equipments should be covered.
Insurance on Property - 1.3
Give an example of circumstances in which a business suffers both direct and indirect loss. Explain the difference between the two. (An exmaple taken from the course text is not acceptable.)
Answer:
Fire insurance policies indemnify the insured against direct loss or damage to property insured, but do not cover indirect loss. A direct loss is the loss of economic value that occurs when property is damaged or destroyed. An indirect loss is the economic loss that arise from the direct loss or damage to property.
A hotel is destroyed by a fire. The hotel own lost the value of the building. This is a direct loss. And the hotel won't be able to run business. Its business interrupted. This is an indirect loss. A photographer may have left his equipments in the hotel. The loss of equipments is a direct loss. For the photographer can not get his equipment in time so he can not report an event. This is an indirect loss.
Answer:
Fire insurance policies indemnify the insured against direct loss or damage to property insured, but do not cover indirect loss. A direct loss is the loss of economic value that occurs when property is damaged or destroyed. An indirect loss is the economic loss that arise from the direct loss or damage to property.
A hotel is destroyed by a fire. The hotel own lost the value of the building. This is a direct loss. And the hotel won't be able to run business. Its business interrupted. This is an indirect loss. A photographer may have left his equipments in the hotel. The loss of equipments is a direct loss. For the photographer can not get his equipment in time so he can not report an event. This is an indirect loss.
Insurance on Property - 1.2
What obligations are placed upon an insurer that receives a written application for fire insurance? (Your answer should include provincial differences, if any.)
Answer:
When an insurer receives a written application for fire insurance, any policy the insurer inssues must reflect that application, unless the insurer points out in writing how it differs from the application.
In the common law provinces, the insured may reject the policy within two weeks of receiving the notification. If the insured does nothing within that time, the insurer can assume the insured has accepted that policy.
In Quebec, the insurer is required to include a copy the application with the policy. However, there is no specified time by which an insured must reject a policy.
Answer:
When an insurer receives a written application for fire insurance, any policy the insurer inssues must reflect that application, unless the insurer points out in writing how it differs from the application.
In the common law provinces, the insured may reject the policy within two weeks of receiving the notification. If the insured does nothing within that time, the insurer can assume the insured has accepted that policy.
In Quebec, the insurer is required to include a copy the application with the policy. However, there is no specified time by which an insured must reject a policy.
Insurance on Property - 1.1
In addition to damage or destruction by an insured peril of property insured under a Basic Fire Policy, the insured may incur expenses for the removal of debris left by the loss.
Describe the coverage provided by the Basic Fire Policy for such expense.
Answer:
The Basic Fire Policy indemnifies the insured for the value of insured property damaged or destroyed. But the loss many also leave behind debris that must be removed, especially if the property is to be rebuilt or repaired. Without special provision in the policy, the expense would not be covered by the policy.
This expense is considered to be covered by the policy if it is included in the amount of insurance chosen by the insured. In this case, the total amount of insurance is the total of both loss of or damage to the insured's property and the expense to remove any debris left by the loss. However, if the policy contains a coinsurance clause, this expense will not be included.
Describe the coverage provided by the Basic Fire Policy for such expense.
Answer:
The Basic Fire Policy indemnifies the insured for the value of insured property damaged or destroyed. But the loss many also leave behind debris that must be removed, especially if the property is to be rebuilt or repaired. Without special provision in the policy, the expense would not be covered by the policy.
This expense is considered to be covered by the policy if it is included in the amount of insurance chosen by the insured. In this case, the total amount of insurance is the total of both loss of or damage to the insured's property and the expense to remove any debris left by the loss. However, if the policy contains a coinsurance clause, this expense will not be included.
Friday, September 22, 2006
What is OOAD
To facilitate software development, the practice of object-oriented analysis and design (OOAD) has developed in tandem with object-oriented technology.
OOAD focuses on analyzing the requirements of a system and designing a model of the system before any code is developed.
OOAD is done to ensure that the purpose and requirements of a system are thoroughly captured and documented before the system is built.
Although it sounds obvious, it is very important that the proposed system will be useful to its intended users and will fulfill their requirements.
OOAD allows a detailed model of the system to be developed, based on the documentation of the users' requirements.
The model provides abstraction from the underlying complexity of the system and allows the system to be viewed as a whole.
It also provides a way for users, analysts, designers, and implementers to study different, but compatible, aspects of the system.
As OOAD takes place, different views of a system should be abstracted to form a model of the system as a whole.
Once this is done, it is easier for developers to see how the components of the system should interact and users can verify that their requirements are met.
Then detail can be added to transform the model into one that can be used for implementation.
Frequently during early analysis and design, different solutions to the problem are modeled and the results are compared to find the best system.
OOAD divides into two phases - object-oriented analysis (OOA) and object-oriented design (OOD).
OOA involves creating a model of a system based on what the users require from that system.
OOD adds detail and design decisions to the model.
The analysis phase takes a "black box" approach to the system, ignoring its inner workings.
The design phase takes a "white box" approach and makes decisions on how the model will be implemented in code.
So analysis takes place from a user's perspective and design takes place from a developer's perspective.
During analysis, a concise, accurate model of what the desired system should do is created.
This model should not consider how the system will perform its functions.
Analysis focuses on abstracting from the problem domain - that is, the real world that the system will function in.
This is done to discover the primary classes and objects in the system.
The objects in the analysis model should be problem domain concepts only - they should not be implementation concepts.
During analysis, the environment the system will be implemented in should not be considered.
However, at the design stage it must be ascertained whether the analysis model will work in the intended implementation environment.
During design, the analysis model is expanded into a technical blueprint for implementing a system.
New classes are added to provide the mechanisms that enable the system to work - for example, mechanisms to handle persistence or interprocess communication.
And the classes discovered during analysis are fleshed out to take account of the implementation environment.
In practice, many portions of the analysis model may be implemented without change, so there is often overlap between analysis and design.
Analysis is some times refined during design, or after key design decisions are made.
Quite often, analysis and design are parallel activities on a large project, so it is difficult to draw a line between where analysis ends and design starts.
At the end of the OOAD process, the analysis and design models combine to provide an overview of the system.
This overview can be used throughout the development process.
During the OOAD process, it is important to be aware of the goals of the software system being developed.
The main goal of a successful software system is that the user should be able to use it effectively.
Other goals of successful systems are that
• it should be easily maintainable
• it should be scalable
• it should be portable between platforms
• its code should be reusable
It is important for the success of a project that its result is delivered in time and within budget.
There are several tactics that facilitate the development of a successful software system that can be taken into account during analysis and design.
The system should be split into modules based on logical functionality.
The modules should be separately compilable so that if changes need to be made to one of them, the whole system won't be affected.
The modules should communicate with each other through small, well-defined interfaces, which act as wrappers to hide the implementation.
And there should be as few of these interfaces as possible.
The use of interfaces allows modules to be very portable, and standard interfaces such as COM interfaces can be used to further increase portability.
Models are usually represented visually by some type of notation.
The notation often takes the form of graphical symbols and connections.
A graphical notation facilitates portraying the structure of a complex system.
It also provides consistency throughout the development process, as models produced using it are standard and are retained for the lifetime of the project.
This means they can be read and understood by everyone involved with the project.
A good notation should allow an accurate description of the system it represents.
It should be as simple as possible, without being oversimplified.
And it should be easy to update and to communicate to others.
The Unified Modeling Language (UML) is a robust notation that you can use to build OOAD models.
It consists of a series of diagrams that represent the different views of a software system in analysis and design.
For example, there are diagrams to chart the interaction between a user and the application.
When you attempt to develop a system, it is not enough to have a notation for modeling - you also need to know how to use the notation.
This means you need a process to guide you through a software development project and through using the notation.
The combination of a notation and a process is known as a method.
Analysis of all but the smallest systems will generate a large number of diagrams, so it is important to record these accurately to ensure consistency in the model.
In order to record the diagrams that you create using a process and notation, you need a tool.
The Rational Software Corporation has devised the Rational Objectory Process to guide developers through a software project.
And it has created a tool called Rational Rose for creating UML diagrams.
The UML has its origins in several competing OOAD methods that were developed separately in the late 1980s and early 1990s in response to the software crisis.
One of the main methods was the Object Modeling Technique (OMT), which was devised by James Rumbaugh and others at General Electric.
It consists of a series of models - use case, object, dynamic, and functional - that combine to give a full view of a system.
The Booch method was devised by Grady Booch and developed the practice of analyzing a system as a series of views.
It emphasizes analyzing the system from both a macro development view and micro development view.
And it was accompanied by a very detailed notation.
The Object-Oriented Software Engineering (OOSE) method was devised by Ivar Jacobson and focused on the analysis of system behavior.
It advocated that at each stage of the process there should be a check to see that the requirements of the user were being met.
Each of these methods had their strong points and their weak points.
Each had their own notation and their own tool.
This made it very difficult for developers to choose the method and notation that suited them and to use it successfully.
This period is often referred to as the time of the "method wars".
New versions of some of the methods were created, each drawing on strengths of the others to augment their weaker aspects.
This led to a growing similarity between the methods.
In 1994 Rumbaugh joined Booch at Rational Software Corporation in order to create a new method.
It was called the Unified Method and its aim was to unite the Booch and OMT methods.
In 1995 Booch and Rumbaugh were joined by Jacobson and the emphasis on the project changed.
It became clear that the focus of their work was on creating a single, standard notation rather than a method, so they renamed their work the Unified Modeling Language.
In January 1997 version 1.0 of the UML was released.
And in September 1997 the Object Management Group (OMG) accepted the notation as a formal standard.
Although main parts of the UML are based on the Booch, OMT, and OOSE methods, the UML also includes elements from other methods.
For example, state charts, devised by David Harrel, have been incorporated into UML state diagrams, and the work of Erich Gamma and his colleagues on patterns has influenced the UML.
The UML is an attempt to standardize the notation used for analysis and design.
The standardization includes diagrams, syntactic notation, and semantic models.
The aims of the UML that its designers have set are
• to model systems using object-oriented concepts
• to accurately describe conceptual and executable artifacts
• to support both small-scale and large-scale analysis and design
• to provide a notation that can be used by both people and machines
The UML is an object-oriented modeling language and its diagrams and semantics are based on object-oriented concepts.
It is designed to describe many types of system in object-oriented terms.
However, the UML is not limited to modeling object-oriented systems.
An example of the type of system the UML can model is an information system based on large databases.
These databases store data in complex relationships and make large amounts of data available to users.
The UML can model both relational and object databases.
Object-oriented technology facilitates the implementation of embedded and real-time systems.
And it facilitates the development of systems that are distributed across a number of machines and require synchronized communication mechanisms.
The UML can be used to model both of these types of system.
The UML can be used to model system software such as operating systems and networking systems.
And it can be used to model technical systems that control equipment such as industrial machines, military hardware, or telecommunications systems.
In addition to software systems, the UML can be used to model business processes, such as the flow of work within and between departments in a company.
The UML is composed of three different parts:
• model elements
• diagrams
• views
The model elements represent basic object-oriented concepts such as classes, objects, and relationships.
Each model element has a corresponding graphical symbol to represent it in the diagrams.
For example, the symbol for a class is shown here.
Model elements are defined semantically in formal statements describing what they are or what they represent.
Each model element can be used in several different diagrams but it always retains the same symbol and meaning.
And there are rules governing the diagrams that each model element can appear in.
Diagrams portray different combinations of model elements.
For example, the class diagram represents a group of classes and the relationships, such as association and inheritance, between them.
The UML provides nine types of diagram - use case, class, object, state, sequence, collaboration, activity, component, and deployment.
Views provide the highest level of abstraction for analyzing the system.
Each view is an aspect of the system that is abstracted to a number of related UML diagrams.
Taken together, the views of a system provide a picture of the system in its entirety.
In the UML, the five main views of the system are
• use case
• logical
• component
• concurrency
• deployment
It is necessary to break the model of a system down into several views with related diagrams.
This is because it would be impossible for one diagram to represent an entire system accurately and clearly.
In addition to model elements, diagrams, and views, the UML provides mechanisms for adding comments, information, or semantics to diagrams.
And it provides mechanisms to adapt or extend itself to a particular method, software system, or organization.
OOAD focuses on analyzing the requirements of a system and designing a model of the system before any code is developed.
OOAD is done to ensure that the purpose and requirements of a system are thoroughly captured and documented before the system is built.
Although it sounds obvious, it is very important that the proposed system will be useful to its intended users and will fulfill their requirements.
OOAD allows a detailed model of the system to be developed, based on the documentation of the users' requirements.
The model provides abstraction from the underlying complexity of the system and allows the system to be viewed as a whole.
It also provides a way for users, analysts, designers, and implementers to study different, but compatible, aspects of the system.
As OOAD takes place, different views of a system should be abstracted to form a model of the system as a whole.
Once this is done, it is easier for developers to see how the components of the system should interact and users can verify that their requirements are met.
Then detail can be added to transform the model into one that can be used for implementation.
Frequently during early analysis and design, different solutions to the problem are modeled and the results are compared to find the best system.
OOAD divides into two phases - object-oriented analysis (OOA) and object-oriented design (OOD).
OOA involves creating a model of a system based on what the users require from that system.
OOD adds detail and design decisions to the model.
The analysis phase takes a "black box" approach to the system, ignoring its inner workings.
The design phase takes a "white box" approach and makes decisions on how the model will be implemented in code.
So analysis takes place from a user's perspective and design takes place from a developer's perspective.
During analysis, a concise, accurate model of what the desired system should do is created.
This model should not consider how the system will perform its functions.
Analysis focuses on abstracting from the problem domain - that is, the real world that the system will function in.
This is done to discover the primary classes and objects in the system.
The objects in the analysis model should be problem domain concepts only - they should not be implementation concepts.
During analysis, the environment the system will be implemented in should not be considered.
However, at the design stage it must be ascertained whether the analysis model will work in the intended implementation environment.
During design, the analysis model is expanded into a technical blueprint for implementing a system.
New classes are added to provide the mechanisms that enable the system to work - for example, mechanisms to handle persistence or interprocess communication.
And the classes discovered during analysis are fleshed out to take account of the implementation environment.
In practice, many portions of the analysis model may be implemented without change, so there is often overlap between analysis and design.
Analysis is some times refined during design, or after key design decisions are made.
Quite often, analysis and design are parallel activities on a large project, so it is difficult to draw a line between where analysis ends and design starts.
At the end of the OOAD process, the analysis and design models combine to provide an overview of the system.
This overview can be used throughout the development process.
During the OOAD process, it is important to be aware of the goals of the software system being developed.
The main goal of a successful software system is that the user should be able to use it effectively.
Other goals of successful systems are that
• it should be easily maintainable
• it should be scalable
• it should be portable between platforms
• its code should be reusable
It is important for the success of a project that its result is delivered in time and within budget.
There are several tactics that facilitate the development of a successful software system that can be taken into account during analysis and design.
The system should be split into modules based on logical functionality.
The modules should be separately compilable so that if changes need to be made to one of them, the whole system won't be affected.
The modules should communicate with each other through small, well-defined interfaces, which act as wrappers to hide the implementation.
And there should be as few of these interfaces as possible.
The use of interfaces allows modules to be very portable, and standard interfaces such as COM interfaces can be used to further increase portability.
Models are usually represented visually by some type of notation.
The notation often takes the form of graphical symbols and connections.
A graphical notation facilitates portraying the structure of a complex system.
It also provides consistency throughout the development process, as models produced using it are standard and are retained for the lifetime of the project.
This means they can be read and understood by everyone involved with the project.
A good notation should allow an accurate description of the system it represents.
It should be as simple as possible, without being oversimplified.
And it should be easy to update and to communicate to others.
The Unified Modeling Language (UML) is a robust notation that you can use to build OOAD models.
It consists of a series of diagrams that represent the different views of a software system in analysis and design.
For example, there are diagrams to chart the interaction between a user and the application.
When you attempt to develop a system, it is not enough to have a notation for modeling - you also need to know how to use the notation.
This means you need a process to guide you through a software development project and through using the notation.
The combination of a notation and a process is known as a method.
Analysis of all but the smallest systems will generate a large number of diagrams, so it is important to record these accurately to ensure consistency in the model.
In order to record the diagrams that you create using a process and notation, you need a tool.
The Rational Software Corporation has devised the Rational Objectory Process to guide developers through a software project.
And it has created a tool called Rational Rose for creating UML diagrams.
The UML has its origins in several competing OOAD methods that were developed separately in the late 1980s and early 1990s in response to the software crisis.
One of the main methods was the Object Modeling Technique (OMT), which was devised by James Rumbaugh and others at General Electric.
It consists of a series of models - use case, object, dynamic, and functional - that combine to give a full view of a system.
The Booch method was devised by Grady Booch and developed the practice of analyzing a system as a series of views.
It emphasizes analyzing the system from both a macro development view and micro development view.
And it was accompanied by a very detailed notation.
The Object-Oriented Software Engineering (OOSE) method was devised by Ivar Jacobson and focused on the analysis of system behavior.
It advocated that at each stage of the process there should be a check to see that the requirements of the user were being met.
Each of these methods had their strong points and their weak points.
Each had their own notation and their own tool.
This made it very difficult for developers to choose the method and notation that suited them and to use it successfully.
This period is often referred to as the time of the "method wars".
New versions of some of the methods were created, each drawing on strengths of the others to augment their weaker aspects.
This led to a growing similarity between the methods.
In 1994 Rumbaugh joined Booch at Rational Software Corporation in order to create a new method.
It was called the Unified Method and its aim was to unite the Booch and OMT methods.
In 1995 Booch and Rumbaugh were joined by Jacobson and the emphasis on the project changed.
It became clear that the focus of their work was on creating a single, standard notation rather than a method, so they renamed their work the Unified Modeling Language.
In January 1997 version 1.0 of the UML was released.
And in September 1997 the Object Management Group (OMG) accepted the notation as a formal standard.
Although main parts of the UML are based on the Booch, OMT, and OOSE methods, the UML also includes elements from other methods.
For example, state charts, devised by David Harrel, have been incorporated into UML state diagrams, and the work of Erich Gamma and his colleagues on patterns has influenced the UML.
The UML is an attempt to standardize the notation used for analysis and design.
The standardization includes diagrams, syntactic notation, and semantic models.
The aims of the UML that its designers have set are
• to model systems using object-oriented concepts
• to accurately describe conceptual and executable artifacts
• to support both small-scale and large-scale analysis and design
• to provide a notation that can be used by both people and machines
The UML is an object-oriented modeling language and its diagrams and semantics are based on object-oriented concepts.
It is designed to describe many types of system in object-oriented terms.
However, the UML is not limited to modeling object-oriented systems.
An example of the type of system the UML can model is an information system based on large databases.
These databases store data in complex relationships and make large amounts of data available to users.
The UML can model both relational and object databases.
Object-oriented technology facilitates the implementation of embedded and real-time systems.
And it facilitates the development of systems that are distributed across a number of machines and require synchronized communication mechanisms.
The UML can be used to model both of these types of system.
The UML can be used to model system software such as operating systems and networking systems.
And it can be used to model technical systems that control equipment such as industrial machines, military hardware, or telecommunications systems.
In addition to software systems, the UML can be used to model business processes, such as the flow of work within and between departments in a company.
The UML is composed of three different parts:
• model elements
• diagrams
• views
The model elements represent basic object-oriented concepts such as classes, objects, and relationships.
Each model element has a corresponding graphical symbol to represent it in the diagrams.
For example, the symbol for a class is shown here.
Model elements are defined semantically in formal statements describing what they are or what they represent.
Each model element can be used in several different diagrams but it always retains the same symbol and meaning.
And there are rules governing the diagrams that each model element can appear in.
Diagrams portray different combinations of model elements.
For example, the class diagram represents a group of classes and the relationships, such as association and inheritance, between them.
The UML provides nine types of diagram - use case, class, object, state, sequence, collaboration, activity, component, and deployment.
Views provide the highest level of abstraction for analyzing the system.
Each view is an aspect of the system that is abstracted to a number of related UML diagrams.
Taken together, the views of a system provide a picture of the system in its entirety.
In the UML, the five main views of the system are
• use case
• logical
• component
• concurrency
• deployment
It is necessary to break the model of a system down into several views with related diagrams.
This is because it would be impossible for one diagram to represent an entire system accurately and clearly.
In addition to model elements, diagrams, and views, the UML provides mechanisms for adding comments, information, or semantics to diagrams.
And it provides mechanisms to adapt or extend itself to a particular method, software system, or organization.
Wednesday, September 20, 2006
Java Garbage Collector
The Java garbage collector is a daemon thread – a thread that runs for the benefit of other threads. It is a mark-sweep facility that scans Java's dynamic memory areas for objects, marking those that are referenced. When Java determines that there are no longer any references to an object, it marks the object for eventual garbage collection. The "mark and sweep" garbage collection algorithm is not suitable for all applications. The new version of Java has been expanded to contain several new garbage collection algorithms. These include the "copying collector", the "parallel copying collector" and the "parallel scavenge collector". All these new algorithms stop all application threads until the garbage collection is complete.
Java's automatic garbage collector eliminates many of the memory leaks that can occur in C and C++. It runs as a low-priority thread, waiting for higher-priority threads to relinquish the processor. You can use a finalize method in a class to help return resources to the system. The finalize method runs automatically when the system runs out of memory or when runtime ends, but you can also invoke it at other times using the System.runFinalization method.
Final Methods and Performance
When compiling code, each method call to a final method can be replaced by the actual method code. This is known as inlining. Inlining can potentially speed up program execution as final methods are inlined at compile time. A final method can be optimized in this way because the compiler knows it will not have to look up the correct version of the method at runtime, as polymorphism does not exist for final methods.
The latest virtual machines, however, can detect whether or not a non-final method is overridden. So declaring methods final to improve performance is no longer as valid as it once was.
The latest virtual machines, however, can detect whether or not a non-final method is overridden. So declaring methods final to improve performance is no longer as valid as it once was.
Final but not Static Variables
Declaring variables as final but not static and not assigning it any initial value allows different constant values for each instance of the class to be assigned in the constructor.
A final variable that refers to an object always refers to the same object. However, values within the object to which it points may change. Similarly, a final variable that refers to an array always refers to the same array, even though elements in that array can change.
A final variable that refers to an object always refers to the same object. However, values within the object to which it points may change. Similarly, a final variable that refers to an array always refers to the same array, even though elements in that array can change.
Parameters as Final
You can declare parameters as final. Declaring parameters as final does not affect method overriding.
For example, method1(final int x, final int y) means the parameters x and y are constant throughout the method.
Final parameters have no impact on variables passed to methods. Because arguments are passed by value, changing them in a method would not have affected the original values in any case. But final arguments cannot be changed within the method.
For example, method1(final int x, final int y) means the parameters x and y are constant throughout the method.
Final parameters have no impact on variables passed to methods. Because arguments are passed by value, changing them in a method would not have affected the original values in any case. But final arguments cannot be changed within the method.
Static Initialization Block
You cannot initialize class variables using a constructor. A useful way of initializing class variables is to use a static initialization block. It saves memory because only one copy of the static initialization block is store for all instances of the class.
A static initialization block begins with the static keyword and is encapsulated in braces. Here is an example,
A static initialization block begins with the static keyword and is encapsulated in braces. Here is an example,
static {
try {
charsInFile = 0;
FileReader in = new FileReader("TestStaticBlock.java");
while(in.read() != -1) {
charsInFile++;
}
} catch (Exception e){
}
System.out.println("Finished static initialization block: " + charsInFile);
}
Methods in Interfaces
You do not have to declare methods in interfaces with an abstract keyword, since interface methods are implicitly abstract.
Methods declared in interfaces body are all implicitly public, and can be accessed outside the package in which the interface is declared as long as the interface itself is public or protected. An interface can be declared private or protected only if it occurs within a class.
Methods declared in interfaces body are all implicitly public, and can be accessed outside the package in which the interface is declared as long as the interface itself is public or protected. An interface can be declared private or protected only if it occurs within a class.
Implications of Inheritance
In a subclass, you can create a new variable with the same name as an inherited variable, same type or class is not necessary. The subclass uses this variable instead of the inherited variable. This is known as hiding a variable.
Generally, you only need to hide superclass variables in rare situations where the generic class was not well defined, such as when maintaining someone else's code. Variable hiding is not recommended, as it can lead to confusing and ambiguous code.
Java makes a copy of each inherited superclass variable available to each object in a subclass, even if the variable is hidden. To access a specific data member within an inheritance hierarchy, you sometimes need to perform an explicit cast.
Overloading a method is often confused with overriding a method. Overloading is to create methods with the same name as an existing method, but with different arguments. Overloading can happen within a same class or subclasses.
Constructors are not automatically inherited, so subclasses do not automatically receive any constructor implementation code from their superclass, such as initialization code for variables. Java ensures that an object is constructed in the correct order, from its base to its subclass. This is called constructor chaining. If you do not explicitly call a constructor of a superclass, Java automatically calls the no-argument superclass constructor. If the superclass has no such constructor, the class will not compile.
Generally, you only need to hide superclass variables in rare situations where the generic class was not well defined, such as when maintaining someone else's code. Variable hiding is not recommended, as it can lead to confusing and ambiguous code.
Java makes a copy of each inherited superclass variable available to each object in a subclass, even if the variable is hidden. To access a specific data member within an inheritance hierarchy, you sometimes need to perform an explicit cast.
Overloading a method is often confused with overriding a method. Overloading is to create methods with the same name as an existing method, but with different arguments. Overloading can happen within a same class or subclasses.
Constructors are not automatically inherited, so subclasses do not automatically receive any constructor implementation code from their superclass, such as initialization code for variables. Java ensures that an object is constructed in the correct order, from its base to its subclass. This is called constructor chaining. If you do not explicitly call a constructor of a superclass, Java automatically calls the no-argument superclass constructor. If the superclass has no such constructor, the class will not compile.
Late Binding vs Early Binding
Often, an object type cannot be determined at compile time and must be dynamically resolved at runtime. This runtime resolution of object types is called late binding of instance methods and makes polymorphism possible in Java.
Late binding enables Java to choose the right version of a called method at runtime, depending on the type of object that is created.
The opposite of late binding is early binding. In early binding, variables and methods are resolved at compile time. Early binding doesn't support polymorphism, and is used in non-OO languages.
Late binding enables Java to choose the right version of a called method at runtime, depending on the type of object that is created.
The opposite of late binding is early binding. In early binding, variables and methods are resolved at compile time. Early binding doesn't support polymorphism, and is used in non-OO languages.
UML - Introduction
UML stands for Unified Modeling Language, which is a family of graphical notations, backed by single meta-model, the help in describing and designing software systems, particularly software systems build using the object oriented style.
A picture says a thousand words. That's why UML comes to the area of OOAD. Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. Graphical modeling languages have been around in the software industry for a long time. The fundamental driver behind them all is that programming languages are not at a high enough level of abstraction to facilitate discussions about design. Despite the fact that graphical modeling languages have been around for a long time, there is an enormous amount of dispute in the software industry about their role. The disputes play directly into how people perceive the role of the UML itself.
So the Object Management Group(OMG) was formed to build UML standards. OMG is also known for the CORBA(Common Object Request Broker Architecture) standards. The earlist UML was version 0.8 released in Oct. 1995. In 1996, version 0.9 and 0.91 and offically UML received its name. In Jan. 1997, version 1.0 submitted, Sep. 1997, version 1.1 submitted, but only adopted by OMG toward the end of 1997. UML 1.2 appeared in 1998, 1.3 in 1999, 1.4 in 2001, 1.5 in 2002.
As the UML 1 series continued, the developers of the UML set their sights on a major revision to the UML with UML 2. The first request for proposals were issued in 2000, but UML 2 didn't start to stabilize until 2003. In Oct. 2004, UML 2.0 was adopted. Now, version 2.1 is the most current.
There are total 13 types of diagrams in UML 2,
On the other side, although the UML provides quite a considerable body of various diagrams that help to define an application, it's by no means a complete list of all the useful diagrams that you might want to use. In many places, different diagrams can be useful, and you shouldn't hesitate to use a non-UML diagram if no UML diagram suits your purpose.
A picture says a thousand words. That's why UML comes to the area of OOAD. Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. Graphical modeling languages have been around in the software industry for a long time. The fundamental driver behind them all is that programming languages are not at a high enough level of abstraction to facilitate discussions about design. Despite the fact that graphical modeling languages have been around for a long time, there is an enormous amount of dispute in the software industry about their role. The disputes play directly into how people perceive the role of the UML itself.
So the Object Management Group(OMG) was formed to build UML standards. OMG is also known for the CORBA(Common Object Request Broker Architecture) standards. The earlist UML was version 0.8 released in Oct. 1995. In 1996, version 0.9 and 0.91 and offically UML received its name. In Jan. 1997, version 1.0 submitted, Sep. 1997, version 1.1 submitted, but only adopted by OMG toward the end of 1997. UML 1.2 appeared in 1998, 1.3 in 1999, 1.4 in 2001, 1.5 in 2002.
As the UML 1 series continued, the developers of the UML set their sights on a major revision to the UML with UML 2. The first request for proposals were issued in 2000, but UML 2 didn't start to stabilize until 2003. In Oct. 2004, UML 2.0 was adopted. Now, version 2.1 is the most current.
There are total 13 types of diagrams in UML 2,
- Activity - procedural and parallel behavior
- Class - Class, features, and relationships
- Communication - Interaction between objects, emphasis on links
- Component - structure and connections of components
- Composite structure - runtime decomposition of a class (since UML 2)
- Deployment - deployment of artifacts to nodes
- Interaction overview - mix of sequence and activity (since UML 2)
- Object - example configurations of instances (unofficially in UML 1)
- Package - compile-time hierarchic structure (unofficially in UML 1)
- Sequence - Interaction between objects, emphasis on sequence
- State machine - how events change an object over its life
- Timing - interaction between objects, emphasis on timing (since UML 2)
- Use case - how users interact with a system
On the other side, although the UML provides quite a considerable body of various diagrams that help to define an application, it's by no means a complete list of all the useful diagrams that you might want to use. In many places, different diagrams can be useful, and you shouldn't hesitate to use a non-UML diagram if no UML diagram suits your purpose.
OOAD - Introduction
OOAD, which stands for Object Oriented Analysis and Design, is just one chain in the process of software/application development. Every software or application has to response to user's requirements. Usually, architects analyze these requirements and design a solution, then developers implement the solution with a programming language, then quality assurance staff test the implementation and finally training facilities turn the key to end users.
Object Oriented(OO) is just one of the methodologies that architects choose. It is popular now, but before it, there have been many other methodologies, e.g. Function Oriented, and they are actually successful and still useful especially when OO programming language is not available or suitable in certain situations. However, OO does have some advantages over others. Code reuse is one of the major advantages. For detail, please google "Object Oriented" and "advantage".
Analysis is the interface between architects and end users, customers and business analysts (shortly as users). A description of the problem or requirements must be created before anything can happen. Requirements are actually the responsibility of users, however, since most users are not trained with software engineering, starting here architects need to take some leadership (see, there IS a reason why you need to be a leader to be hired as an architect. ^_^) and gather stories from users and create documents to describe and code all requirements. And that defines what the problem is about and what a software or application must do. Analysis emphasizes an investigation of the problem rather than how a solution is defined. For example, if a card game which players lead 4 cards to a result of 24 by using +-x/ is desired, what are the business(or game) processes related to its use?
To develop an application, it is also necessary to have high level and detailed descriptions of the logical solution and how it fulfills requirements and constraints. Design emphasizes a logical solution, how the system fulfills the requirements. To illustrate, how exactly will a library system capture and record over-due loans?
After all, the investigation on business processes is called requirements analysis, investigation on user roles is called domain analysis, investigation on responsibilities and interactions is called responsibility and interaction design. Besides, OOAD emphasizes decomposing a problem space by objects rather than by functions, systems and sub-systems.
Object Oriented(OO) is just one of the methodologies that architects choose. It is popular now, but before it, there have been many other methodologies, e.g. Function Oriented, and they are actually successful and still useful especially when OO programming language is not available or suitable in certain situations. However, OO does have some advantages over others. Code reuse is one of the major advantages. For detail, please google "Object Oriented" and "advantage".
Analysis is the interface between architects and end users, customers and business analysts (shortly as users). A description of the problem or requirements must be created before anything can happen. Requirements are actually the responsibility of users, however, since most users are not trained with software engineering, starting here architects need to take some leadership (see, there IS a reason why you need to be a leader to be hired as an architect. ^_^) and gather stories from users and create documents to describe and code all requirements. And that defines what the problem is about and what a software or application must do. Analysis emphasizes an investigation of the problem rather than how a solution is defined. For example, if a card game which players lead 4 cards to a result of 24 by using +-x/ is desired, what are the business(or game) processes related to its use?
To develop an application, it is also necessary to have high level and detailed descriptions of the logical solution and how it fulfills requirements and constraints. Design emphasizes a logical solution, how the system fulfills the requirements. To illustrate, how exactly will a library system capture and record over-due loans?
After all, the investigation on business processes is called requirements analysis, investigation on user roles is called domain analysis, investigation on responsibilities and interactions is called responsibility and interaction design. Besides, OOAD emphasizes decomposing a problem space by objects rather than by functions, systems and sub-systems.
Monday, September 18, 2006
Abstract Class or Interface
Developers are often confused with the choice of abstract class or interface. In design patterns, for example, factory method and abstract factory, abstract classes are used sometimes and interfaces other times.
What is exactly the difference between abstract class and interface? One simple idea is the relationship. Abstract class hints a "is-a" relationship and interface a "is" . For example, a Dog is an animal, and a Dog is priceable, which means it can have a price and participate in a market.
What is exactly the difference between abstract class and interface? One simple idea is the relationship. Abstract class hints a "is-a" relationship and interface a "is" . For example, a Dog is an animal, and a Dog is priceable, which means it can have a price and participate in a market.
Most introductory Java texts take an implementation-centric stab at how to use interfaces and abstract classes. However, few provide a clear design distinction for choosing between these two similar object-oriented constructs. This article investigates such a distinction through a discussion of a simple, yet common, example. The resulting design uses both interfaces and abstract classes to maximize flexibility and extendibility.Please read the Maximize flexibility with interfaces and abstract classes for deep understanding of their differences.
Polymorphism in Java
In simple terms, polymorphism lets you treat derived class members just like their parent class's members.
In more precise terms, polymorphism (object-oriented programming theory) is the ability of objects belonging to different types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behaviour. The programmer (and the program) does not have to know the exact type of the object in advance, so this behavior can be implemented at run time (this is called late binding or dynamic binding).
In more precise terms, polymorphism (object-oriented programming theory) is the ability of objects belonging to different types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behaviour. The programmer (and the program) does not have to know the exact type of the object in advance, so this behavior can be implemented at run time (this is called late binding or dynamic binding).
Java developers all too often associate the term polymorphism with an object's ability to magically execute correct method behavior at appropriate points in a program. That behavior is usually associated with overriding inherited class method implementations. However, a careful examination of polymorphism demystifies the magic and reveals that polymorphic behavior is best understood in terms of type, rather than as dependent on overriding implementation inheritance. That understanding allows developers to fully take advantage of polymorphism.Please read the Reveal the magic behind subtype polymorphism for a deep understanding of polymorphism.
Disable Directory Listing in Tomcat 5
For fresh Tomcat installations, directory listing is enabled by default. This can be a very useful debugging tool, and if, like me, you sometimes forget what servlets are deployed in a certain web application, you can get a complete listing by simply keying in the web application's URL.
But for production deployments, you may want to turn it off. If nothing else, it discourages users from poking around where they should not. There are basically 2 methods of "turning off" this option :
1. Create an index.html file and place it in the web application's directory
2. Edit the global web.xml file to turn off the option.
The first option is fairly simple, so we shall only examine the second option.
Open the file web.xml which is located inside $CATALINA_HOME/conf/. This is the global web.xml file, which means that any changes here will affect ALL web applications deployed by that Tomcat instance. If you want more granular control, like turning it off for certain applications but not for others, you will need to go with the first option of creating index.html files.
Change param-value of listing to false and you turn off directory listing. It is that simple.
But for production deployments, you may want to turn it off. If nothing else, it discourages users from poking around where they should not. There are basically 2 methods of "turning off" this option :
1. Create an index.html file and place it in the web application's directory
2. Edit the global web.xml file to turn off the option.
The first option is fairly simple, so we shall only examine the second option.
Open the file web.xml which is located inside $CATALINA_HOME/conf/. This is the global web.xml file, which means that any changes here will affect ALL web applications deployed by that Tomcat instance. If you want more granular control, like turning it off for certain applications but not for others, you will need to go with the first option of creating index.html files.
Change param-value of listing to false and you turn off directory listing. It is that simple.
Context Descriptor in Tomcat 5
The context descriptor file, according to the Tomcat official documentation, is "used to define Tomcat specific configuration options, such as loggers, data sources, session manager configuration and more".
The file follows an XML syntax, and the name of the file is always the name of the web application, with a .xml extension. So, for this application, called MyFirst, the name of the context descriptor is MyFirst.xml.
Create a file called MyFirst.xml with the following contents:
Save the file into $CATALINA_HOME/conf/Catalina/localhost/ directory.
With much older versions of Tomcat, such as the early Tomcat 3.x series or 4.0.x series, you had to add the context definitions inside server.xml. With Tomcat 5.x, the context descriptor provides a cleaner separation of web application configuration and the main Tomcat server configuration. An added benefit is that web applications deployed in this way do not require a stop and restart of the Tomcat server process. Tomcat should automatically pick it up while it is still running.
One of the things I really enjoy about Open Source software is that you can sometimes get useful insights from people smarter and more experienced than yourself. I had an interesting discussion with Josh Rehman on the relative merits of deploying web applications using the server.xml method or using the context descriptor method.
Josh's position is that the context descriptor method should become the canonical method for web application deployment for many reasons: the unreliability of server.xml edits propagating through the server, and the difficulty of removing those contexts that are already deployed.
I had not considered that position before, probably because I do not run Tomcat in a high volume, mission-critical environment. Things are different in the little corner of Asia where I stay and work. The traffic is much lower and you can pretty much reboot the server anytime you wish. So bringing down the Tomcat server process to add, modify or delete a context is feasible.
If, however, you have responsibilities for a large deployment of Tomcat servers, or just a Tomcat server running in a high volume environment, the game changes fundamentally. You will need something that allows for "on-the-fly" changes, and more importantly, you need a clear separation between server configuration parameters shared by all applications, and configurations for each individual web application. Although there are merits in keeping all configuration in one place, when you are pressed for time, you don't want to wade through an ultra-long configuration file to get at the parts you want to change or delete. I learned that painful lesson when adding a CD-RW drive to a running web server recently.
The file follows an XML syntax, and the name of the file is always the name of the web application, with a .xml extension. So, for this application, called MyFirst, the name of the context descriptor is MyFirst.xml.
Create a file called MyFirst.xml with the following contents:
<Context path="/MyFirst" docBase="MyFirst" debug="0" reloadable="true"/>
Save the file into $CATALINA_HOME/conf/Catalina/localhost/ directory.
With much older versions of Tomcat, such as the early Tomcat 3.x series or 4.0.x series, you had to add the context definitions inside server.xml. With Tomcat 5.x, the context descriptor provides a cleaner separation of web application configuration and the main Tomcat server configuration. An added benefit is that web applications deployed in this way do not require a stop and restart of the Tomcat server process. Tomcat should automatically pick it up while it is still running.
One of the things I really enjoy about Open Source software is that you can sometimes get useful insights from people smarter and more experienced than yourself. I had an interesting discussion with Josh Rehman on the relative merits of deploying web applications using the server.xml method or using the context descriptor method.
Josh's position is that the context descriptor method should become the canonical method for web application deployment for many reasons: the unreliability of server.xml edits propagating through the server, and the difficulty of removing those contexts that are already deployed.
I had not considered that position before, probably because I do not run Tomcat in a high volume, mission-critical environment. Things are different in the little corner of Asia where I stay and work. The traffic is much lower and you can pretty much reboot the server anytime you wish. So bringing down the Tomcat server process to add, modify or delete a context is feasible.
If, however, you have responsibilities for a large deployment of Tomcat servers, or just a Tomcat server running in a high volume environment, the game changes fundamentally. You will need something that allows for "on-the-fly" changes, and more importantly, you need a clear separation between server configuration parameters shared by all applications, and configurations for each individual web application. Although there are merits in keeping all configuration in one place, when you are pressed for time, you don't want to wade through an ultra-long configuration file to get at the parts you want to change or delete. I learned that painful lesson when adding a CD-RW drive to a running web server recently.
Subscribe to:
Posts (Atom)