Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:45:27Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12] 

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.[17] In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:[18]

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524 
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx 
[3] http://www.crcpress.com/product/isbn/9781439838129 
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992. 
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm 
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm 
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design 
[8] http://softwaredesign.com/objects.html 
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design 
[10] http://www.objectmentor.com/omSolutions/oops_what.html 
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us 
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/ 
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:44:40Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12] 

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.[17] In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:[18]

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:31:32Z

Xfang2: /* Software design anti-patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12] 

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.[17] In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:[18]

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:29:41Z

Xfang2: /* Design patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12] 

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:29:09Z

Xfang2: /* Design patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12] 

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:28:55Z

Xfang2: /* Design patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]
 
There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:28:39Z

Xfang2: /* Design principles */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:28:14Z

Xfang2: /* Design principles */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) polymorphism] manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:27:38Z

Xfang2: /* Design principles */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:27:14Z

Xfang2: /* Design principles */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)inheritance] way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:25:07Z

Xfang2: /* Programming Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
 There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:24:57Z

Xfang2: /* Language Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
 The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:24:11Z

Xfang2: /* Language Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

 Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:23:36Z

Xfang2: /* Programming Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:22:48Z

Xfang2: /* What is software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:22:30Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4. 
[17]http://sourcemaking.com/antipatterns 
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:21:48Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design 
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4.

[17]http://sourcemaking.com/antipatterns
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:21:25Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4.

[17]http://sourcemaking.com/antipatterns
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:20:45Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
[17]http://sourcemaking.com/antipatterns
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:20:09Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
[17]AntiPatterns http://sourcemaking.com/antipatterns
[18]http://en.wikipedia.org/wiki/Anti-pattern

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:19:15Z

Xfang2: /* Software design anti-patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:18:48Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.［2］Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:18:14Z

Xfang2: /* Factors may lead to Poor OOD */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.［2］Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-21T00:16:10Z

Xfang2:

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

=Poor OOD Leads to Software Failures=
In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 1, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.
[[File:failure.jpg]]

Figure 1 cyclic Fault behavior
==Factors may lead to Poor OOD==

Bad practice in code will always lead to the poor OOD. Here are some common ones:［1］
*Classes that break the Single Responsibility Principle (SRP) and perform too many actions
*Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free
*Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
*Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
*Long chains of member access
*Use of too many design patterns in a small space
*Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results
*A base class down-casting itself to a derived class. Like, excessive use of switch statements, or derived classes that override everything
*Duplicate code, code that does the same thing

== Software design anti-patterns==
In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.［2］Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.［3］ In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:［4］

*Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
*Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
*Big ball of mud: A system with no recognizable structure
*Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
*Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
*Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
*Input kludge: Failing to specify and implement the handling of possibly invalid input
*Interface bloat: Making an interface so powerful that it is extremely difficult to implement
*Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
*Race hazard: Failing to see the consequence of different orders of events
*Stovepipe system: A barely maintainable assemblage of ill-related components

== Object oriented design anti-patterns ==
*Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
*BaseBean: Inheriting functionality from a utility class rather than delegating to it
*Call super: Requiring subclasses to call a superclass's overridden method
*Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
*Constant interface: Using interfaces to define constants
*God object: Concentrating too many functions in a single part of the design (class)
*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
*Poltergeists: Objects whose sole purpose is to pass information to another object
*Sequential coupling: A class that requires its methods to be called in a particular order
*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T23:59:30Z

Xfang2: /* Language Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:35:18Z

Xfang2: /* References */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

