UML Guidance (objectoriented development)

[Introduction]
About Software development style, "waterfall development" has been used from
very ancient times, and we recently often hear the "agile development."
"Waterfall development" is a development methodology that emphasizes the
structure and procedures. "Agile development" is treated as an object
"objective", "object", "things". And is a development methodology that
emphasizes interaction between objects.
In this document, we describes about UML（Unified Modeling Language（required
by the design of object-oriented development.

[About UML]
A

software

development

consists

a

phase

called

requirements

definition(analysis), basic design, design, implementation, test, systems test,
and operation(maintenance).
In the design phase (requirements definition, basic design, design), perform the
following tasks.

1) Make a concrete objects from Requirements, purpose and functions.
2) Determine the interaction between the object and the specification of the
object.
We describe Specification that decided at this time. It is difficult in words. But it
is easy to understand by using figure. Creation of figure are called "modeling" (
The figure itself is called model or diagram), and modeling technique to use
when this is the UML (Unified Modeling Language).


[About modeling]
In the design phase (requirements definition, basic design, design), we call
"modeling" work that to visualize the interaction between objects and object.
“ （（（（（（（（（（（（（（（ “
This sentence is Japanese. So you cannot understand meaning of this sentence.
But I make diagram this sentence like the following. How about this?

Employees provide work to the company (Vina Saver). Company (Vina Saver)
pays the salary. I think you understand the above sentence by this diagram. And
the company is one, also has five employees.
* UML modeling is best method for communicate between Vietnam members
and Japan members.


[About object-oriented]
In phases of software development (from “requirements definition” to “design”),
1) As a collection of interaction between objects, and analyze them.
-> OOA（object-oriented analysis
2) Design.
-> OOD（object-oriented design
3) Programming(Implementation).

-> OOP（object-oriented programming
The "object-oriented programming" is a programming using the following
technique.
- Encapsulation
- Inheritance
- Polymorphism
Programming language that incorporates these techniques is called "objectoriented programming language (OOPL)".


[About Object-Oriented: encapsulation]
Hiding

of

object's

internal

data,

behavior

and

data

type

is

called

"encapsulation". Let's look at the concrete code.

If it is not encapsulation)
class NonEncapsulatedEmployeeClass {
public Integer age;
public NonEncapsulatedEmployeeClass(){
age = 20;
}
}

NonEncapsulatedEmployeeClass
NonEncapsulatedEmployeeClass();
employee1.age = 40;

employee1

=

new

System.out.println(employee.age.toString());

“age” has been rewritten without permission. This is not good.

If it is encapsulation)
class EncapsulatedEmployeeClass {
private Integer age;
public EncapsulatedEmployeeClass(){

age = 20;
}
public Integer getAge() {
if (today >= birthday) {
age++;

}
}

birthday = today + 365;
}
return age;

EncapsulatedEmployeeClass employee1 = new EncapsulatedEmployeeClass();
employee1.age = 40;
// Compile error (1)
employee1.setAge();
// Compile error (2)
System.out.println(employee.getAge().toString());

Because “age” is private type, it cannot be change directly (1). And because
“setAge()” method is not exist, you cannot call “setAge()” method (2). It is
updated only when birthday is come!


Like above, by using encapsulation, you should hide a class variable (in this
case, declare private type), and you should not create unnecessary method
(such as “setAge()”). So, you were able to avoid the problems that may occur.
The following is a UML class diagram of the above code.

Figure 1 Not encapsulation

Figure 2 Encapsulated

* Class diagram that has not been encapsulated and class diagram that has
been encapsulated are different. In design phase, you must be aware of
encapsulation when you create UML diagram. This is an important point.


[About Object-Oriented: inheritance]
That the object inherits properties of other object is called "inheritance". In this
case, there is an "inheritance relationship" between the object and other object.

