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 objectoriented 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).

[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 Not encapsulation Figure 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 Not use inheritance Figure 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 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 Not use polymorphism Figure 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  ... 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]... (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 Not encapsulation Figure Encapsulated * Class diagram... 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