= References =
*[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
*[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
*[3] http://www.crcpress.com/product/isbn/9781439838129
*[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
*[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
*[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
*[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[8] http://softwaredesign.com/objects.html
*[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
*[10] http://www.objectmentor.com/omSolutions/oops_what.html
*[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
*[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
*[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
*[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:34:47Z

Xfang2:

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

= References =
[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:31:32Z

Xfang2: /* Tips for a good OOD */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:30:59Z

Xfang2: /* Tips for a good OOD */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects 
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable 
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection 
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes 
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:30:03Z

Xfang2: /* Design patterns */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator 
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller 
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion 
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection 
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations 
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:29:44Z

Xfang2: /* Design principles */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation 
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction 
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance 
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism 
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:28:54Z

Xfang2: /* How to achieve a good OOD */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:28:36Z

Xfang2: /* How to achieve a good OOD */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:28:04Z

Xfang2: /* Programming Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability 
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy 
This is important for large programs and preventing loss of data.

Documentation 
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:27:41Z

Xfang2: /* Language Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection 
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance 
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface 
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism 
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:27:01Z

Xfang2: /* Factors leading to software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:26:18Z

Xfang2: /* Factors leading to software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input 
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement 
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation 
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job 
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown 
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture 
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:25:50Z

Xfang2: /* Language Concepts */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation 
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:06:34Z

Xfang2: /* Factors leading to software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

Poor user input
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

Vague requirement
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that not match the job
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:05:20Z

Xfang2: /* What is software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

== Poor user input ==
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

== Vague requirement ==
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

== Poor cost and schedule estimation==
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

== Skills that not match the job ==
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

== Communication breakdown ==
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

== Poor architecture ==
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

File:Failure.jpg

2011-10-20T05:03:55Z

Xfang2:

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:03:24Z

Xfang2: /* What is software failure */

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

[[File:failure.jpg]]

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

== Poor user input ==
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

== Vague requirement ==
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

== Poor cost and schedule estimation==
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

== Skills that not match the job ==
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

== Communication breakdown ==
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

== Poor architecture ==
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T05:01:26Z

Xfang2:

=Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

== Poor user input ==
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

== Vague requirement ==
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

== Poor cost and schedule estimation==
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

== Skills that not match the job ==
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

== Communication breakdown ==
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

== Poor architecture ==
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011/ch4 4j fw

2011-10-20T04:59:40Z

Xfang2: Created page with "Software failures due to poor OOD = Introduction = In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focu..."

Software failures due to poor OOD = Introduction =
In this wiki page, we will introduce the factors that relevant to software project success and failure. And we will focus on analyzing how [http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] affects the success of software. In the later part of this wiki page, we will demonstrate and analysis some examples of software failures which due to poor OOD.

= Software success and failure =

== What is software success ==
The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In ''The Strategic Project Office'', written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan.
The organization’s shareholders are satisfied.
The organization is financially successful.
Projects are completed on schedule and on budget.
Project customers are satisfied.
Project resources are allocated optimally.
Projects are aligned to the organization’s business strategy.
The organization works on the right projects.

== What is software failure ==
Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD that will be discussed later. In the figure below, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

Figure 1 cyclic Fault behavior

= Factors leading to software failure =

Most software project can be considered at least partial failures since few of the software can meet all the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. Below are some factors that may lead to the software failure with no particular order:

== Poor user input ==
It is possible that a titanic project which meets all the requirements ultimately get fails because the system did not meet the user needs.

== Vague requirement ==
People cannot design a process that assumes the requirement is stable. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

== Poor cost and schedule estimation==
Although it is unfair to call software project a failure if it cannot meet the budget and schedule goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

== Skills that not match the job ==
It is obvious reason, just like managers can perform poorly if they lead projects that do not match their strengths.

== Communication breakdown ==
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

== Poor architecture ==
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

= What is Object Oriented Design (OOD) =
[http://en.wikipedia.org/wiki/OOD Object Oriented Design (OOD)] is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about [http://en.wikipedia.org/wiki/Object_(computer_science) objects]. An object can be considered as a “[http://en.wikipedia.org/wiki/Black_box black box]” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface.

== Simple example of OOD==
Here we give a simple example of coding used in both non-object-oriented-design and object-oriented-design.

If we want to add two names together in non-object-oriented language such C. We first define a data type as list which will be defined as structure in C:

<pre>
structure list {
<definition of list structure data here>
};

list a, b, c;

a = “Adam”;
b = “Eva”;
c = a + b;
</pre>

We expect to get the result as “Adam Eva” but it doesn’t work actually in C. C complier will generate error when adding a and b because it only know how to add number while “Adam” and “Eva” are not.

Let try this example again in Object-oriented language such as Ruby, we write the code as below:

<pre>
a = “Adam”
b =”Eva”
c = a + b
puts c
</pre>

The object a is created with string “Adam” and object b is created with string “Eva”. After entering the code, we can get the result “AdamEva”. Ruby complier knows how to manipulate the message “+” and that’s why object c gets new value.

== Tools help for OOD ==
Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality.[9]
===Language Concepts===
The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation
[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection
Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface
[http://en.wikipedia.org/wiki/Interface_(Java) Interface] is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism
[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] refers to the ability to define different functions or classes as having the same name but taking different data types.

===Programming Concepts===
There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy
This is important for large programs and preventing loss of data.

Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

=How to achieve a good OOD=
“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”
----------------------------Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

==Design principles==
Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

==Design patterns==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern] is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

==Tips for a good OOD==
There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable

Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]
What factors may lead to poor OOD
Example of software due to poor OOD (analysis)

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
[12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/

CSC/ECE 517 Fall 2011

2011-10-20T04:58:29Z

Xfang2:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 1i zf

2011-09-18T03:05:57Z

Xfang2: /* C++ */

CSC/ECE 517 Fall 2010/ch1 1i zf
----
= Introduction =
In [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented languages], method is a subroutine which associates with the instances of the class to define the specific behavior of this class. In the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] of these languages, methods reimplementation is essential because descendant class inherited from the ancestor class in which properties and method have been defined to some extent. In fact, method reimplementation not only simplify the coding (become more readable) but also make the relationship tight between ancestor class and descendant class. However, in different OO languages, the ways of acquiring or allowing method reimplementation are significantly different. In this article, we are going to introduce these differences and provide code for better understanding.

= Principle of method reimplementation in descendant class =
Method reimplementation is various in different OO languages according to their own programming rules and complier environments. And it also associated with inheritance between ancestor class and descendant class. Several terms of method are listed below.

==Abstract method==
[http://en.wikipedia.org/wiki/Abstract_method Abstract method] is a method only has name but little or no implementation in the ancestor class, which must be also an abstract class. In most of the case, codes in abstract method are considered dummy but it does not mean useless. In fact, it provides a place for descendant class which inherited from the ancestor class to define specific behaviors and actions.

For example, a toy company develops an ancestor class called “animal” which contains “dog”, “bird” and “fish” as its descendant classes. These subclasses have same characteristic such as color, size, price and behavior like move, speak. Here we use the abstract methods for move and speak so that the subclasses can define their own behaviors which act differently.

==Virtual method==
Virtual method, or [http://en.wikipedia.org/wiki/Virtual_method virtual function], is the method that first declared or defined in the ancestor class and then completed defined in the descendant class. Based on the functionality in the subclasses, virtual method can be simply defined or overridden with details. In a virtual method in which only has the name but no implementation, we call this as pure virtual method, as known as abstract method introduced above.

==Overridden method==
[http://en.wikipedia.org/wiki/Method_overriding Overridden method], as mentioned in virtual method, is used in OO language involving inheritance hierarchy. It allows descendant classes to redefine the method in their ancestor class with more details and particular purposes. “Override” means the implementation in subclasses rewrites or redefines the original implementation of the method in their super class without changing the name, parameter and return type. To better demonstrate how overridden method work, we take the toy company example again. In the behavior aspect of “animal”, we have the method call “move”. In this method, we know it define the same of movement for all the animals. However, the way of movement among “dog”, “bird” and “fish” are different. Thus, in “dog” class, we may redefine the detail in move method as “I use leg”; in “bird” class, the detail of move method is “I use wings”; and in “fish” class, the detail of move method is “I use fin”.

==Overloaded method==
[http://en.wikipedia.org/wiki/Method_overload Overloaded method] means that method share the same name with other method but may be different in other aspects such as parameter, number of parameter and data type.
And the correct method will be executed automatically during the runtime depends on how it is called.

= Method reimplementation in different languages =

==Smalltalk==
In [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] language, we can use the inheritance to reimplementation the methods. Inheritance is very useful in Smalltalk which makes the Smalltalk language reusability and extensibility.
There are two ways to modify the behavior of the methods in Smalltalk by inheritance. One is adding new methods and the other is overriding the inherited method.

===Adding Methods===
Adding new method is very simple; we can add either instance or class methods, to the class definition. The following diagrams show how the adding method works:

{| border=1 align = center
|+ClassRoom’s Methods
|-
| Room instance methods
|-
| align = center | Room_Number
|-
| align = center | Room_Size
|-
| align = center | Open_Window
|-
| align = center | Open_Door
|}

{| border=1 align = center
|-
| ClassRoom instance methods
|-
| align = center | Turn_On_Computer
|-
| align = center | Clean_Blackboard
|}

The ClassRoom class is specific types of Room. The ClassRoom class is inheriting from Room Class, so the new methods Turn_On_Computer and Clean_Blackboard will add to the ClassRoom class. Now ClassRoom class definition can now support all of the messages or methods in Room and the two new messages.

===Overridden method===
Overriding an inherited method is very important way to provide unique behaviors to a class. If an object receives a message which we have a method in the class definition for that massage, the object will work its way up the hierarchy until it finds a method with that name. We cannot delete the inherited methods, if we do not need the method in the superclass, we can provide a method by the same name with the superclass in the subclass with no code in the method. In this way, we can simply replace the behavior of the superclass behavior by no behavior.

==Java==
We can use the inheritance to make the method reimplementation in [http://en.wikipedia.org/wiki/Java Java]. They are similar with the ways we do in Smalltalk, like the overriding and overloading. But in Java, we can define abstract method and virtual method in Java, and it provides a @override tag that prevents the programmer from thinking another method is being overridden when really it is not.

===Overridden method===
If we want to override a method in subclass that inherited from the superclass, we should invoke the superclass method by using the keyword super.
Below is the example:
<pre>
public class Say {
public void express() {
System.out.println(“Hello wolrd!”);
}
}

public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
}
}
</pre>

Class Say represents the superclass and implements a method call express (). The subclass called Shout will inherit all the methods which in the Say class. But the class Shout will override the method express in Shout class, and replace it with new action.

<pre>
Say hello_say = new Say();
hello_say.express(); // Prints “Hello wolrd!”

Say hello_shout = new Shout(); //Polymorphism
hello_shout.express(); //Prints “Hello wolrd, loudly!”
</pre>

The super can be used to call the superclass's method; we can modify the class in class Shout to make the method express call another express method which in superclass Say.

<pre>
public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
Super.express(); //will call the express method in class Say
}
}
</pre>

But some of the methods cannot be overridden. For example, in Java, a method that is declared final in the super class cannot be overridden, and the method declared private or static cannot be overridden too. We cannot make a class that that is declared final to become a super class too.

===Overloaded method===

Java supports method overloading which allows the creation of several methods with the same method name, but different in their types of input and output of the function.
We can define two methods with the same name in Java:

<pre>
int Add(int a, int b) {
return a + b;}

float Add(float a, float b) {
return a + b;}
</pre>

The two methods have the same method name in define. To call the methods, we should pass the parameters to the methods above. When we call Add(1,1) it will call the first method Add(int a, int b), because we pass two int types of the parameters to the method Add. And if we call Add(1.0,1.0) it will call the second method Add(float a, float b) because we pass the float types of the parameters to the method Add. But if we give these two methods parameters a, b with default value, it will cause an error, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two methods to use.

===Abstract Method===
Abstract method: When a class contains an abstract method, that class must be declared as abstract. The abstract method has no implementation and thus, classes that derive from that abstract class, must provide an implementation for this abstract method.

Abstract method are the method that with no body specification. Subclasses must provide the method statements to fulfill the abstract method. Especially, if the method was one provided by the superclass, we should override them in each subclass. If we forgot to override that will cause some problem like that the applied method statement may be inappropriate.
Below is the abstract method example, we need to define the abstract method in subclass to reimplementation the method.

<pre>
public abstract class Vehicle // class is abstract
{
private String name;
public Vehicle (String nm) // constructor method
{ name=nm; }
public String getName() // regular method
{ return (name); }
public abstract void run(); // abstract method - note no {}
}
</pre>

===Virtual Method===

Virtual method: A class can have a virtual method. The virtual method has an implementation. When you inherit from a class that has a virtual method, you can override the virtual method and provide additional logic, or replace the logic with your own implementation.
A virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature.
In java, all the non-static methods with the default type “virtual function”. But if the methods marked with the keyword final, which cannot be overridden. The private methods are non-virtual which cannot be inherited.
Below is the example for Virtual Method:

<pre>
public class toy
{
public void say()
{
System.out.println(“I am toy.”);
}

public static void main(String[] args)
{
List<toy> toys = new LinkedList<toy>();

toys.add(new toy());
toys.add(new toy_man());
toys.add(new toy_car());

for(toy current_toy : toys)
{
current_toy.say();
}
}
}

public class toy_man extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_man.”);
}
}

public class toy_car extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_car.”);
}
}
</pre>

The output will be:
I am toy.
I am toy_man.
I am toy_car.

===Interfaces===
In java interfaces are very similar with the abstract classes but all the methods in interfaces are abstract and all properties are static final. As the abstract classes, interfaces also can be inherited. And we also use the extends keywords too. Different from C++, in Java we cannot use the multiple inheritances for class, which means that a subclass extends from more than one superclass. An interface can tie elements of several classes together, and it also can separate design from coding as class method headers are specified but not their body.
For example we build a running interface for the subclasses of Vehicle. Because there is a method called stop(), we should define the method in any class which using the running interface.

<pre>
public interface running
{
public void stop();
}
</pre>

When we create a class that will use the interface, we should use the keywords implements which will follow one or more interface list.

<pre>
public class Vehicle_Run extends Vehicle implements running
{
public Vehicle_Run (String nm)
{
super(nm); // builds ala parent
}
public void run ()
{
System.out.println("I am running.");
}
public void stop () // this method specific to Vehicle_Run
{
System.out.println("I stop.");
}
}
</pre>

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is very similar with Java in method overriding and method overloading. The method overloading of C++ we can refer the method overloading in Java. But they have difference in method overriding between C++ and Java.

===Overridden method===
C++ does not provide the keyword super that a subclass can use in Java to invoke a superclass version of a method that it wants to override. But in C++ we can use the base class follow with the scope resolution operator to override the superclass method.
Below is the example:
<pre>
class Toy {
public:
Toy(char* nm, int s):name(name),size(s){}
virtual void print() const;
private:
char* name;
int size;
};

void Toy::print() const{ // print() method of base class
std::cout<<”Name = ” << this->name << “; Size = ” << this->size;
}

class Toy_car: public Toy {
public:
Toy_car(char * nm, int s, int t) : Toy(nm,s), type(t) {}
virtual void print() const;

private:
int type;
};

void Toy_car::print() const{
Toy::print();
Std::cout<<”; Type = ” << this-> type;
}
</pre>

The main method will call the print method in class Toy and class Toy_car separately.
<pre>
Int main(int argc, char** argv) {
Toy toy_test(“Jack”, 9);
Toy_test.print();
//outputs:
//Name = Jack; Size = 9

Toy_car toy_car_test(“Ann”,”7”,”1”);
//the pointer to the most overridden method in the vtable in on Toy_car::print
toy_car_test.print();// but this call does not illustrate overriding
static_cast<Toy&>(toy_car_test).print(); // this one does
//output
// Name = Jack; Size = 9;Type = 1
}
</pre>

===Virtual Method===

In C++ we declare the virtual method by add the virtual keyword before the function’s declaration. The concept of the virtual method is nearly the same with that in Java, but the function in C++ is not default by “virtual function”.
Below is the example of virtual method in C++.

<pre>
class Toy {
public:
virtual void say() const {
std::cout << “I am Toy.” << std::endl;
}
};

class Toy_car : public Toy{
public:
void say() const {
std::cout << “I am Toy_car.” << std::endl;
}
};

class Toy_man : public Toy{
public:
void say() const {
std::cout << “I am Toy_man.” << std::endl;
}
};

int main() {
std::vector<Toy*> toys;
toys.push_back(new Toy()) ;
toys.push_back(new Toy_car()) ;
toys.push_back(new Toy_man()) ;

for(std::vector<Toy*>::const_iterator it = toys.begin() ; it != toys.end(); ++it){
(*it)->say();
delete *it;
}

return 0;
}
</pre>

The output will be:
I am Toy.
I am Toy_car.
I am Toy_man.

If we do not declare Toy::say() as virtual, the result will be:
I am Toy.
I am Toy.
I am Toy.

===Abstract Method===

Quite similar with abstract method used in JAVA, the abstract method applied in C only generate a new virtual method without providing an implementation of that method. In fact, the derived classes have to overload the method and therefore to specify the implementation in that method. That's because abstract method provide no actual implementation in the body in which only exist a semicolon.

<pre>
public abstract class Toy
{
public abstract void action(speed s, direction d);
}
public class dog: Toy
{
public override void action(speed s, direction d) {
d.moveasDog(s);
}
}
public class bird: Toy
{
public override void action(speed s, direction d) {
d.moveasBird(s);
}
}
</pre>

As we can see above, the Toy class defines a abstract method which allow dog and bird to move. Obviously the action method is abstract since no default implementation included. And in classes of dog and bird, we can see detail implementations in action method, so that specific action method has been defined according to individual behavior.

==Ruby==

Different with Java and C, [http://en.wikipedia.org/wiki/Ruby Ruby] is a dynamic Object-orientated Language. It allows default parameter and variable parameter used in the method. Therefore, there is no strict classification of overridden method and overloaded method.

=== Method with default parameter===
With the code below, we can better understand this concept:

<pre>
def sum( x, y, z=1 )
x+y+z
end

puts sum(10,20,30)
puts sum(5.0,10)
</pre>

Output:
60
16.0

<pre>
def sum( *num )
totalSum =0
num.each { |i| totalSum+=i }
return totalSum
end

puts sum(1,10,100)
puts sum(2.2,3.3,4.4)
puts sum()
</pre>

Output:
111
9.9
0

From the output we can see Ruby allow default parameter regardless the number and the type of parameter. Unlike the limitation in other static OO language, Ruby can dynamically execute codes in runtime. Therefore, the reimplementation in Ruby become less important compared with other static languages. Several ways can be used for method reimplementation in Ruby. For example, just simply extend classes. Or re-declare an existing class with new methods. To better demonstrate how these two approaches work, we use the code example as below:

=== Method extended from class===

<pre>
class Animal
attr_accessor:voice
def initialize(v)
puts "This is an animal."
self.voice=v
end

def speak
puts "This animal can speak"+self.voice
end
end

class Dog<Animal
end

d=Dog.new(" bow-wow!!")
d.speak
</pre>

The output of this code is
This is an animal.
This animal can speak bow-wow!!

As we can see, we just simply create a descendant class Dog and use the default method in the ancestor class Animal. The dog can bark as “bow-wow”, so we use the voice parameter to make it particular for dog.

=== New method in the descendant class===

Also, we can change the code of descendant class Dog since every dog can bark. Code shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end

d=Dog.new
d.speak
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow

As we can see, the first line of the result is changed since we change the initialize in Dog class. And we do not need to define how the dog bark in the follow code since it has been defined in the Dog class. To further improve the code of this example, we can rewrite the Dog class again to make the speak method more specific. Codes shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
i am a dog and i can speak like this: bow-wow
As we can found in the result, the speak method is revised. This result is exclusive for describing dog.

If we just want to improve the functionality of the method in an ancestor class instead of rewriting it, we can use the keyword super in the code. Code for example is shown below:
<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
super
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow
i am a dog and i can speak like this: bow-wow

From the result, we can see that both the speak methods in Animal class and Dog class are used.

=Advantages and disadvantages of each languages applying method reimplementation=
==Smalltalk==
Advantages:
It is a very flexible program language. It allows any method to be overridden, so we can be very convenient to get the method we want by overridden.

Disadvantages:
Sometimes we do not require some methods in Smalltalk, but we still can override the methods which no longer need them.

==Java==
Advantages:
Java support the overriding methods, overloading methods, abstract methods, virtual methods, interfaces which make java be one of the top popular programming language today. We can reimplementation the methods by use the overriding and overloading methods. Abstract methods and virtual methods make the hierarchy structure colorful and clear. The interfaces of Java help to make some design patterns implementation easily. For example when we use the Strategy pattern, which clearly indicates a place in the design that will change, we should define the strategy as an interface.

Disadvantages:
Java does not support the multiple inheritances. Compared with C++ which supports the multiple inheritances, C++ can provide more flexible way and more clear structure in class inheritance, which makes C++ sometimes a better choice for reimplementation methods in descendant classes.

==C++==
Advantages:
C++ provide the multiple inheritance which makes C++ much more flexible in reimplementation the methods. With the multiple inheritances, it makes some of the design patterns work better. One benefit from it is Adapter pattern: it uses multiple inheritances to adapt one interface to another. This pattern usually used to provide implementation for an abstract class (when you want to use an existing class and its interface is not appropriate, so you need to glue another interface with that class).

The scope resolution operator in C++ is powerful enough. We can put the definition of the class in one file and use the scope resolution operator to implement the method in another file, which will make the whole structure more clear and it will help to add new method, overriding method, overloading method much easier.

With the keywords “virtual” we can make the virtual method in C++ much more flexible. From the above examples you can see that the “virtual” keywords it helps us easy to fulfill the polymorphism, makes the program much more efficiently.

Disadvantages:
The multiple inheritances help us easy to reimplementation the method in subclass. But sometimes it causes some problems. With multiple inheritances, it makes the hierarchy of the program very complex. The programmers need to more time know the details of each base class. It will cause problem when using multiple inheritance is the diamond problem, which occurs when two classes are derived from a base class and another class is obtained by joining the derived classes together. If the derived classes override the same method from the base class when calling the method from the merged class and the joining class does also override that method, an ambiguity will rise. Another problem is that if two classes derived from the same base class. When we use these two classes to make multiple inheritance, it would make some base members duplicated.

==Ruby==
Advantages:
Java and C++, both as static OO languages, use overload and overridden methods in polymorphism to extend the flexibility of programming, since the property and method of class cannot be changed during the runtime. Compared with Java and C++, Ruby, as a dynamic OO language, allows change of property and method in the class in the runtime. For this reason, the method reimplementation becomes less essential as that in Java and C++. Ruby does not require using complicated mechanism to define the methods for disambiguation. Thus, Ruby is considered has better performance in reducing code and providing concise program.

Disadvantages:
The disadvantage of Rudy, to some extent, also results from its dynamic characteristic. It become unsafe and unreliable compared with static typing OO language. For example, method in Ruby does not care about the type of parameter. It may cause problem when the type of parameter is essential for some application. Ruby cannot identify this wrong type error made by programmer.

=Conclusion=
Reimplementation of methods is one of the most essential features in Object-Oriented language. It expands the flexibility of polymorphism in which descendant class can define their own behaviors and functions more efficiently. There are different ways for various languages to define how to reuse methods. In details, we use codes of Smalltalk, Java, C++ and Ruby to demonstrate and analysis how methods are reused, following with the discussion of advantages and disadvantages of method reuse in these four languages.

= References =
*[1]:http://en.wikipedia.org/wiki/Method_(computer_programming)
*[2]:http://www.wisegeek.com/what-is-an-abstract-method.htm
*[3]:http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap6.html
*[4]:http://en.wikipedia.org/wiki/Function_overloading
*[5]:http://home.cogeco.ca/~ve3ll/jatutor5.htm
*[6]:http://en.wikipedia.org/wiki/Virtual_function#Java
*[7]:http://rubylearning.com/satishtalim/ruby_overloading_methods.html
*[8]:http://rubylearning.com/satishtalim/writing_own_ruby_methods.html
*[9]:http://learnruby.com/about-ruby.html
*[10]:http://www.pluitsolutions.com/2006/10/05/overriding-methods-in-ruby/

CSC/ECE 517 Fall 2011/ch1 1i zf

2011-09-18T02:20:08Z

Xfang2: /* Introduction */

CSC/ECE 517 Fall 2010/ch1 1i zf
----
= Introduction =
In [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented languages], method is a subroutine which associates with the instances of the class to define the specific behavior of this class. In the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] of these languages, methods reimplementation is essential because descendant class inherited from the ancestor class in which properties and method have been defined to some extent. In fact, method reimplementation not only simplify the coding (become more readable) but also make the relationship tight between ancestor class and descendant class. However, in different OO languages, the ways of acquiring or allowing method reimplementation are significantly different. In this article, we are going to introduce these differences and provide code for better understanding.

= Principle of method reimplementation in descendant class =
Method reimplementation is various in different OO languages according to their own programming rules and complier environments. And it also associated with inheritance between ancestor class and descendant class. Several terms of method are listed below.

==Abstract method==
[http://en.wikipedia.org/wiki/Abstract_method Abstract method] is a method only has name but little or no implementation in the ancestor class, which must be also an abstract class. In most of the case, codes in abstract method are considered dummy but it does not mean useless. In fact, it provides a place for descendant class which inherited from the ancestor class to define specific behaviors and actions.

For example, a toy company develops an ancestor class called “animal” which contains “dog”, “bird” and “fish” as its descendant classes. These subclasses have same characteristic such as color, size, price and behavior like move, speak. Here we use the abstract methods for move and speak so that the subclasses can define their own behaviors which act differently.

==Virtual method==
Virtual method, or [http://en.wikipedia.org/wiki/Virtual_method virtual function], is the method that first declared or defined in the ancestor class and then completed defined in the descendant class. Based on the functionality in the subclasses, virtual method can be simply defined or overridden with details. In a virtual method in which only has the name but no implementation, we call this as pure virtual method, as known as abstract method introduced above.

==Overridden method==
[http://en.wikipedia.org/wiki/Method_overriding Overridden method], as mentioned in virtual method, is used in OO language involving inheritance hierarchy. It allows descendant classes to redefine the method in their ancestor class with more details and particular purposes. “Override” means the implementation in subclasses rewrites or redefines the original implementation of the method in their super class without changing the name, parameter and return type. To better demonstrate how overridden method work, we take the toy company example again. In the behavior aspect of “animal”, we have the method call “move”. In this method, we know it define the same of movement for all the animals. However, the way of movement among “dog”, “bird” and “fish” are different. Thus, in “dog” class, we may redefine the detail in move method as “I use leg”; in “bird” class, the detail of move method is “I use wings”; and in “fish” class, the detail of move method is “I use fin”.

==Overloaded method==
[http://en.wikipedia.org/wiki/Method_overload Overloaded method] means that method share the same name with other method but may be different in other aspects such as parameter, number of parameter and data type.
And the correct method will be executed automatically during the runtime depends on how it is called.

= Method reimplementation in different languages =

==Smalltalk==
In [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] language, we can use the inheritance to reimplementation the methods. Inheritance is very useful in Smalltalk which makes the Smalltalk language reusability and extensibility.
There are two ways to modify the behavior of the methods in Smalltalk by inheritance. One is adding new methods and the other is overriding the inherited method.

===Adding Methods===
Adding new method is very simple; we can add either instance or class methods, to the class definition. The following diagrams show how the adding method works:

{| border=1 align = center
|+ClassRoom’s Methods
|-
| Room instance methods
|-
| align = center | Room_Number
|-
| align = center | Room_Size
|-
| align = center | Open_Window
|-
| align = center | Open_Door
|}

{| border=1 align = center
|-
| ClassRoom instance methods
|-
| align = center | Turn_On_Computer
|-
| align = center | Clean_Blackboard
|}

The ClassRoom class is specific types of Room. The ClassRoom class is inheriting from Room Class, so the new methods Turn_On_Computer and Clean_Blackboard will add to the ClassRoom class. Now ClassRoom class definition can now support all of the messages or methods in Room and the two new messages.

===Overridden method===
Overriding an inherited method is very important way to provide unique behaviors to a class. If an object receives a message which we have a method in the class definition for that massage, the object will work its way up the hierarchy until it finds a method with that name. We cannot delete the inherited methods, if we do not need the method in the superclass, we can provide a method by the same name with the superclass in the subclass with no code in the method. In this way, we can simply replace the behavior of the superclass behavior by no behavior.

==Java==
We can use the inheritance to make the method reimplementation in [http://en.wikipedia.org/wiki/Java Java]. They are similar with the ways we do in Smalltalk, like the overriding and overloading. But in Java, we can define abstract method and virtual method in Java, and it provides a @override tag that prevents the programmer from thinking another method is being overridden when really it is not.

===Overridden method===
If we want to override a method in subclass that inherited from the superclass, we should invoke the superclass method by using the keyword super.
Below is the example:
<pre>
public class Say {
public void express() {
System.out.println(“Hello wolrd!”);
}
}

public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
}
}
</pre>

Class Say represents the superclass and implements a method call express (). The subclass called Shout will inherit all the methods which in the Say class. But the class Shout will override the method express in Shout class, and replace it with new action.

<pre>
Say hello_say = new Say();
hello_say.express(); // Prints “Hello wolrd!”

Say hello_shout = new Shout(); //Polymorphism
hello_shout.express(); //Prints “Hello wolrd, loudly!”
</pre>

The super can be used to call the superclass's method; we can modify the class in class Shout to make the method express call another express method which in superclass Say.

<pre>
public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
Super.express(); //will call the express method in class Say
}
}
</pre>

But some of the methods cannot be overridden. For example, in Java, a method that is declared final in the super class cannot be overridden, and the method declared private or static cannot be overridden too. We cannot make a class that that is declared final to become a super class too.

===Overloaded method===

Java supports method overloading which allows the creation of several methods with the same method name, but different in their types of input and output of the function.
We can define two methods with the same name in Java:

<pre>
int Add(int a, int b) {
return a + b;}

float Add(float a, float b) {
return a + b;}
</pre>

The two methods have the same method name in define. To call the methods, we should pass the parameters to the methods above. When we call Add(1,1) it will call the first method Add(int a, int b), because we pass two int types of the parameters to the method Add. And if we call Add(1.0,1.0) it will call the second method Add(float a, float b) because we pass the float types of the parameters to the method Add. But if we give these two methods parameters a, b with default value, it will cause an error, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two methods to use.

===Abstract Method===
Abstract method: When a class contains an abstract method, that class must be declared as abstract. The abstract method has no implementation and thus, classes that derive from that abstract class, must provide an implementation for this abstract method.

Abstract method are the method that with no body specification. Subclasses must provide the method statements to fulfill the abstract method. Especially, if the method was one provided by the superclass, we should override them in each subclass. If we forgot to override that will cause some problem like that the applied method statement may be inappropriate.
Below is the abstract method example, we need to define the abstract method in subclass to reimplementation the method.

<pre>
public abstract class Vehicle // class is abstract
{
private String name;
public Vehicle (String nm) // constructor method
{ name=nm; }
public String getName() // regular method
{ return (name); }
public abstract void run(); // abstract method - note no {}
}
</pre>

===Virtual Method===

Virtual method: A class can have a virtual method. The virtual method has an implementation. When you inherit from a class that has a virtual method, you can override the virtual method and provide additional logic, or replace the logic with your own implementation.
A virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature.
In java, all the non-static methods with the default type “virtual function”. But if the methods marked with the keyword final, which cannot be overridden. The private methods are non-virtual which cannot be inherited.
Below is the example for Virtual Method:

<pre>
public class toy
{
public void say()
{
System.out.println(“I am toy.”);
}

public static void main(String[] args)
{
List<toy> toys = new LinkedList<toy>();

toys.add(new toy());
toys.add(new toy_man());
toys.add(new toy_car());

for(toy current_toy : toys)
{
current_toy.say();
}
}
}

public class toy_man extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_man.”);
}
}

public class toy_car extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_car.”);
}
}
</pre>

The output will be:
I am toy.
I am toy_man.
I am toy_car.

===Interfaces===
In java interfaces are very similar with the abstract classes but all the methods in interfaces are abstract and all properties are static final. As the abstract classes, interfaces also can be inherited. And we also use the extends keywords too. Different from C++, in Java we cannot use the multiple inheritances for class, which means that a subclass extends from more than one superclass. An interface can tie elements of several classes together, and it also can separate design from coding as class method headers are specified but not their body.
For example we build a running interface for the subclasses of Vehicle. Because there is a method called stop(), we should define the method in any class which using the running interface.

<pre>
public interface running
{
public void stop();
}
</pre>

When we create a class that will use the interface, we should use the keywords implements which will follow one or more interface list.

<pre>
public class Vehicle_Run extends Vehicle implements running
{
public Vehicle_Run (String nm)
{
super(nm); // builds ala parent
}
public void run ()
{
System.out.println("I am running.");
}
public void stop () // this method specific to Vehicle_Run
{
System.out.println("I stop.");
}
}
</pre>

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is very similar with Java in method overriding and method overloading. The method overloading of C++ we can refer the method overloading in Java. But they have difference in method overriding between C++ and Java.

===Overridden method===
C++ does not provide the keyword super that a subclass can use in Java to invoke a superclass version of a method that it wants to override. But in C++ we can use the base class follow with the scope resolution operator to override the superclass method.
Below is the example:
<pre>
class Toy {
public:
Toy(char* nm, int s):name(name),size(s){}
virtual void print() const;
private:
char* name;
int size;
};

void Toy::print() const{ // print() method of base class
std::cout<<”Name = ” << this->name << “; Size = ” << this->size;
}

class Toy_car: public Toy {
public:
Toy_car(char * nm, int s, int t) : Toy(nm,s), type(t) {}
virtual void print() const;

private:
int type;
};

void Toy_car::print() const{
Toy::print();
Std::cout<<”; Type = ” << this-> type;
}
</pre>

The main method will call the print method in class Toy and class Toy_car separately.
<pre>
Int main(int argc, char** argv) {
Toy toy_test(“Jack”, 9);
Toy_test.print();
//outputs:
//Name = Jack; Size = 9

Toy_car toy_car_test(“Ann”,”7”,”1”);
//the pointer to the most overridden method in the vtable in on Toy_car::print
toy_car_test.print();// but this call does not illustrate overriding
static_cast<Toy&>(toy_car_test).print(); // this one does
//output
// Name = Jack; Size = 9;Type = 1
}
</pre>

===Virtual Method===

In C++ we declare the virtual method by add the virtual keyword before the function’s declaration. The concept of the virtual method is nearly the same with that in Java, but the function in C++ is not default by “virtual function”.
Below is the example of virtual method in C++.

<pre>
class Toy {
public:
virtual void say() const {
std::cout << “I am Toy.” << std::endl;
}
};

class Toy_car : public Toy{
public:
void say() const {
std::cout << “I am Toy_car.” << std::endl;
}
};

class Toy_man : public Toy{
public:
void say() const {
std::cout << “I am Toy_man.” << std::endl;
}
};

int main() {
std::vector<Toy*> toys;
toys.push_back(new Toy()) ;
toys.push_back(new Toy_car()) ;
toys.push_back(new Toy_man()) ;

for(std::vector<Toy*>::const_iterator it = toys.begin() ; it != toys.end(); ++it){
(*it)->say();
delete *it;
}

return 0;
}
</pre>

The output will be:
I am Toy.
I am Toy_car.
I am Toy_man.

If we do not declare Toy::say() as virtual, the result will be:
I am Toy.
I am Toy.
I am Toy.

==Ruby==

Different with Java and C, [http://en.wikipedia.org/wiki/Ruby Ruby] is a dynamic Object-orientated Language. It allows default parameter and variable parameter used in the method. Therefore, there is no strict classification of overridden method and overloaded method.

=== Method with default parameter===
With the code below, we can better understand this concept:

<pre>
def sum( x, y, z=1 )
x+y+z
end

puts sum(10,20,30)
puts sum(5.0,10)
</pre>

Output:
60
16.0

<pre>
def sum( *num )
totalSum =0
num.each { |i| totalSum+=i }
return totalSum
end

puts sum(1,10,100)
puts sum(2.2,3.3,4.4)
puts sum()
</pre>

Output:
111
9.9
0

From the output we can see Ruby allow default parameter regardless the number and the type of parameter. Unlike the limitation in other static OO language, Ruby can dynamically execute codes in runtime. Therefore, the reimplementation in Ruby become less important compared with other static languages. Several ways can be used for method reimplementation in Ruby. For example, just simply extend classes. Or re-declare an existing class with new methods. To better demonstrate how these two approaches work, we use the code example as below:

=== Method extended from class===

<pre>
class Animal
attr_accessor:voice
def initialize(v)
puts "This is an animal."
self.voice=v
end

def speak
puts "This animal can speak"+self.voice
end
end

class Dog<Animal
end

d=Dog.new(" bow-wow!!")
d.speak
</pre>

The output of this code is
This is an animal.
This animal can speak bow-wow!!

As we can see, we just simply create a descendant class Dog and use the default method in the ancestor class Animal. The dog can bark as “bow-wow”, so we use the voice parameter to make it particular for dog.

=== New method in the descendant class===

Also, we can change the code of descendant class Dog since every dog can bark. Code shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end

d=Dog.new
d.speak
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow

As we can see, the first line of the result is changed since we change the initialize in Dog class. And we do not need to define how the dog bark in the follow code since it has been defined in the Dog class. To further improve the code of this example, we can rewrite the Dog class again to make the speak method more specific. Codes shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
i am a dog and i can speak like this: bow-wow
As we can found in the result, the speak method is revised. This result is exclusive for describing dog.

If we just want to improve the functionality of the method in an ancestor class instead of rewriting it, we can use the keyword super in the code. Code for example is shown below:
<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
super
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow
i am a dog and i can speak like this: bow-wow

From the result, we can see that both the speak methods in Animal class and Dog class are used.

=Advantages and disadvantages of each languages applying method reimplementation=
==Smalltalk==
Advantages:
It is a very flexible program language. It allows any method to be overridden, so we can be very convenient to get the method we want by overridden.

Disadvantages:
Sometimes we do not require some methods in Smalltalk, but we still can override the methods which no longer need them.

==Java==
Advantages:
Java support the overriding methods, overloading methods, abstract methods, virtual methods, interfaces which make java be one of the top popular programming language today. We can reimplementation the methods by use the overriding and overloading methods. Abstract methods and virtual methods make the hierarchy structure colorful and clear. The interfaces of Java help to make some design patterns implementation easily. For example when we use the Strategy pattern, which clearly indicates a place in the design that will change, we should define the strategy as an interface.

Disadvantages:
Java does not support the multiple inheritances. Compared with C++ which supports the multiple inheritances, C++ can provide more flexible way and more clear structure in class inheritance, which makes C++ sometimes a better choice for reimplementation methods in descendant classes.

==C++==
Advantages:
C++ provide the multiple inheritance which makes C++ much more flexible in reimplementation the methods. With the multiple inheritances, it makes some of the design patterns work better. One benefit from it is Adapter pattern: it uses multiple inheritances to adapt one interface to another. This pattern usually used to provide implementation for an abstract class (when you want to use an existing class and its interface is not appropriate, so you need to glue another interface with that class).

The scope resolution operator in C++ is powerful enough. We can put the definition of the class in one file and use the scope resolution operator to implement the method in another file, which will make the whole structure more clear and it will help to add new method, overriding method, overloading method much easier.

With the keywords “virtual” we can make the virtual method in C++ much more flexible. From the above examples you can see that the “virtual” keywords it helps us easy to fulfill the polymorphism, makes the program much more efficiently.

Disadvantages:
The multiple inheritances help us easy to reimplementation the method in subclass. But sometimes it causes some problems. With multiple inheritances, it makes the hierarchy of the program very complex. The programmers need to more time know the details of each base class. It will cause problem when using multiple inheritance is the diamond problem, which occurs when two classes are derived from a base class and another class is obtained by joining the derived classes together. If the derived classes override the same method from the base class when calling the method from the merged class and the joining class does also override that method, an ambiguity will rise. Another problem is that if two classes derived from the same base class. When we use these two classes to make multiple inheritance, it would make some base members duplicated.

==Ruby==
Advantages:
Java and C++, both as static OO languages, use overload and overridden methods in polymorphism to extend the flexibility of programming, since the property and method of class cannot be changed during the runtime. Compared with Java and C++, Ruby, as a dynamic OO language, allows change of property and method in the class in the runtime. For this reason, the method reimplementation becomes less essential as that in Java and C++. Ruby does not require using complicated mechanism to define the methods for disambiguation. Thus, Ruby is considered has better performance in reducing code and providing concise program.

Disadvantages:
The disadvantage of Rudy, to some extent, also results from its dynamic characteristic. It become unsafe and unreliable compared with static typing OO language. For example, method in Ruby does not care about the type of parameter. It may cause problem when the type of parameter is essential for some application. Ruby cannot identify this wrong type error made by programmer.

=Conclusion=
Reimplementation of methods is one of the most essential features in Object-Oriented language. It expands the flexibility of polymorphism in which descendant class can define their own behaviors and functions more efficiently. There are different ways for various languages to define how to reuse methods. In details, we use codes of Smalltalk, Java, C++ and Ruby to demonstrate and analysis how methods are reused, following with the discussion of advantages and disadvantages of method reuse in these four languages.

= References =
*[1]:http://en.wikipedia.org/wiki/Method_(computer_programming)
*[2]:http://www.wisegeek.com/what-is-an-abstract-method.htm
*[3]:http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap6.html
*[4]:http://en.wikipedia.org/wiki/Function_overloading
*[5]:http://home.cogeco.ca/~ve3ll/jatutor5.htm
*[6]:http://en.wikipedia.org/wiki/Virtual_function#Java
*[7]:http://rubylearning.com/satishtalim/ruby_overloading_methods.html
*[8]:http://rubylearning.com/satishtalim/writing_own_ruby_methods.html
*[9]:http://learnruby.com/about-ruby.html
*[10]:http://www.pluitsolutions.com/2006/10/05/overriding-methods-in-ruby/

CSC/ECE 517 Fall 2011/ch1 1i zf

2011-09-07T03:59:49Z

Xfang2: /* Ruby */

CSC/ECE 517 Fall 2010/ch1 1i zf
----
= Introduction =
In [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented languages], method is a subroutine which associates with the instances of the class to define the specific behavior of this class. In the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] of these languages, methods reimplementation is essential because descendant class inherited from the ancestor class in which properties and method have been defined to some extent. With the method reimplementation, coding can be more efficient and simple without rewriting the same code again and agian. However, in different OO languages, the ways of acquiring or allowing method reimplementation are significantly different. In this article, we are going to introduce these differences and provide code for better understanding.

= Principle of method reimplementation in descendant class =
Method reimplementation is various in different OO languages according to their own programming rules and complier environments. And it also associated with inheritance between ancestor class and descendant class. Several terms of method are listed below.

==Abstract method==
[http://en.wikipedia.org/wiki/Abstract_method Abstract method] is a method only has name but little or no implementation in the ancestor class, which must be also an abstract class. In most of the case, codes in abstract method are considered dummy but it does not mean useless. In fact, it provides a place for descendant class which inherited from the ancestor class to define specific behaviors and actions.

For example, a toy company develops an ancestor class called “animal” which contains “dog”, “bird” and “fish” as its descendant classes. These subclasses have same characteristic such as color, size, price and behavior like move, speak. Here we use the abstract methods for move and speak so that the subclasses can define their own behaviors which act differently.

==Virtual method==
Virtual method, or [http://en.wikipedia.org/wiki/Virtual_method virtual function], is the method that first declared or defined in the ancestor class and then completed defined in the descendant class. Based on the functionality in the subclasses, virtual method can be simply defined or overridden with details. In a virtual method in which only has the name but no implementation, we call this as pure virtual method, as known as abstract method introduced above.

==Overridden method==
[http://en.wikipedia.org/wiki/Method_overriding Overridden method], as mentioned in virtual method, is used in OO language involving inheritance hierarchy. It allows descendant classes to redefine the method in their ancestor class with more details and particular purposes. “Override” means the implementation in subclasses rewrites or redefines the original implementation of the method in their super class without changing the name, parameter and return type. To better demonstrate how overridden method work, we take the toy company example again. In the behavior aspect of “animal”, we have the method call “move”. In this method, we know it define the same of movement for all the animals. However, the way of movement among “dog”, “bird” and “fish” are different. Thus, in “dog” class, we may redefine the detail in move method as “I use leg”; in “bird” class, the detail of move method is “I use wings”; and in “fish” class, the detail of move method is “I use fin”.

==Overloaded method==
[http://en.wikipedia.org/wiki/Method_overload Overloaded method] means that method share the same name with other method but may be different in other aspects such as parameter, number of parameter and data type.
And the correct method will be executed automatically during the runtime depends on how it is called.

= Method reimplementation in different languages =

==Smalltalk==
In [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] language, we can use the inheritance to reimplementation the methods. Inheritance is very useful in Smalltalk which makes the Smalltalk language reusability and extensibility.
There are two ways to modify the behavior of the methods in Smalltalk by inheritance. One is adding new methods and the other is overriding the inherited method.

===Adding Methods===
Adding new method is very simple; we can add either instance or class methods, to the class definition. The following diagrams show how the adding method works:

{| border=1 align = center
|+ClassRoom’s Methods
|-
| Room instance methods
|-
| align = center | Room_Number
|-
| align = center | Room_Size
|-
| align = center | Open_Window
|-
| align = center | Open_Door
|}

{| border=1 align = center
|-
| ClassRoom instance methods
|-
| align = center | Turn_On_Computer
|-
| align = center | Clean_Blackboard
|}

The ClassRoom class is specific types of Room. The ClassRoom class is inheriting from Room Class, so the new methods Turn_On_Computer and Clean_Blackboard will add to the ClassRoom class. Now ClassRoom class definition can now support all of the messages or methods in Room and the two new messages.

===Overridden method===
Overriding an inherited method is very important way to provide unique behaviors to a class. If an object receives a message which we have a method in the class definition for that massage, the object will work its way up the hierarchy until it finds a method with that name. We cannot delete the inherited methods, if we do not need the method in the superclass, we can provide a method by the same name with the superclass in the subclass with no code in the method. In this way, we can simply replace the behavior of the superclass behavior by no behavior.

==Java==
We can use the inheritance to make the method reimplementation in [http://en.wikipedia.org/wiki/Java Java]. They are similar with the ways we do in Smalltalk, like the overriding and overloading. But in Java, we can define abstract method and virtual method in Java, and it provides a @override tag that prevents the programmer from thinking another method is being overridden when really it is not.

===Overridden method===
If we want to override a method in subclass that inherited from the superclass, we should invoke the superclass method by using the keyword super.
Below is the example:
<pre>
public class Say {
public void express() {
System.out.println(“Hello wolrd!”);
}
}

public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
}
}
</pre>

Class Say represents the superclass and implements a method call express (). The subclass called Shout will inherit all the methods which in the Say class. But the class Shout will override the method express in Shout class, and replace it with new action.

<pre>
Say hello_say = new Say();
hello_say.express(); // Prints “Hello wolrd!”

Say hello_shout = new Shout(); //Polymorphism
hello_shout.express(); //Prints “Hello wolrd, loudly!”
</pre>

The super can be used to call the superclass's method; we can modify the class in class Shout to make the method express call another express method which in superclass Say.

<pre>
public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
Super.express(); //will call the express method in class Say
}
}
</pre>

But some of the methods cannot be overridden. For example, in Java, a method that is declared final in the super class cannot be overridden, and the method declared private or static cannot be overridden too. We cannot make a class that that is declared final to become a super class too.

===Overloaded method===

Java supports method overloading which allows the creation of several methods with the same method name, but different in their types of input and output of the function.
We can define two methods with the same name in Java:

<pre>
int Add(int a, int b) {
return a + b;}

float Add(float a, float b) {
return a + b;}
</pre>

The two methods have the same method name in define. To call the methods, we should pass the parameters to the methods above. When we call Add(1,1) it will call the first method Add(int a, int b), because we pass two int types of the parameters to the method Add. And if we call Add(1.0,1.0) it will call the second method Add(float a, float b) because we pass the float types of the parameters to the method Add. But if we give these two methods parameters a, b with default value, it will cause an error, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two methods to use.

===Abstract Method===
Abstract method: When a class contains an abstract method, that class must be declared as abstract. The abstract method has no implementation and thus, classes that derive from that abstract class, must provide an implementation for this abstract method.

Abstract method are the method that with no body specification. Subclasses must provide the method statements to fulfill the abstract method. Especially, if the method was one provided by the superclass, we should override them in each subclass. If we forgot to override that will cause some problem like that the applied method statement may be inappropriate.
Below is the abstract method example, we need to define the abstract method in subclass to reimplementation the method.

<pre>
public abstract class Vehicle // class is abstract
{
private String name;
public Vehicle (String nm) // constructor method
{ name=nm; }
public String getName() // regular method
{ return (name); }
public abstract void run(); // abstract method - note no {}
}
</pre>

===Virtual Method===

Virtual method: A class can have a virtual method. The virtual method has an implementation. When you inherit from a class that has a virtual method, you can override the virtual method and provide additional logic, or replace the logic with your own implementation.
A virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature.
In java, all the non-static methods with the default type “virtual function”. But if the methods marked with the keyword final, which cannot be overridden. The private methods are non-virtual which cannot be inherited.
Below is the example for Virtual Method:

<pre>
public class toy
{
public void say()
{
System.out.println(“I am toy.”);
}

public static void main(String[] args)
{
List<toy> toys = new LinkedList<toy>();

toys.add(new toy());
toys.add(new toy_man());
toys.add(new toy_car());

for(toy current_toy : toys)
{
current_toy.say();
}
}
}

public class toy_man extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_man.”);
}
}

public class toy_car extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_car.”);
}
}
</pre>

