Sunday, October 26, 2008

Section 2.1: UML for Classes, Inheritance, and Memebr Visibilty

Requirement: Recognize the UML representation of classes, (including attributes and operations, abstract classes, and interfaces), the UML representation of inheritance (both implementation and interface), and the UML representation of class member visibility modifiers (-/private and +/public).


(Almost all of this section is just a refinement of the free hfoo-associateuml.pdf pdf file. Unfortunately the link to the pdf is currently broken so I won't be able to give it to you. I will upload the pdf later and provide the link in a downloads section on the blog.)


UML for Classes and Objects:

(2.1.1) A class is drawn as a rectangle with 3 sections:
  1. The 1st section contains the name of the class written in bold.
  2. The 2nd section contians the atrributes (member fields) written as attributeName : AttributeType (ex: title : String).
  3. The 3rd section contains the operations (methods) written as operationName(OperationArgumentTypes) : ReturnType (ex: search(String) : boolean).

(2.1.2) An object is drawn as a rectangle with 2 sections:

  1. The 1st section contains the name of the object as well as its type written as objName : ObjType (ex: hfJava : Book). Note the underlining.
  2. The 2nd section lists the member field names as well as their current values written as attributeName = CurrentValue (ex: title = "HF Java").

(2.1.3) It is less common to use object diagrams but they can be useful for describing specific examples or complex relationships between objects. (2.1.4) In object diagrams, we don't bother listing object operations since all objects of a particular class have the same set of operations so it would be redundant to list the operations for every single object. (2.1.5) Any thing in a UML diagram that is abstract is written in italics (ex: when drawing an abstract class digram we write ClassName in the 1st section of the diagram instead ClassName) (ex: when listing an abstract operation in a particular class or interface we write operationName instead of operationName). (2.1.6) Interfaces are represented just like classes with only one difference which is: we write <> in italics above the name of the interface and of course we write the name of the interface in italics.


UML for Inheritance:

(2.1.7) In UML inheritance is refered to as generalization. (2.1.8) Generalization is reperesented be an open rectangle that points from the subclass to the superclass. (2.1.9) It's also valid to use a single triangle with multiple lines connected to it when connecting many subclasses with the same superclass. (2.1.10) A class that impelements an interface is conneced to that interface by a dashed line with an open triangle pointing to the interface at the end of the dashed line. (2.1.11) When a class implements multiple interfaces, the lollipop notation is used to make drawing the UML diagram more managable. (2.1.12) In lollipop notation the interface is represented by a small circle attached to the class by a solid line. (2.1.13) In lollipop notation we don't list the operations of the implemented interfaces.


UML for Member Visibility:

(2.1.14) To represent a private member field or operation, you preceed the name of the field with the - indicator (ex: - title : String). (2.1.15) To represent a public member field or operation, you preceed the name of the field with the + indicator (ex: + search(String) : boolean).


(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

Chapter 2: UML Representation of Object-Oriented Concepts

We have finally reached our second station in the journey through the Java world. This chapter will talk mainly about the UML reperesentation of various OO concepts. To start, we will look at the basic points covered in this part of the SCJA exam.


As mentioned on Sun MicroSystems website this part of the exam covers the following points:
  1. Recognize the UML representation of classes, (including attributes and operations, abstract classes, and interfaces), the UML representation of inheritance (both implementation and interface), and the UML representation of class member visibility modifiers (-/private and +/public).
  2. Recognize the UML representation of class associations, compositions, association multiplicity indicators, and association navigation indicators.

As usual we will detail every point in a separate section of the chapter. So let's go :).

Saturday, October 25, 2008

Section 1.5: Polymorphism

Requirement: Describe polymorphism as it applies to classes and interfaces, and describe and apply the "program to an interface" principle.


Polymorphism:

(1.5.1) Polymorphism is the fact that an object variable can refer to multiple actual types. (1.5.2) The is-a rule states that every object of a subclass is an object of the superclass. (1.5.3) You can assign a subclass reference to a superclass variable (ex: assuming that Employee is the superclass and Manager is the subclass you can write: Employee e = new Manager(...) but you cannot write: Manager m = new Employee(....), all managers are employees but not all employees are managers). (1.5.4) Arrays of subclass references can refer to arrays of superclass references without a cast:

Ex:
Manager[] managers = new Manager[10];
Employee[] staff = managers; //This is OK

But the caution here is that managers and staff are references for the same array. So if you write something like: staff[0] = new Employee(....); the compiler will not indicate any errors. But what you have done actually is that you assigned an Employee object to a Manager reference since managers[0] is the same as staff[0] which is illegal. So if you try to something like that an ArrayStoreException will be caused at run time.


Program to an Interface Principle:
(from the JavaRanch forum)

(1.5.5) Program to an interface means don't tie relationships to classes, instead tie them to interfaces. For example, I have a class C1 which is a parameter for a method M2 in class C2, I code M2 method as M2(C1 c). I cannot use M2 to process any objects from classes other than C1. Instead if an interface I1 is created and which is implemented by C1, I can change the method signature to M2(I1 i) and this will be able to process objects of any class that implements I1 including C1 instead of exclusively processing C1 objects.

Friday, October 24, 2008

Section 1.4: Information Hiding and Encapsulation

Requirement: Describe information hiding (using private attributes and methods), encapsulation, and exposing object functionality using public methods; and describe the JavaBeans conventions for setter and getter methods.


Encapsulation:

(1.4.1) Encapsulation is sometimes called information hiding so they are the same concept. (1.4.2) Encapsulation is nothing more than combining data and behavior in one package and hiding the implementation detials from the user of the object. (1.4.3) The key to making encapsulation work is to have methods never access instance fields in a class other than their own. (1.4.4) Encapsulation is the way to give the object its black box bahvior, which is the key to reliability and reuse. (1.4.5) Benifits of encapsulation:

  1. You can change the internal implementation without affecting any code other than the methods of the class.
  2. Mutator methods (methods that assign values to private instance fields, the setter methods) can perform error-checking, whereas code that simply assigns to a filed may not go to the trouble.

(1.4.6) When creating accessor methods (getter methods) that get the value of a private reference field, never return the reference to the member field directly, instead return a clone of that member object.

Ex:
Assuming that hireDate is a member field of type Date:
Don't write the following code:
public getHireDate() {
reutrn hireDate;
}


In the above code, the returned Date object is the same as the hireDate member field. So any outer code that calls getHireDate can modify the hireDate member field which violates encapsulation.
Instead, write the following code:
public getHireDate() {
reuturn (Date) hireDate.clone();
}



The private Keyword:

(1.4.7) The private keyword makes sure that the only methods that can access the instance fields or methods declared as private are the methods of the class itself. (1.4.8) Instance fields should be explicitly declared private or they will be considered to have the package visibilty which breaks encapsulation. (1.4.9) A method can access the private data of all objects of its class.

Ex:
class Employee {
public equals(Employee other) {
reutrn name.equals(other.name);
}

private String name;
}


(1.4.10) The methods of a subclass cannot access the private fields of its superclass. (1.4.11) Sometimes, you may wish to break up the code for a computation to seprarate helper methods. Typically, these helper methods shouldn't be part of the public interface - they may be too close to the current implementation or require a special protocol or calling order. Such methods are best implemented as private. (1.4.12) Only inner classes can be declared as private, regular classes are either public or have the default package visibilty.


The public Keyword:

(1.4.13) According to the Java Language Specification the main method must be declared as public. (1.4.14) When you override a method, the subclass metohd must be at least as visible as the superclass method. In particlular, if the superclass method is declared as public the subclass method must also be declared as public.


JavaBeans Conventions for Setter and Getter Methods:

(1.4.15) A bean defines an intance field p of type T, the setter and getter methods should have the following convention:

  1. Getter: public T getP()
  2. Boolean getter: public boolean isP()
  3. Setter: public void setP()

p may consist of many words in which case the first letter of each word will be capital except for the first letter of the first word. However, the name of p after the get, set, or is part should be capitalized in the first letter of every word (ex: private String firstName; while public String getFirstName()). (1.4.16) For indexed instance fields (array type instance fields) should follow the following conventions:

  1. Array getter: public T[] getP()
  2. Array element getter: public T getP(int)
  3. Array setter: public void setP(T[])
  4. Array element setter: public void setP(int,T)

(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

Monday, October 20, 2008

Section 1.3: Class Relationships

Requirement: Describe, compare, and contrast class compositions, and associations (including multiplicity: (one-to-one, one-to-many, and many-to-many), and association navigation.


Composition:

We are going to start with a simple example, an instance of Point class may be a part of a polygon or may be the center of a circle, but it cannot be both. (1.3.1) Although a class may be a component of many other classes, any instance of that class must be a component of only one owner (this no sharing rule is the key to composition). (1.3.2) In a composition relationship, data usually flows in only one direction (that is from the whole classifier or owner to the part classifier or the owned) (ex: if you remove the Polygon object, the owned Point objects are also removed).


Association:

(1.3.3) Association is a way to notate a property (ex: you can think of a property as a field in a class). (1.3.4) The name of an association describes the nature of the relationship between 2 classes and should be a name or a verb. (1.3.5) The multiplicity of a property is an indication of how many objects may fill the property. (1.3.6) The most common multiplicities are:
  1. 1 (ex: an order must have exactly one customer).
  2. 0..1 (ex: a customer may or may not have a single sales rep.).
  3. * (ex: a customer need not place an order and there is no upper limit on the number of orders that the customer can place).

(1.3.7) More generally, multiplicities are defined with a lower bound (which may be any positive integer or zero) and an upper bound (which may be any positive integer or *). (1.3.8) There are various terms that refer to multiplicity:

  1. Optional implies a lower bound of 0.
  2. Mandatory implies a lower bound of 1 and possibly more.
  3. Single-Valued implies an upper bound of 1.
  4. Multivalued implies an upper bound of more than 1: usually *.

(1.3.9) The default multiplicity of an attribute is 1.


Association Navigation:

(1.3.10) Associations are either unidirectional or bidirectional. (1.3.11) Unidirectional associations are navigable in only 1 direction (ex: an order has a property called arrivalDate but not vice versa). (1.3.12) A bidirectional association is a pair of properties that are linked together as inverses (ex: the Car class has a property called owner of type Person and the Person class has a property called cars of type Car).

(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

Sunday, October 19, 2008

Section 1.2: Concrete and Abstract Class, and Interfaces

Requirement: Describe, compare, and contrast concrete classes, abstract classes, and interfaces, and how inheritance applies to them.


Classes:

(1.2.1) A class is a template or blueprint from which objects are made. (1.2.2) An object constructed from a particular class is said to be an instance of that class. (1.2.3)* In a single source file you can have multiple classes but exactly one class must be declared as public (see the 1st and 2nd comments for corrections, thanks to Tchulda). (1.2.4) The name of the source file must match the name of the public class declared in that file.


Abstract Classes:

(1.2.5) A class with one or more abstract methods must itself be declared abstract. (1.2.6) An abstract method is a method declared with the abstract keyword and has no implementation (ex: public abstract String getDescription();). (1.2.7) Abstract classes can have fields and concrete methods. (1.2.8) When you extend an abstract class, if the subclass leaves some or all of the abstract methods undefined then the subclass must be declared abstract as well. (1.2.9) When you extend an abstract class, if the subclass implements all of the abstract methods then the subclass is no longer abstract unless you declare some abstract methods in the subclass. (1.2.10) Abstract classes cannot be instantiated. (1.2.11) You can create object variables from an abstract class, but such variable must refer to an object of a non-abstract class which is a subclass of the abstract class. (1.2.12) In this case, when you call a method that is abstract in the abstract class what will be executed actually is the implementation of that method in the non-abstract class.


Interfaces:

(1.2.13) In Java, an interface is not a class but a set of requirements for classes that want to conform to that interface. (1.2.14) All methods of an interface are automatically public so there is no need to use the public keyword with each method in the interface. (1.2.15) When you implement an interface in a particular class you must declare the implemented interface methods as public or the compiler will consider them to have the package visibility (i.e. they are not considered to be public despite they considered public by default in the interface). (1.2.16) Interfaces can define constants (ex: public interface Interface1 { int SOME_CONST = 12; //This is considered public static final int SOME_CONST = 12}) so fields are always considered to be public static final even if you don't specify that in your code. (1.2.17) Interfaces never have instance fields and methods are never implemented in interfaces. (1.2.18) You cannot instantiate interface objects with the new keyword (since interface are not classes) but you can declare interface variables which refer to an object of class that implements the interface. (1.2.19) You can use instaceof keyword to test whether an object implements an interface (ex: if(anObj instanceof Interface1) { ... }). (1.2.20) Classes can implement multiple interfaces.


Inheritance:

(1.2.21) The idea behind inheritance is that you can create new classes that are built on existing classes. (1.2.22) The new class reuses the old class's methods and fields and adds new methods and fields to add new functionality. (1.2.23) The new class is called subclass, derived class, or child class while the old class is called superclass, base class, or parent class. (1.2.24) When there is a method that is implemented in both the superclass and subclass but you want to use the superclass version in the subclass, you have to use the super keyword (ex: super.someMethod();). (1.2.25) Inheritance hierarchy is the set of classes extending from a common superclass. (1.2.26) Inheritance chain is the path from a particular class to its ancestors in the inheritance hierarchy.

(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

Saturday, October 18, 2008

Section 1.1: Primitive, Enumeration, and Reference Types

Requirement: Describe, compare, and contrast primitives (integer, floating point, boolean, and character), enumeration types, and objects.

Primitive Types:
There are 8 primitive types in Java, divided as follows:

  • 4 are integer types. (1.1.1) They represent positive and negative values without fractional parts. (1.1.2) The following table shows all of the 4 integer primitive types (click on the image to enlarge):

(1.1.3) The range of the integer types doesn't depend on the machine on which you will be running the Java code. (1.1.4) Long integers have a suffix L (ex: 400000L). (1.1.5) While hexadecimal numbers have a prefix 0x (ex: 0x10FE). (1.1.6) Octal numbers have a prefix 0 (ex: 010).

  • 2 are floating-point number types. (1.1.7) Represent numbers with fractional parts. (1.1.8) The following table shows the 2 floating-point numbers:


(1.1.9) The double type is used in most applications. (1.1.10) The float type is only used when processing single-precision numbers and at the same time speed processing is important. (1.1.11) Numbers of type float have a suffix of F (ex: 1.23F). (1.1.12) Numbers of type double have an optional suffix of D (ex: 23.64433533D). (1.1.13) Floating-point numbers can be written in hexadecimal (ex: 0.125 can be written as 0x1.0p-3) where the base in written in hexadecimal while the exponent is written in decimal format. (1.1.14) There are 3 special values to denote overflows and errors: positive infinity, negative infinity, and NaN (not a number) (ex: 0/0 = NaN, 12/0 = positive infinity). (1.1.15) To test whether a floating-point number equals any of the previous special values you can use Double.isNaN(x), Float.isNaN(x), etc.. (1.1.16) Floating-point numbers are not suitable for financial calculations because of round off errors.

  • 1 is the character type char, used for Unicode. (1.1.17) Used to describe individual characters. (1.1.18) Unicode values range from \u0000 to \uFFFF. (1.1.19) Only the escape sequence \u can be used outside quoted character constants and strings (ex: String[] args is exactly the same as String\u005B\u005D args). (1.1.20) The following table represents escape sequences for special characters:

(1.1.21) The char type describes a code unit in UTF-16 encoding (http://en.wikipedia.org/wiki/UTF-16). (1.1.22) It is strongly recommended not to use the char type in your programs unless you actually manipulate UTF-16 code units (it is better to use Strings).

  • 1 is the boolean type for truth values. (1.1.23) It has 2 possible values true and false which are used for evaluating logical conditions. (1.1.24) You cannot convert between integer and boolean values.

Enumeration Type:
We will start by an example showing how to declare an enumerated type:

public enum Size { SMALL, MEDIUM, LARGE, EXTRA_LARGE };

(1.1.25) The enumeration type just defines is actually a class. (1.1.26) The class has exactly 4 instances, it not possible to construct new objects. (1.1.27) You never need to compare enum using equals methods, just use the == operator. (1.1.28) You can add constructors, methods, and fields to enumerated types. (1.1.29) The constructors are only invoked when the enumerated constants are constructed.

Example (1.1.28, 1.1.29):

enum Size {
SMALL("S"), MEDIUM("M"), LARGE("L"), EXTRA_LARGE("XL")

public Size(String abbreviation) { this.abbreviation == abbreviation; }
public String getAbbreviation() { return abbreviation; }

private String abbreviation;
}

(1.1.30) All enumerated types are subclasses of the class enum. (1.1.31) The toString method returns the name of the enumerated constant (ex: Size.SMALL.toString() returns "SMALL"). (1.1.32) The static valueOf method is the converse of the toString method (ex: Size s = (Size)Enum.valueOf(Size.class, "SMALL"); sets s to Size.SMALL). (1.1.33) Each enumerated type has a static values method that returns an array of all values in the enumeration (ex: Size[] values = Size.values(); fills the array with elements Size.SMALL, Size.MEDIUM, Size.Large, and Size.EXTRA_LARGE). (1.1.34) The ordinal method yields the position of an enumerated constant in the enum declaration counting from 0. (1.1.35) The enum class has a type parameter that is used in the compareTo method (ex: the enumerated type Size actually extends Enum). (1.1.35b) When you use the switch statement with enumerated constants, you need not supply the name of the enumeration in each label - it is deduced from the the switch value.

Objects:
(1.1.36) A class is a template or blueprint from which objects are made (an object is an instance of its class). (1.1.37) All of the Java code is written inside classes. (1.1.38) An object has 3 basic characteristics: behaviour, state, and identity. (1.1.39) The object's behaviour is what can you do with this object, or what methods can you apply to it? (1.1.39b) The object's behaviour is defined by the methods you can call. (1.1.40) The object's state is how does the object react when you apply these methods to it? (1.1.40b) The state is represented by the information that the object stores about what it currently looks like. (1.1.40c) An object's state can change over time. (1.1.41) The object's identity is how is the object distinguished from others that may have the same behaviour and state? (1.1.42) Individual objects that are instances of a class have the same behaviour, always differ in their identities, and usually differ in their states.

(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

Chapter 1: Fundamental Object-Oriented Concepts

Hello everybody,
Today we will start chapter 1 which corresponds to the first section in the SCJA specification. Before we dig into the details of the chapter, lets take a look at the basic points covered in this section. As I told you before, each point will be covered in a separate section of the chapter.


The details of the first section of the SCJA are as follows:
  1. Describe, compare, and contrast primitives (integer, floating point, boolean, and character), enumeration types, and objects.
  2. Describe, compare, and contrast concrete classes, abstract classes, and interfaces, and how inheritance applies to them.
  3. Describe, compare, and contrast class compositions, and associations (including multiplicity: (one-to-one, one-to-many, and many-to-many), and association navigation.
  4. Describe information hiding (using private attributes and methods), encapsulation, and exposing object functionality using public methods; and describe the JavaBeans conventions for setter and getter methods.
  5. Describe polymorphism as it applies to classes and interfaces, and describe and apply the "program to an interface" principle.
And now we are going to start with the first section that covers point #1 of the above list.
Get ready for the long exciting journey through the Java world :).

Hello, Certification World!!

In the Name of ALLAH

Hi there,
In this new blog I will write down my notes during my preparation for the SCJA (Sun Certified Java Associate). This is my first attempt to take a certification exam (and my first experience with the blogging world too). The road to be a Java certified professional is somewhat long. But the first step is to be an SCJA.

Here you are an overview of the Java certification path (click on the image to enlarge - I've just known this feature :D):

First, I want to tell you more about the SCJA. To successfully be an SCJA you must pass exactly one exam which is called Sun Certified Associate for the Java Platform, Standard Edition, Exam Version 1.0 (CX-310-019). The exam consists of 51 MCQ and Drag&Drop questions which must be completed in 115 minutes. The passing score is 68% (35 of 51 questions). The exam covers many subjects organized in 8 sections, as follows:

  • Section 1: Fundamental Object-Oriented Concepts.
  • Section 2: UML Representation of Object-Oriented Concepts.
  • Section 3: Java Implementation of Object-Oriented Concepts.
  • Section 4: Algorithm Design and Implementation.
  • Section 5: Java Development Fundamentals.
  • Section 6: Java Platforms and Integration Technologies.
  • Section 7: Client Technologies.
  • Section 8: Server Technologies.

You can find more details about the subjects covered in each section on Sun MicroSystems website.

And now lets talk about my preparation for the exam. This blog will serve as a notebook in which I'll write down whatever I read during my preparation. It will be organized like a book. Each section of the above 8 sections will be covered in a single chapter. And each subject covered in a particular section will be covered in a single section of the appropriate chapter.

Finally, here you are a list of references that I'll use during my study:

  1. Core Java, Volume I, 8th edition.
  2. Core Java, Volume II, 8th edition.
  3. Java How to Program, 6th edition.
  4. Effective Java, 2nd edition.
  5. Head First Java, 2nd edition.
  6. UML Distilled, 3rd edition.

Of course this is not an exclusive list and I might refer to other books or websites. So I'll use this main list besides searching the Internet whenever required.

I hope that I'll be able to do something useful for all people. I wish you can learn something new from this blog. And of course I'll be very happy to receive comments, feedback, additions, etc..

That's all for the first post. See you when I complete the first chapter. Wish you all good luck.