If inheritance is not used)
class Ikawa {
private Vector skill;
public Ikawa() {
skill.add("driving");
skill.add("programming");
skill.add("swim");
skill.add("golf");
}
public void printSkill() {
for (int inc = 0; inc < skill.size(); inc++) {
System.out.println(skill.get(inc));
}
}
class Shinozaki {
private Vector skill;
public Shinozaki() {

skill.add("driving");
skill.add("programming");
skill.add("drinker");
}
public void printSkill() {
for (int inc = 0; inc < skill.size(); inc++) {
System.out.println(skill.get(inc));
}
}
class Utsunomiya {
private Vector skill;
public Utsunomiya() {
skill.add("driving");
skill.add("programming");
skill.add("swim");
skill.add("basketball");
}
public void printSkill() {
for (int inc = 0; inc < skill.size(); inc++) {
System.out.println(skill.get(inc));
}
}
Ikawa
tuken = new Ikawa();
Shinozaki shino = new Shinozaki();
Utsunomiya utsuma = new Utsunomiya();
tuken.printSkill();
shino.printSkill();
utsuma.printSkill();

In

this

code,

because

there

were

many

similar

variables(skill),

methods(printSkill), and logics(skill.add), it is hard to understand. If you want to
change the code at "printSkill" method, you must change the many lines


(3methods). As a result, your work will increase, and you might write the wrong
code.

If inheritance is used)
class Employee {
protected Vector skill;
public Employee(){
skill.add("drive");

skill.add("programming");
}
public void printSkill() {
for (int inc = 0; inc < skill.size(); inc++) {
System.out.println(skill.get(inc));
}
}
class Ikawa extends Employee {
public Ikawa() {
skill.add("swim");
skill.add("golf");
}
}
class Shinozaki extends Employee {
public Shinozaki() {
skill.add("drinker");
}
}
class Utsunomiya extends Employee {
public Utsunomiya() {
skill.add("swim");
skill.add("basketball");
}
}

Employee[3] employees = new Employee[] {
new Ikawa(),
new Shinozaki(),
new Utsunomiya()
};

for (int inc = 0; inc < employees.length; inc++) {
employees[inc].printSkill();
}

Source code above, it is easy to understand, because variables (“skill” in
Employee class) and methods (“printSkill” method in Employee class) are now
one and logic(call “skill.add”) is simple. If you want to change the code at
"printSkill" method, you only need to change the one method.


The following is a UML class diagram of the above code.

Figure 3 Not use inheritance

Figure 4 Use inheritance

* Class diagram that has not used inheritance and class diagram that has used
inheritance are different. In design phase, you must be aware of inheritance
when you create UML diagram. This is an important point.


[About Object-Oriented: Polymorphism]
If the Polymorphism is not used)
class Utility {
public static String getStringValueFromNumber(Number inValue) {
...
}
public static String getStringValueFromDate(Date inValue) {
...
}

}
class Number {
Integer var;
public Number() {
var = new Integer(123456789);
}
}
class Date {
Date var;
public Date() {
var = new Date(today);
}
}
Number number = new Number();
System.out.println(Utility.getStringValueFromNumber(number));
Date date = new Date();
System.out.println(Utility.getStringValueFromDate(date));

When you print (System.out.println) the content of objects, you must be aware,
whether the content of the object is Date type or Numbers type. If it is Date
type, you must use “getStringValueFromDate()” method. If it is Number type,
you must use “getStringValueFromNumber()” method. This is inconvenient.


If the polymorphism is used)
class Variable {
public String getStringValue() {
return "";
}
}

class Number extends Variable {
Integer var;
public Number() {
var = new Integer(123456789);
}
public String getStringValue() {
return var.toString();
}
}
class Date extends Variable {
Date var;
public Date() {
var = new Date(today);
}
public String getStringValue() {
return var.toGMTString();
}
}
Variable[2] vars = new Variable[] {
new Number(),
new Date()
};
for (int inc = 0; inc < vars.length; inc++) {
System.out.println(vars[inc].getStringValue());
}

When you print (System.out.println) the content of objects, You do not need to
be aware, whether the content of the object is Date type or Numbers type,
because “getStringValue()" methods return appropriate value (String type).

The following is a UML class diagram of the above code.

Figure 5 Not use polymorphism

Figure 6 use polymorphism

* Class diagram that has not used polymorphism and class diagram that has
used polymorphism are different. In design phase, you must be aware of
polymorphism when you create UML diagram. This is an important point.