The output will be:
I am toy.
I am toy_man.
I am toy_car.

===Interfaces===
In java interfaces are very similar with the abstract classes but all the methods in interfaces are abstract and all properties are static final. As the abstract classes, interfaces also can be inherited. And we also use the extends keywords too. Different from C++, in Java we cannot use the multiple inheritances for class, which means that a subclass extends from more than one superclass. An interface can tie elements of several classes together, and it also can separate design from coding as class method headers are specified but not their body.
For example we build a running interface for the subclasses of Vehicle. Because there is a method called stop(), we should define the method in any class which using the running interface.

<pre>
public interface running
{
public void stop();
}
</pre>

When we create a class that will use the interface, we should use the keywords implements which will follow one or more interface list.

<pre>
public class Vehicle_Run extends Vehicle implements running
{
public Vehicle_Run (String nm)
{
super(nm); // builds ala parent
}
public void run ()
{
System.out.println("I am running.");
}
public void stop () // this method specific to Vehicle_Run
{
System.out.println("I stop.");
}
}
</pre>

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is very similar with Java in method overriding and method overloading. The method overloading of C++ we can refer the method overloading in Java. But they have difference in method overriding between C++ and Java.

===Overridden method===
C++ does not provide the keyword super that a subclass can use in Java to invoke a superclass version of a method that it wants to override. But in C++ we can use the base class follow with the scope resolution operator to override the superclass method.
Below is the example:
<pre>
class Toy {
public:
Toy(char* nm, int s):name(name),size(s){}
virtual void print() const;
private:
char* name;
int size;
};

