// Public
public $variable;
public function doSomething() {
  // ...
}

// Private
private $variable;
private function doSomething() {
  // ...
}

// Protected
protected $variable;
protected function doSomething() {
  // ...
}

• public scope to make that variable/function available from anywhere, other classes and instances of the object.
• private scope when you want your variable/function to be visible in its own class only.
• protected scope when you want to make your variable/function visible in all classes that extend current class including the parent class.

• http://php.net/manual/en/language.oop5.visibility.php

public function CheckUsername($connection, $username)
{
    try
    {
        $data = array();
        $data['Username'] = $username;

        //// SQL
        $sql = "SELECT Username FROM" . $this->usersTableName . " WHERE Username = :Username";

        //// Execute statement
        return $this->ExecuteObject($connection, $sql, $data);
    }
    catch(Exception $e)
    {
        throw $e;
    }
}

Answer:

     _{Disclaimer: the following is a description of how I understand MVC-like patterns in the context of PHP-based web applications. All the external links that are used in the content are there to explain terms and concepts, and not to imply my own credibility on the subject.}

What a model is NOT:

What a model is:

• Domain Objects

       A domain object is a logical container of purely domain information; it usually represents a logical entity in the problem domain space. Commonly referred to as business logic.

  This would be where you define how to validate data before sending an invoice, or to compute the total cost of an order. At the same time, Domain Objects are completely unaware of storage - neither from where (SQL database, REST API, text file, etc.) nor even if they get saved or retrieved.
• Data Mappers
  These objects are only responsible for the storage. If you store information in a database, this would be where the SQL lives. Or maybe you use an XML file to store data, and your Data Mappers are parsing from and to XML files.
• Services
  You can think of them as "higher level Domain Objects", but instead of business logic, Services are responsible for interaction between Domain Objects and Mappers. These structures end up creating a "public" interface for interacting with the domain business logic. You can avoid them, but at the penalty of leaking some domain logic into Controllers.
  There is a related answer to this subject in the ACL implementation question - it might be useful.

How to interact with a model?

      _{Prerequisites: watch lectures "Global State and Singletons" and "Don't Look For Things!" from the Clean Code Talks.}

• it helps to enforce the single responsibility principle (SRP)
• provides additional 'wiggle room' in case the logic changes
• keeps the controller as simple as possible
• gives a clear blueprint, if you ever need an external API

/*
 * Closure for providing lazy initialization of DB connection
 */
$dbhProvider = function() {
    $instance = new \PDO('mysql:host=localhost;dbname=******;charset=UTF-8', 
    '**username**', '**password**');
    $instance->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $instance->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
    return $instance;
};

/* 
 * Creates basic structures, which will be used for 
 * interaction with model layer
 */
$serviceFactory = new ServiceFactory(
    new DataMapperFactory($dbhProvider),
    new DomainObjectFactory
    );
$serviceFactory->setDefaultNamespace('Application\\Service');

/*
 * Initializes the routing mechanism
 */
$configuration = json_decode(
    file_get_contents(__DIR__ . '/config/routes.json'), true);
$router = new Router(new RouteBuilder);
$router->import($configuration);

/*
 * Gets the part of URI after the "?" symbol
 */
$uri = isset($_SERVER['REQUEST_URI']) 
           ? $_SERVER['REQUEST_URI'] 
           : '/';

/*
 * Initializes the request/response abstraction and 
 * applies routing patterns to that instance
 */
$request = new Request($uri);
$response = new Response;
$router->route($request);

/* 
 * Initialization of View 
 */
$class = '\\Application\\View\\' . $request->getResourceName();
$view = new $class($serviceFactory);
$view->setDefaultTemplateLocation(__DIR__ . '/templates');

/*
 * Initialization of Controller
 */
$class = '\\Application\\Controller\\' . $request->getResourceName();
$controller = new $class($serviceFactory);

/*
 * Execute the necessary command on the controller
 */
$command = $request->getCommand();
$controller->{$command}($request);

/*
 * Produces the response
 */
$view->{$command}($response)
echo $view->render();

       _{Note: this code is geared towards a project, where you don't have proper dependency injection container. A much better implementation would have the DI container (like Auryn) to create controllers and views, with only the required services, instead of using a factory.}

How to build the model?

An example of a service method:

namespace Service;

class Recognitions
{
    // -- snip --

    /* This is an EXAMPLE, not a production-level code.
       Do not copy-paste! */
    public function authenticate( $username, $password )
    {
        $account = $this->domainObjectFactory->build('User');
        $mapper  = $this->dataMapperFactory->build('User');

        $account->setUsername( $username );
        $mapper->fetch( $account );

        if ( $account->matchPassword($password) )
        {
            $state = $this->dataMapperFactory->build('Cookie');
        }
        else
        {
            $state = $this->dataMapperFactory->build('Session');
        }

        $state->store($account);

    }
    // -- snip --
}

Some additional comments:

1. Database tables and model
   While sometimes there is a direct 1:1:1 relationship between a database table, Domain Object, and Mapper, in larger projects it might be less common than you expect:
   • Information used by a single Domain Object might be mapped from different tables, while the object itself has no persistence in the database.
     Example: if you are generating a monthly report. This would collect information from different of tables, but there is no magical MonthlyReport table in the database.
   • A single Mapper can affect multiple tables.
     Example: when you are storing data from the User object, this Domain Object could contain collection of other domain objects - Group instances. If you alter them and store the User, the Data Mapper will have to update and/or insert entries in multiple tables.
   • Data from a single Domain Object is stored in more than one table.
     Example: in large systems (think: a medium-sized social network), it might be pragmatic to store user authentication data and often-accessed data separately from larger chunks of content, which is rarely required. In that case you might still have a single User class, but the information it contains would depend of whether full details were fetched.
2. A view is not a template
   View instances in MVC (if you are not using the MVP variation of the pattern) are responsible for the presentational logic. This means that each View will usually juggle at least a few templates. It acquires data from the Model Layer and then, based on the received information, chooses a template and sets values.
   One of the benefits you gain from this is re-usability. If you create a ListView class, then, with well-written code, you can have the same class handing the presentation of user-list and comments below an article. Because they both have the same presentation logic. You just switch templates.
   You can use either native PHP templates or use some third-party templating engine. There also might be some third-party libraries, which are able to fully replace View instances.
3. What about the old version of the answer?
   The only major change is that, what is called Model in the old version, is actually a Service. The rest of the "library analogy" keeps up pretty well.
   The only flaw that I see is that this would be a really strange library, because it would return you information from the book, but not let you touch the book itself, because otherwise the abstraction would start to "leak". I might have to think of a more fitting analogy.
4. What is the relationship between View and Controller instances?
   The MVC structure is composed of two layers: presentation and model. The main structures in the Presentation layer are views and controller.
   When you are dealing with websites that use MVC design pattern, the best way is to have 1:1 relation between views and controllers. Each view represents a whole page in your website and it has a dedicated controller to handle all the incoming requests for that particular view.
   For example, to represent an opened article, you would have \Application\Controller\Document and \Application\View\Document. This would contain all the main functionality for presentation layer, when it comes to dealing with articles (of course you might have some XHR components that are not directly related to articles).