void Toy::print() const{ // print() method of base class
std::cout<<”Name = ” << this->name << “; Size = ” << this->size;
}

class Toy_car: public Toy {
public:
Toy_car(char * nm, int s, int t) : Toy(nm,s), type(t) {}
virtual void print() const;

private:
int type;
};

void Toy_car::print() const{
Toy::print();
Std::cout<<”; Type = ” << this-> type;
}
</pre>

The main method will call the print method in class Toy and class Toy_car separately.
<pre>
Int main(int argc, char** argv) {
Toy toy_test(“Jack”, 9);
Toy_test.print();
//outputs:
//Name = Jack; Size = 9

Toy_car toy_car_test(“Ann”,”7”,”1”);
//the pointer to the most overridden method in the vtable in on Toy_car::print
toy_car_test.print();// but this call does not illustrate overriding
static_cast<Toy&>(toy_car_test).print(); // this one does
//output
// Name = Jack; Size = 9;Type = 1
}
</pre>

===Virtual Method===

In C++ we declare the virtual method by add the virtual keyword before the function’s declaration. The concept of the virtual method is nearly the same with that in Java, but the function in C++ is not default by “virtual function”.
Below is the example of virtual method in C++.

<pre>
class Toy {
public:
virtual void say() const {
std::cout << “I am Toy.” << std::endl;
}
};

class Toy_car : public Toy{
public:
void say() const {
std::cout << “I am Toy_car.” << std::endl;
}
};

class Toy_man : public Toy{
public:
void say() const {
std::cout << “I am Toy_man.” << std::endl;
}
};

int main() {
std::vector<Toy*> toys;
toys.push_back(new Toy()) ;
toys.push_back(new Toy_car()) ;
toys.push_back(new Toy_man()) ;

for(std::vector<Toy*>::const_iterator it = toys.begin() ; it != toys.end(); ++it){
(*it)->say();
delete *it;
}

return 0;
}
</pre>

The output will be:
I am Toy.
I am Toy_car.
I am Toy_man.

If we do not declare Toy::say() as virtual, the result will be:
I am Toy.
I am Toy.
I am Toy.

==Ruby==

Different with Java and C, [http://en.wikipedia.org/wiki/Ruby Ruby] is a dynamic Object-orientated Language. It allows default parameter and variable parameter used in the method. Therefore, there is no strict classification of overridden method and overloaded method.

=== Method with default parameter===
With the code below, we can better understand this concept:

<pre>
def sum( x, y, z=1 )
x+y+z
end

puts sum(10,20,30)
puts sum(5.0,10)
</pre>

Output:
60
16.0

<pre>
def sum( *num )
totalSum =0
num.each { |i| totalSum+=i }
return totalSum
end

puts sum(1,10,100)
puts sum(2.2,3.3,4.4)
puts sum()
</pre>

Output:
111
9.9
0

From the output we can see Ruby allow default parameter regardless the number and the type of parameter. Unlike the limitation in other static OO language, Ruby can dynamically execute codes in runtime. Therefore, the reimplementation in Ruby become less important compared with other static languages. Several ways can be used for method reimplementation in Ruby. For example, just simply extend classes. Or re-declare an existing class with new methods. To better demonstrate how these two approaches work, we use the code example as below:

=== Method extended from class===

<pre>
class Animal
attr_accessor:voice
def initialize(v)
puts "This is an animal."
self.voice=v
end

def speak
puts "This animal can speak"+self.voice
end
end

class Dog<Animal
end

d=Dog.new(" bow-wow!!")
d.speak
</pre>

The output of this code is
This is an animal.
This animal can speak bow-wow!!

As we can see, we just simply create a descendant class Dog and use the default method in the ancestor class Animal. The dog can bark as “bow-wow”, so we use the voice parameter to make it particular for dog.

=== New method in the descendant class===

Also, we can change the code of descendant class Dog since every dog can bark. Code shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end

d=Dog.new
d.speak
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow

As we can see, the first line of the result is changed since we change the initialize in Dog class. And we do not need to define how the dog bark in the follow code since it has been defined in the Dog class. To further improve the code of this example, we can rewrite the Dog class again to make the speak method more specific. Codes shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
i am a dog and i can speak like this: bow-wow
As we can found in the result, the speak method is revised. This result is exclusive for describing dog.

If we just want to improve the functionality of the method in an ancestor class instead of rewriting it, we can use the keyword super in the code. Code for example is shown below:
<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
super
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow
i am a dog and i can speak like this: bow-wow

From the result, we can see that both the speak methods in Animal class and Dog class are used.

=Advantages and disadvantages of each languages applying method reimplementation=
==Smalltalk==
Advantages:
It is a very flexible program language. It allows any method to be overridden, so we can be very convenient to get the method we want by overridden.

Disadvantages:
Sometimes we do not require some methods in Smalltalk, but we still can override the methods which no longer need them.

==Java==
Advantages:
Java support the overriding methods, overloading methods, abstract methods, virtual methods, interfaces which make java be one of the top popular programming language today. We can reimplementation the methods by use the overriding and overloading methods. Abstract methods and virtual methods make the hierarchy structure colorful and clear. The interfaces of Java help to make some design patterns implementation easily. For example when we use the Strategy pattern, which clearly indicates a place in the design that will change, we should define the strategy as an interface.

Disadvantages:
Java does not support the multiple inheritances. Compared with C++ which supports the multiple inheritances, C++ can provide more flexible way and more clear structure in class inheritance, which makes C++ sometimes a better choice for reimplementation methods in descendant classes.

==C++==
Advantages:
C++ provide the multiple inheritance which makes C++ much more flexible in reimplementation the methods. With the multiple inheritances, it makes some of the design patterns work better. One benefit from it is Adapter pattern: it uses multiple inheritances to adapt one interface to another. This pattern usually used to provide implementation for an abstract class (when you want to use an existing class and its interface is not appropriate, so you need to glue another interface with that class).

The scope resolution operator in C++ is powerful enough. We can put the definition of the class in one file and use the scope resolution operator to implement the method in another file, which will make the whole structure more clear and it will help to add new method, overriding method, overloading method much easier.

With the keywords “virtual” we can make the virtual method in C++ much more flexible. From the above examples you can see that the “virtual” keywords it helps us easy to fulfill the polymorphism, makes the program much more efficiently.

Disadvantages:
The multiple inheritances help us easy to reimplementation the method in subclass. But sometimes it causes some problems. With multiple inheritances, it makes the hierarchy of the program very complex. The programmers need to more time know the details of each base class. It will cause problem when using multiple inheritance is the diamond problem, which occurs when two classes are derived from a base class and another class is obtained by joining the derived classes together. If the derived classes override the same method from the base class when calling the method from the merged class and the joining class does also override that method, an ambiguity will rise. Another problem is that if two classes derived from the same base class. When we use these two classes to make multiple inheritance, it would make some base members duplicated.

==Ruby==
Advantages:
Java and C++, both as static OO languages, use overload and overridden methods in polymorphism to extend the flexibility of programming, since the property and method of class cannot be changed during the runtime. Compared with Java and C++, Ruby, as a dynamic OO language, allows change of property and method in the class in the runtime. For this reason, the method reimplementation becomes less essential as that in Java and C++. Ruby does not require using complicated mechanism to define the methods for disambiguation. Thus, Ruby is considered has better performance in reducing code and providing concise program.

Disadvantages:
The disadvantage of Rudy, to some extent, also results from its dynamic characteristic. It become unsafe and unreliable compared with static typing OO language. For example, method in Ruby does not care about the type of parameter. It may cause problem when the type of parameter is essential for some application. Ruby cannot identify this wrong type error made by programmer.

=Conclusion=
Reimplementation of methods is one of the most essential features in Object-Oriented language. It expands the flexibility of polymorphism in which descendant class can define their own behaviors and functions more efficiently. There are different ways for various languages to define how to reuse methods. In details, we use codes of Smalltalk, Java, C++ and Ruby to demonstrate and analysis how methods are reused, following with the discussion of advantages and disadvantages of method reuse in these four languages.

= References =
*[1]:http://en.wikipedia.org/wiki/Method_(computer_programming)
*[2]:http://www.wisegeek.com/what-is-an-abstract-method.htm
*[3]:http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap6.html
*[4]:http://en.wikipedia.org/wiki/Function_overloading
*[5]:http://home.cogeco.ca/~ve3ll/jatutor5.htm
*[6]:http://en.wikipedia.org/wiki/Virtual_function#Java
*[7]:http://rubylearning.com/satishtalim/ruby_overloading_methods.html
*[8]:http://rubylearning.com/satishtalim/writing_own_ruby_methods.html
*[9]:http://learnruby.com/about-ruby.html
*[10]:http://www.pluitsolutions.com/2006/10/05/overriding-methods-in-ruby/

CSC/ECE 517 Fall 2011/ch1 1i zf

2011-09-07T03:58:32Z

Xfang2: /* Ruby */

CSC/ECE 517 Fall 2010/ch1 1i zf
----
= Introduction =
In [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented languages], method is a subroutine which associates with the instances of the class to define the specific behavior of this class. In the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] of these languages, methods reimplementation is essential because descendant class inherited from the ancestor class in which properties and method have been defined to some extent. With the method reimplementation, coding can be more efficient and simple without rewriting the same code again and agian. However, in different OO languages, the ways of acquiring or allowing method reimplementation are significantly different. In this article, we are going to introduce these differences and provide code for better understanding.

= Principle of method reimplementation in descendant class =
Method reimplementation is various in different OO languages according to their own programming rules and complier environments. And it also associated with inheritance between ancestor class and descendant class. Several terms of method are listed below.

==Abstract method==
[http://en.wikipedia.org/wiki/Abstract_method Abstract method] is a method only has name but little or no implementation in the ancestor class, which must be also an abstract class. In most of the case, codes in abstract method are considered dummy but it does not mean useless. In fact, it provides a place for descendant class which inherited from the ancestor class to define specific behaviors and actions.

For example, a toy company develops an ancestor class called “animal” which contains “dog”, “bird” and “fish” as its descendant classes. These subclasses have same characteristic such as color, size, price and behavior like move, speak. Here we use the abstract methods for move and speak so that the subclasses can define their own behaviors which act differently.

==Virtual method==
Virtual method, or [http://en.wikipedia.org/wiki/Virtual_method virtual function], is the method that first declared or defined in the ancestor class and then completed defined in the descendant class. Based on the functionality in the subclasses, virtual method can be simply defined or overridden with details. In a virtual method in which only has the name but no implementation, we call this as pure virtual method, as known as abstract method introduced above.

==Overridden method==
[http://en.wikipedia.org/wiki/Method_overriding Overridden method], as mentioned in virtual method, is used in OO language involving inheritance hierarchy. It allows descendant classes to redefine the method in their ancestor class with more details and particular purposes. “Override” means the implementation in subclasses rewrites or redefines the original implementation of the method in their super class without changing the name, parameter and return type. To better demonstrate how overridden method work, we take the toy company example again. In the behavior aspect of “animal”, we have the method call “move”. In this method, we know it define the same of movement for all the animals. However, the way of movement among “dog”, “bird” and “fish” are different. Thus, in “dog” class, we may redefine the detail in move method as “I use leg”; in “bird” class, the detail of move method is “I use wings”; and in “fish” class, the detail of move method is “I use fin”.

==Overloaded method==
[http://en.wikipedia.org/wiki/Method_overload Overloaded method] means that method share the same name with other method but may be different in other aspects such as parameter, number of parameter and data type.
And the correct method will be executed automatically during the runtime depends on how it is called.

= Method reimplementation in different languages =

==Smalltalk==
In [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] language, we can use the inheritance to reimplementation the methods. Inheritance is very useful in Smalltalk which makes the Smalltalk language reusability and extensibility.
There are two ways to modify the behavior of the methods in Smalltalk by inheritance. One is adding new methods and the other is overriding the inherited method.

===Adding Methods===
Adding new method is very simple; we can add either instance or class methods, to the class definition. The following diagrams show how the adding method works:

{| border=1 align = center
|+ClassRoom’s Methods
|-
| Room instance methods
|-
| align = center | Room_Number
|-
| align = center | Room_Size
|-
| align = center | Open_Window
|-
| align = center | Open_Door
|}

{| border=1 align = center
|-
| ClassRoom instance methods
|-
| align = center | Turn_On_Computer
|-
| align = center | Clean_Blackboard
|}

The ClassRoom class is specific types of Room. The ClassRoom class is inheriting from Room Class, so the new methods Turn_On_Computer and Clean_Blackboard will add to the ClassRoom class. Now ClassRoom class definition can now support all of the messages or methods in Room and the two new messages.

===Overridden method===
Overriding an inherited method is very important way to provide unique behaviors to a class. If an object receives a message which we have a method in the class definition for that massage, the object will work its way up the hierarchy until it finds a method with that name. We cannot delete the inherited methods, if we do not need the method in the superclass, we can provide a method by the same name with the superclass in the subclass with no code in the method. In this way, we can simply replace the behavior of the superclass behavior by no behavior.

==Java==
We can use the inheritance to make the method reimplementation in [http://en.wikipedia.org/wiki/Java Java]. They are similar with the ways we do in Smalltalk, like the overriding and overloading. But in Java, we can define abstract method and virtual method in Java, and it provides a @override tag that prevents the programmer from thinking another method is being overridden when really it is not.

===Overridden method===
If we want to override a method in subclass that inherited from the superclass, we should invoke the superclass method by using the keyword super.
Below is the example:
<pre>
public class Say {
public void express() {
System.out.println(“Hello wolrd!”);
}
}

public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
}
}
</pre>

Class Say represents the superclass and implements a method call express (). The subclass called Shout will inherit all the methods which in the Say class. But the class Shout will override the method express in Shout class, and replace it with new action.

<pre>
Say hello_say = new Say();
hello_say.express(); // Prints “Hello wolrd!”

Say hello_shout = new Shout(); //Polymorphism
hello_shout.express(); //Prints “Hello wolrd, loudly!”
</pre>

The super can be used to call the superclass's method; we can modify the class in class Shout to make the method express call another express method which in superclass Say.

<pre>
public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
Super.express(); //will call the express method in class Say
}
}
</pre>

But some of the methods cannot be overridden. For example, in Java, a method that is declared final in the super class cannot be overridden, and the method declared private or static cannot be overridden too. We cannot make a class that that is declared final to become a super class too.

===Overloaded method===

Java supports method overloading which allows the creation of several methods with the same method name, but different in their types of input and output of the function.
We can define two methods with the same name in Java:

<pre>
int Add(int a, int b) {
return a + b;}

float Add(float a, float b) {
return a + b;}
</pre>

The two methods have the same method name in define. To call the methods, we should pass the parameters to the methods above. When we call Add(1,1) it will call the first method Add(int a, int b), because we pass two int types of the parameters to the method Add. And if we call Add(1.0,1.0) it will call the second method Add(float a, float b) because we pass the float types of the parameters to the method Add. But if we give these two methods parameters a, b with default value, it will cause an error, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two methods to use.

===Abstract Method===
Abstract method: When a class contains an abstract method, that class must be declared as abstract. The abstract method has no implementation and thus, classes that derive from that abstract class, must provide an implementation for this abstract method.

Abstract method are the method that with no body specification. Subclasses must provide the method statements to fulfill the abstract method. Especially, if the method was one provided by the superclass, we should override them in each subclass. If we forgot to override that will cause some problem like that the applied method statement may be inappropriate.
Below is the abstract method example, we need to define the abstract method in subclass to reimplementation the method.

<pre>
public abstract class Vehicle // class is abstract
{
private String name;
public Vehicle (String nm) // constructor method
{ name=nm; }
public String getName() // regular method
{ return (name); }
public abstract void run(); // abstract method - note no {}
}
</pre>

===Virtual Method===

Virtual method: A class can have a virtual method. The virtual method has an implementation. When you inherit from a class that has a virtual method, you can override the virtual method and provide additional logic, or replace the logic with your own implementation.
A virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature.
In java, all the non-static methods with the default type “virtual function”. But if the methods marked with the keyword final, which cannot be overridden. The private methods are non-virtual which cannot be inherited.
Below is the example for Virtual Method:

<pre>
public class toy
{
public void say()
{
System.out.println(“I am toy.”);
}

public static void main(String[] args)
{
List<toy> toys = new LinkedList<toy>();

toys.add(new toy());
toys.add(new toy_man());
toys.add(new toy_car());

for(toy current_toy : toys)
{
current_toy.say();
}
}
}

public class toy_man extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_man.”);
}
}

public class toy_car extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_car.”);
}
}
</pre>

The output will be:
I am toy.
I am toy_man.
I am toy_car.

===Interfaces===
In java interfaces are very similar with the abstract classes but all the methods in interfaces are abstract and all properties are static final. As the abstract classes, interfaces also can be inherited. And we also use the extends keywords too. Different from C++, in Java we cannot use the multiple inheritances for class, which means that a subclass extends from more than one superclass. An interface can tie elements of several classes together, and it also can separate design from coding as class method headers are specified but not their body.
For example we build a running interface for the subclasses of Vehicle. Because there is a method called stop(), we should define the method in any class which using the running interface.

<pre>
public interface running
{
public void stop();
}
</pre>

When we create a class that will use the interface, we should use the keywords implements which will follow one or more interface list.

<pre>
public class Vehicle_Run extends Vehicle implements running
{
public Vehicle_Run (String nm)
{
super(nm); // builds ala parent
}
public void run ()
{
System.out.println("I am running.");
}
public void stop () // this method specific to Vehicle_Run
{
System.out.println("I stop.");
}
}
</pre>

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is very similar with Java in method overriding and method overloading. The method overloading of C++ we can refer the method overloading in Java. But they have difference in method overriding between C++ and Java.

===Overridden method===
C++ does not provide the keyword super that a subclass can use in Java to invoke a superclass version of a method that it wants to override. But in C++ we can use the base class follow with the scope resolution operator to override the superclass method.
Below is the example:
<pre>
class Toy {
public:
Toy(char* nm, int s):name(name),size(s){}
virtual void print() const;
private:
char* name;
int size;
};

void Toy::print() const{ // print() method of base class
std::cout<<”Name = ” << this->name << “; Size = ” << this->size;
}

class Toy_car: public Toy {
public:
Toy_car(char * nm, int s, int t) : Toy(nm,s), type(t) {}
virtual void print() const;

private:
int type;
};

void Toy_car::print() const{
Toy::print();
Std::cout<<”; Type = ” << this-> type;
}
</pre>

The main method will call the print method in class Toy and class Toy_car separately.
<pre>
Int main(int argc, char** argv) {
Toy toy_test(“Jack”, 9);
Toy_test.print();
//outputs:
//Name = Jack; Size = 9

Toy_car toy_car_test(“Ann”,”7”,”1”);
//the pointer to the most overridden method in the vtable in on Toy_car::print
toy_car_test.print();// but this call does not illustrate overriding
static_cast<Toy&>(toy_car_test).print(); // this one does
//output
// Name = Jack; Size = 9;Type = 1
}
</pre>

===Virtual Method===

In C++ we declare the virtual method by add the virtual keyword before the function’s declaration. The concept of the virtual method is nearly the same with that in Java, but the function in C++ is not default by “virtual function”.
Below is the example of virtual method in C++.

<pre>
class Toy {
public:
virtual void say() const {
std::cout << “I am Toy.” << std::endl;
}
};

class Toy_car : public Toy{
public:
void say() const {
std::cout << “I am Toy_car.” << std::endl;
}
};

class Toy_man : public Toy{
public:
void say() const {
std::cout << “I am Toy_man.” << std::endl;
}
};

int main() {
std::vector<Toy*> toys;
toys.push_back(new Toy()) ;
toys.push_back(new Toy_car()) ;
toys.push_back(new Toy_man()) ;

for(std::vector<Toy*>::const_iterator it = toys.begin() ; it != toys.end(); ++it){
(*it)->say();
delete *it;
}

return 0;
}
</pre>

The output will be:
I am Toy.
I am Toy_car.
I am Toy_man.

If we do not declare Toy::say() as virtual, the result will be:
I am Toy.
I am Toy.
I am Toy.

==Ruby==

Different with Java and C, [http://en.wikipedia.org/wiki/Ruby Ruby] is a dynamic Object-orientated Language. It allows default parameter and variable parameter used in the method. Therefore, there is no strict classification of overridden method and overloaded method.

=== Method with default parameter===
With the code below, we can better understand this concept:

<pre>
def sum( x, y, z=1 )
x+y+z
end
puts sum(10,20,30)
puts sum(5.0,10)
</pre>

Output:
60
16.0

<pre>
def sum( *num )
totalSum = 0
num.each { |i| totalSum+=i }
return totalSum
end
puts sum(1,10,100)
puts sum(2.2,3.3,4.4)
puts sum()
</pre>

Output:
111
9.9
0

From the output we can see Ruby allow default parameter regardless the number and the type of parameter. Unlike the limitation in other static OO language, Ruby can dynamically execute codes in runtime. Therefore, the reimplementation in Ruby become less important compared with other static languages. Several ways can be used for method reimplementation in Ruby. For example, just simply extend classes. Or re-declare an existing class with new methods. To better demonstrate how these two approaches work, we use the code example as below:

=== Method extended from class===

<pre>
class Animal
attr_accessor:voice
def initialize(v)
puts "This is an animal."
self.voice=v
end

def speak
puts "This animal can speak"+self.voice
end
end

class Dog<Animal
end

d=Dog.new(" bow-wow!!")
d.speak
</pre>

The output of this code is
This is an animal.
This animal can speak bow-wow!!

As we can see, we just simply create a descendant class Dog and use the default method in the ancestor class Animal. The dog can bark as “bow-wow”, so we use the voice parameter to make it particular for dog.

=== New method in the descendant class===

Also, we can change the code of descendant class Dog since every dog can bark. Code shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end

d=Dog.new
d.speak
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow

As we can see, the first line of the result is changed since we change the initialize in Dog class. And we do not need to define how the dog bark in the follow code since it has been defined in the Dog class. To further improve the code of this example, we can rewrite the Dog class again to make the speak method more specific. Codes shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
i am a dog and i can speak like this: bow-wow
As we can found in the result, the speak method is revised. This result is exclusive for describing dog.

If we just want to improve the functionality of the method in an ancestor class instead of rewriting it, we can use the keyword super in the code. Code for example is shown below:
<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
super
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow
i am a dog and i can speak like this: bow-wow

From the result, we can see that both the speak methods in Animal class and Dog class are used.

=Advantages and disadvantages of each languages applying method reimplementation=
==Smalltalk==
Advantages:
It is a very flexible program language. It allows any method to be overridden, so we can be very convenient to get the method we want by overridden.

Disadvantages:
Sometimes we do not require some methods in Smalltalk, but we still can override the methods which no longer need them.

==Java==
Advantages:
Java support the overriding methods, overloading methods, abstract methods, virtual methods, interfaces which make java be one of the top popular programming language today. We can reimplementation the methods by use the overriding and overloading methods. Abstract methods and virtual methods make the hierarchy structure colorful and clear. The interfaces of Java help to make some design patterns implementation easily. For example when we use the Strategy pattern, which clearly indicates a place in the design that will change, we should define the strategy as an interface.

Disadvantages:
Java does not support the multiple inheritances. Compared with C++ which supports the multiple inheritances, C++ can provide more flexible way and more clear structure in class inheritance, which makes C++ sometimes a better choice for reimplementation methods in descendant classes.

==C++==
Advantages:
C++ provide the multiple inheritance which makes C++ much more flexible in reimplementation the methods. With the multiple inheritances, it makes some of the design patterns work better. One benefit from it is Adapter pattern: it uses multiple inheritances to adapt one interface to another. This pattern usually used to provide implementation for an abstract class (when you want to use an existing class and its interface is not appropriate, so you need to glue another interface with that class).

The scope resolution operator in C++ is powerful enough. We can put the definition of the class in one file and use the scope resolution operator to implement the method in another file, which will make the whole structure more clear and it will help to add new method, overriding method, overloading method much easier.

With the keywords “virtual” we can make the virtual method in C++ much more flexible. From the above examples you can see that the “virtual” keywords it helps us easy to fulfill the polymorphism, makes the program much more efficiently.

Disadvantages:
The multiple inheritances help us easy to reimplementation the method in subclass. But sometimes it causes some problems. With multiple inheritances, it makes the hierarchy of the program very complex. The programmers need to more time know the details of each base class. It will cause problem when using multiple inheritance is the diamond problem, which occurs when two classes are derived from a base class and another class is obtained by joining the derived classes together. If the derived classes override the same method from the base class when calling the method from the merged class and the joining class does also override that method, an ambiguity will rise. Another problem is that if two classes derived from the same base class. When we use these two classes to make multiple inheritance, it would make some base members duplicated.

==Ruby==
Advantages:
Java and C++, both as static OO languages, use overload and overridden methods in polymorphism to extend the flexibility of programming, since the property and method of class cannot be changed during the runtime. Compared with Java and C++, Ruby, as a dynamic OO language, allows change of property and method in the class in the runtime. For this reason, the method reimplementation becomes less essential as that in Java and C++. Ruby does not require using complicated mechanism to define the methods for disambiguation. Thus, Ruby is considered has better performance in reducing code and providing concise program.

Disadvantages:
The disadvantage of Rudy, to some extent, also results from its dynamic characteristic. It become unsafe and unreliable compared with static typing OO language. For example, method in Ruby does not care about the type of parameter. It may cause problem when the type of parameter is essential for some application. Ruby cannot identify this wrong type error made by programmer.

=Conclusion=
Reimplementation of methods is one of the most essential features in Object-Oriented language. It expands the flexibility of polymorphism in which descendant class can define their own behaviors and functions more efficiently. There are different ways for various languages to define how to reuse methods. In details, we use codes of Smalltalk, Java, C++ and Ruby to demonstrate and analysis how methods are reused, following with the discussion of advantages and disadvantages of method reuse in these four languages.

= References =
*[1]:http://en.wikipedia.org/wiki/Method_(computer_programming)
*[2]:http://www.wisegeek.com/what-is-an-abstract-method.htm
*[3]:http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap6.html
*[4]:http://en.wikipedia.org/wiki/Function_overloading
*[5]:http://home.cogeco.ca/~ve3ll/jatutor5.htm
*[6]:http://en.wikipedia.org/wiki/Virtual_function#Java
*[7]:http://rubylearning.com/satishtalim/ruby_overloading_methods.html
*[8]:http://rubylearning.com/satishtalim/writing_own_ruby_methods.html
*[9]:http://learnruby.com/about-ruby.html
*[10]:http://www.pluitsolutions.com/2006/10/05/overriding-methods-in-ruby/

CSC/ECE 517 Fall 2011/ch1 1i zf

2011-09-07T03:57:49Z

Xfang2: /* C++ */

CSC/ECE 517 Fall 2010/ch1 1i zf
----
= Introduction =
In [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented languages], method is a subroutine which associates with the instances of the class to define the specific behavior of this class. In the [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance] of these languages, methods reimplementation is essential because descendant class inherited from the ancestor class in which properties and method have been defined to some extent. With the method reimplementation, coding can be more efficient and simple without rewriting the same code again and agian. However, in different OO languages, the ways of acquiring or allowing method reimplementation are significantly different. In this article, we are going to introduce these differences and provide code for better understanding.

= Principle of method reimplementation in descendant class =
Method reimplementation is various in different OO languages according to their own programming rules and complier environments. And it also associated with inheritance between ancestor class and descendant class. Several terms of method are listed below.

==Abstract method==
[http://en.wikipedia.org/wiki/Abstract_method Abstract method] is a method only has name but little or no implementation in the ancestor class, which must be also an abstract class. In most of the case, codes in abstract method are considered dummy but it does not mean useless. In fact, it provides a place for descendant class which inherited from the ancestor class to define specific behaviors and actions.

For example, a toy company develops an ancestor class called “animal” which contains “dog”, “bird” and “fish” as its descendant classes. These subclasses have same characteristic such as color, size, price and behavior like move, speak. Here we use the abstract methods for move and speak so that the subclasses can define their own behaviors which act differently.

==Virtual method==
Virtual method, or [http://en.wikipedia.org/wiki/Virtual_method virtual function], is the method that first declared or defined in the ancestor class and then completed defined in the descendant class. Based on the functionality in the subclasses, virtual method can be simply defined or overridden with details. In a virtual method in which only has the name but no implementation, we call this as pure virtual method, as known as abstract method introduced above.

==Overridden method==
[http://en.wikipedia.org/wiki/Method_overriding Overridden method], as mentioned in virtual method, is used in OO language involving inheritance hierarchy. It allows descendant classes to redefine the method in their ancestor class with more details and particular purposes. “Override” means the implementation in subclasses rewrites or redefines the original implementation of the method in their super class without changing the name, parameter and return type. To better demonstrate how overridden method work, we take the toy company example again. In the behavior aspect of “animal”, we have the method call “move”. In this method, we know it define the same of movement for all the animals. However, the way of movement among “dog”, “bird” and “fish” are different. Thus, in “dog” class, we may redefine the detail in move method as “I use leg”; in “bird” class, the detail of move method is “I use wings”; and in “fish” class, the detail of move method is “I use fin”.

==Overloaded method==
[http://en.wikipedia.org/wiki/Method_overload Overloaded method] means that method share the same name with other method but may be different in other aspects such as parameter, number of parameter and data type.
And the correct method will be executed automatically during the runtime depends on how it is called.

= Method reimplementation in different languages =

==Smalltalk==
In [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] language, we can use the inheritance to reimplementation the methods. Inheritance is very useful in Smalltalk which makes the Smalltalk language reusability and extensibility.
There are two ways to modify the behavior of the methods in Smalltalk by inheritance. One is adding new methods and the other is overriding the inherited method.

===Adding Methods===
Adding new method is very simple; we can add either instance or class methods, to the class definition. The following diagrams show how the adding method works:

{| border=1 align = center
|+ClassRoom’s Methods
|-
| Room instance methods
|-
| align = center | Room_Number
|-
| align = center | Room_Size
|-
| align = center | Open_Window
|-
| align = center | Open_Door
|}

{| border=1 align = center
|-
| ClassRoom instance methods
|-
| align = center | Turn_On_Computer
|-
| align = center | Clean_Blackboard
|}

The ClassRoom class is specific types of Room. The ClassRoom class is inheriting from Room Class, so the new methods Turn_On_Computer and Clean_Blackboard will add to the ClassRoom class. Now ClassRoom class definition can now support all of the messages or methods in Room and the two new messages.

===Overridden method===
Overriding an inherited method is very important way to provide unique behaviors to a class. If an object receives a message which we have a method in the class definition for that massage, the object will work its way up the hierarchy until it finds a method with that name. We cannot delete the inherited methods, if we do not need the method in the superclass, we can provide a method by the same name with the superclass in the subclass with no code in the method. In this way, we can simply replace the behavior of the superclass behavior by no behavior.

==Java==
We can use the inheritance to make the method reimplementation in [http://en.wikipedia.org/wiki/Java Java]. They are similar with the ways we do in Smalltalk, like the overriding and overloading. But in Java, we can define abstract method and virtual method in Java, and it provides a @override tag that prevents the programmer from thinking another method is being overridden when really it is not.

===Overridden method===
If we want to override a method in subclass that inherited from the superclass, we should invoke the superclass method by using the keyword super.
Below is the example:
<pre>
public class Say {
public void express() {
System.out.println(“Hello wolrd!”);
}
}

public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
}
}
</pre>

Class Say represents the superclass and implements a method call express (). The subclass called Shout will inherit all the methods which in the Say class. But the class Shout will override the method express in Shout class, and replace it with new action.

<pre>
Say hello_say = new Say();
hello_say.express(); // Prints “Hello wolrd!”

Say hello_shout = new Shout(); //Polymorphism
hello_shout.express(); //Prints “Hello wolrd, loudly!”
</pre>

The super can be used to call the superclass's method; we can modify the class in class Shout to make the method express call another express method which in superclass Say.

<pre>
public class Shout extends Say {
@Override // @Override annotation in Java 5 is optional but helpful.
public void express() {
System.out.println(“Hello wolrd, loudly! ”);
Super.express(); //will call the express method in class Say
}
}
</pre>

But some of the methods cannot be overridden. For example, in Java, a method that is declared final in the super class cannot be overridden, and the method declared private or static cannot be overridden too. We cannot make a class that that is declared final to become a super class too.

===Overloaded method===

Java supports method overloading which allows the creation of several methods with the same method name, but different in their types of input and output of the function.
We can define two methods with the same name in Java:

<pre>
int Add(int a, int b) {
return a + b;}

float Add(float a, float b) {
return a + b;}
</pre>

The two methods have the same method name in define. To call the methods, we should pass the parameters to the methods above. When we call Add(1,1) it will call the first method Add(int a, int b), because we pass two int types of the parameters to the method Add. And if we call Add(1.0,1.0) it will call the second method Add(float a, float b) because we pass the float types of the parameters to the method Add. But if we give these two methods parameters a, b with default value, it will cause an error, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two methods to use.

===Abstract Method===
Abstract method: When a class contains an abstract method, that class must be declared as abstract. The abstract method has no implementation and thus, classes that derive from that abstract class, must provide an implementation for this abstract method.

Abstract method are the method that with no body specification. Subclasses must provide the method statements to fulfill the abstract method. Especially, if the method was one provided by the superclass, we should override them in each subclass. If we forgot to override that will cause some problem like that the applied method statement may be inappropriate.
Below is the abstract method example, we need to define the abstract method in subclass to reimplementation the method.

<pre>
public abstract class Vehicle // class is abstract
{
private String name;
public Vehicle (String nm) // constructor method
{ name=nm; }
public String getName() // regular method
{ return (name); }
public abstract void run(); // abstract method - note no {}
}
</pre>

===Virtual Method===

Virtual method: A class can have a virtual method. The virtual method has an implementation. When you inherit from a class that has a virtual method, you can override the virtual method and provide additional logic, or replace the logic with your own implementation.
A virtual method is a function or method whose behavior can be overridden within an inheriting class by a function with the same signature.
In java, all the non-static methods with the default type “virtual function”. But if the methods marked with the keyword final, which cannot be overridden. The private methods are non-virtual which cannot be inherited.
Below is the example for Virtual Method:

<pre>
public class toy
{
public void say()
{
System.out.println(“I am toy.”);
}

public static void main(String[] args)
{
List<toy> toys = new LinkedList<toy>();

toys.add(new toy());
toys.add(new toy_man());
toys.add(new toy_car());

for(toy current_toy : toys)
{
current_toy.say();
}
}
}

public class toy_man extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_man.”);
}
}

public class toy_car extends toy
{
@Override
public void say()
{
System.out.println(“I am toy_car.”);
}
}
</pre>

The output will be:
I am toy.
I am toy_man.
I am toy_car.

===Interfaces===
In java interfaces are very similar with the abstract classes but all the methods in interfaces are abstract and all properties are static final. As the abstract classes, interfaces also can be inherited. And we also use the extends keywords too. Different from C++, in Java we cannot use the multiple inheritances for class, which means that a subclass extends from more than one superclass. An interface can tie elements of several classes together, and it also can separate design from coding as class method headers are specified but not their body.
For example we build a running interface for the subclasses of Vehicle. Because there is a method called stop(), we should define the method in any class which using the running interface.

<pre>
public interface running
{
public void stop();
}
</pre>

When we create a class that will use the interface, we should use the keywords implements which will follow one or more interface list.

<pre>
public class Vehicle_Run extends Vehicle implements running
{
public Vehicle_Run (String nm)
{
super(nm); // builds ala parent
}
public void run ()
{
System.out.println("I am running.");
}
public void stop () // this method specific to Vehicle_Run
{
System.out.println("I stop.");
}
}
</pre>

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is very similar with Java in method overriding and method overloading. The method overloading of C++ we can refer the method overloading in Java. But they have difference in method overriding between C++ and Java.

===Overridden method===
C++ does not provide the keyword super that a subclass can use in Java to invoke a superclass version of a method that it wants to override. But in C++ we can use the base class follow with the scope resolution operator to override the superclass method.
Below is the example:
<pre>
class Toy {
public:
Toy(char* nm, int s):name(name),size(s){}
virtual void print() const;
private:
char* name;
int size;
};

void Toy::print() const{ // print() method of base class
std::cout<<”Name = ” << this->name << “; Size = ” << this->size;
}

class Toy_car: public Toy {
public:
Toy_car(char * nm, int s, int t) : Toy(nm,s), type(t) {}
virtual void print() const;

private:
int type;
};

void Toy_car::print() const{
Toy::print();
Std::cout<<”; Type = ” << this-> type;
}
</pre>

The main method will call the print method in class Toy and class Toy_car separately.
<pre>
Int main(int argc, char** argv) {
Toy toy_test(“Jack”, 9);
Toy_test.print();
//outputs:
//Name = Jack; Size = 9

Toy_car toy_car_test(“Ann”,”7”,”1”);
//the pointer to the most overridden method in the vtable in on Toy_car::print
toy_car_test.print();// but this call does not illustrate overriding
static_cast<Toy&>(toy_car_test).print(); // this one does
//output
// Name = Jack; Size = 9;Type = 1
}
</pre>

===Virtual Method===

In C++ we declare the virtual method by add the virtual keyword before the function’s declaration. The concept of the virtual method is nearly the same with that in Java, but the function in C++ is not default by “virtual function”.
Below is the example of virtual method in C++.

<pre>
class Toy {
public:
virtual void say() const {
std::cout << “I am Toy.” << std::endl;
}
};

class Toy_car : public Toy{
public:
void say() const {
std::cout << “I am Toy_car.” << std::endl;
}
};

class Toy_man : public Toy{
public:
void say() const {
std::cout << “I am Toy_man.” << std::endl;
}
};

int main() {
std::vector<Toy*> toys;
toys.push_back(new Toy()) ;
toys.push_back(new Toy_car()) ;
toys.push_back(new Toy_man()) ;

for(std::vector<Toy*>::const_iterator it = toys.begin() ; it != toys.end(); ++it){
(*it)->say();
delete *it;
}

return 0;
}
</pre>

The output will be:
I am Toy.
I am Toy_car.
I am Toy_man.

If we do not declare Toy::say() as virtual, the result will be:
I am Toy.
I am Toy.
I am Toy.

==Ruby==

Different with Java and C, Ruby is a dynamic Object-orientated Language. It allows default parameter and variable parameter used in the method. Therefore, there is no strict classification of overridden method and overloaded method.

=== Method with default parameter===
With the code below, we can better understand this concept:

<pre>
def sum( x, y, z=1 )
x+y+z
end
puts sum(10,20,30)
puts sum(5.0,10)
</pre>

Output:
60
16.0

<pre>
def sum( *num )
totalSum = 0
num.each { |i| totalSum+=i }
return totalSum
end
puts sum(1,10,100)
puts sum(2.2,3.3,4.4)
puts sum()
</pre>

Output:
111
9.9
0

From the output we can see Ruby allow default parameter regardless the number and the type of parameter. Unlike the limitation in other static OO language, Ruby can dynamically execute codes in runtime. Therefore, the reimplementation in Ruby become less important compared with other static languages. Several ways can be used for method reimplementation in Ruby. For example, just simply extend classes. Or re-declare an existing class with new methods. To better demonstrate how these two approaches work, we use the code example as below:

=== Method extended from class===

<pre>
class Animal
attr_accessor:voice
def initialize(v)
puts "This is an animal."
self.voice=v
end

def speak
puts "This animal can speak"+self.voice
end
end

class Dog<Animal
end

d=Dog.new(" bow-wow!!")
d.speak
</pre>

The output of this code is
This is an animal.
This animal can speak bow-wow!!

As we can see, we just simply create a descendant class Dog and use the default method in the ancestor class Animal. The dog can bark as “bow-wow”, so we use the voice parameter to make it particular for dog.

=== New method in the descendant class===

Also, we can change the code of descendant class Dog since every dog can bark. Code shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end

d=Dog.new
d.speak
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow

As we can see, the first line of the result is changed since we change the initialize in Dog class. And we do not need to define how the dog bark in the follow code since it has been defined in the Dog class. To further improve the code of this example, we can rewrite the Dog class again to make the speak method more specific. Codes shown below:

<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
i am a dog and i can speak like this: bow-wow
As we can found in the result, the speak method is revised. This result is exclusive for describing dog.

If we just want to improve the functionality of the method in an ancestor class instead of rewriting it, we can use the keyword super in the code. Code for example is shown below:
<pre>
class Dog<Animal
def initialize
puts "This is a dog."
self.voice=" bow-wow"
end
def speak
super
puts "i am a dog and i can speak like this:"+self.voice
end
end
</pre>

The output of this code is
This is a dog.
This animal can speak bow-wow
i am a dog and i can speak like this: bow-wow

From the result, we can see that both the speak methods in Animal class and Dog class are used.

=Advantages and disadvantages of each languages applying method reimplementation=
==Smalltalk==
Advantages:
It is a very flexible program language. It allows any method to be overridden, so we can be very convenient to get the method we want by overridden.

Disadvantages:
Sometimes we do not require some methods in Smalltalk, but we still can override the methods which no longer need them.

==Java==
Advantages:
Java support the overriding methods, overloading methods, abstract methods, virtual methods, interfaces which make java be one of the top popular programming language today. We can reimplementation the methods by use the overriding and overloading methods. Abstract methods and virtual methods make the hierarchy structure colorful and clear. The interfaces of Java help to make some design patterns implementation easily. For example when we use the Strategy pattern, which clearly indicates a place in the design that will change, we should define the strategy as an interface.

Disadvantages:
Java does not support the multiple inheritances. Compared with C++ which supports the multiple inheritances, C++ can provide more flexible way and more clear structure in class inheritance, which makes C++ sometimes a better choice for reimplementation methods in descendant classes.

==C++==
Advantages:
C++ provide the multiple inheritance which makes C++ much more flexible in reimplementation the methods. With the multiple inheritances, it makes some of the design patterns work better. One benefit from it is Adapter pattern: it uses multiple inheritances to adapt one interface to another. This pattern usually used to provide implementation for an abstract class (when you want to use an existing class and its interface is not appropriate, so you need to glue another interface with that class).

The scope resolution operator in C++ is powerful enough. We can put the definition of the class in one file and use the scope resolution operator to implement the method in another file, which will make the whole structure more clear and it will help to add new method, overriding method, overloading method much easier.

With the keywords “virtual” we can make the virtual method in C++ much more flexible. From the above examples you can see that the “virtual” keywords it helps us easy to fulfill the polymorphism, makes the program much more efficiently.

Disadvantages:
The multiple inheritances help us easy to reimplementation the method in subclass. But sometimes it causes some problems. With multiple inheritances, it makes the hierarchy of the program very complex. The programmers need to more time know the details of each base class. It will cause problem when using multiple inheritance is the diamond problem, which occurs when two classes are derived from a base class and another class is obtained by joining the derived classes together. If the derived classes override the same method from the base class when calling the method from the merged class and the joining class does also override that method, an ambiguity will rise. Another problem is that if two classes derived from the same base class. When we use these two classes to make multiple inheritance, it would make some base members duplicated.

==Ruby==
Advantages:
Java and C++, both as static OO languages, use overload and overridden methods in polymorphism to extend the flexibility of programming, since the property and method of class cannot be changed during the runtime. Compared with Java and C++, Ruby, as a dynamic OO language, allows change of property and method in the class in the runtime. For this reason, the method reimplementation becomes less essential as that in Java and C++. Ruby does not require using complicated mechanism to define the methods for disambiguation. Thus, Ruby is considered has better performance in reducing code and providing concise program.

Disadvantages:
The disadvantage of Rudy, to some extent, also results from its dynamic characteristic. It become unsafe and unreliable compared with static typing OO language. For example, method in Ruby does not care about the type of parameter. It may cause problem when the type of parameter is essential for some application. Ruby cannot identify this wrong type error made by programmer.

=Conclusion=
Reimplementation of methods is one of the most essential features in Object-Oriented language. It expands the flexibility of polymorphism in which descendant class can define their own behaviors and functions more efficiently. There are different ways for various languages to define how to reuse methods. In details, we use codes of Smalltalk, Java, C++ and Ruby to demonstrate and analysis how methods are reused, following with the discussion of advantages and disadvantages of method reuse in these four languages.

= References =
*[1]:http://en.wikipedia.org/wiki/Method_(computer_programming)
*[2]:http://www.wisegeek.com/what-is-an-abstract-method.htm
*[3]:http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap6.html
*[4]:http://en.wikipedia.org/wiki/Function_overloading
*[5]:http://home.cogeco.ca/~ve3ll/jatutor5.htm
*[6]:http://en.wikipedia.org/wiki/Virtual_function#Java
*[7]:http://rubylearning.com/satishtalim/ruby_overloading_methods.html
*[8]:http://rubylearning.com/satishtalim/writing_own_ruby_methods.html
*[9]:http://learnruby.com/about-ruby.html
*[10]:http://www.pluitsolutions.com/2006/10/05/overriding-methods-in-ruby/