responsibility of each class and how they interact

I'm trying to draw an class diagram for my project management software describing the following scenario. It contains

project
Manager
Employee

Manager can create project
manager can change project deadline
manager can change project name
manager can assign a employee To Project (single project have only one assigned employee)
employee can submit project

For the above requirements created this Class diagram

and implement it in code using php as shown below

Class Manager {
private $Id;
private $name;
private $selectedProject;

public function __construct($name){
    $this->$name = $name;        
}

//manager create a project
    public function createProject(){            
        $project       = new Project('Web Dev','incomplete','2018/6/18');
        $this->selectedProject = $project;
    }

//manager can change project deadline
    public function updateProjectDeadline($projectDeadline){
        $this->selectedProject->SetProjectDeadline($projectDeadline);
    }

//manager can change project name
    public function updateProjectName($projectName){
        $this->selectedProject->SetProjectDeadline($projectName);
    }

//manager can assign a employee To Project
    public function assignEmployeeToProject(Employee $employee){
        $this->employee = $employee;
        $this->selectedProject->SetProjectEmployee($this->employee);
    }

}

Class Project {
    private $Id;
    private $projectName ;
    private $projectStatus ;
    private $deadline ;
    private $assignedEmployee;

    public function __construct($projectName ,$projectStatus ,$deadline ){
        $this->$projectName  = $projectName ;
        $this->$projectStatus  = $projectStatus ;
        $this->$deadline  = $deadline ;
    }

    public function SetProjectDeadline($deadline ) {
        $this->$deadline  = $deadline ;    
    }
    public function SetProjectEmployee(Employee $employee) {
        $this->$assignedEmployee = $employee;
    }
    public function setProjectStatus($projectStatus ) {
        $this->$projectStatus  = $projectStatus ;    
    }
    public function setProjectName($projectName ) {
        $this->$projectName  = $projectName ;    
    }
}

Class Employee {
    private $empName;
    private $assignedProject;

    public function __construct($empName){
        $this->$empName = $empName;
    }

    //employee can submit project
    public function submitProject(Project $project){
        $this->assignedProject = $project;
        $this->assignedProject->setProjectStatus('submit');
    }
}

I want to know
Is my class diagram correct ?
Is my implementation correct ?

specially implementation of below methods cover good OO Design ?

manager changing the project deadline - updateProjectDeadline()
manager changing project name - updateProjectName()

i feel code smell because in above below only thing done there is calling a setter of another class ....

P.S - another one is it bad practice class access another class setters,getters (call setter ,getter methods of one from another class) ??

In your class diagram the two things that jump out are that you have filled arrow heads (these have no meaning in UML class diagrams -- they either need to be open arrows or a closed arrow that is not filled depending on meaning -- in the diagram below I've added a dependency (dash line arrow) and a basic association (solid line arrow) which could be what you mean). In addition, the diamond in the middle -- this is not a UML class diagram element. Is it a note??

In terms of Object Orientation -- the general principles I assume you know -- encapsulation, abstraction, polymorphism etc. Typically accessor (getter) and mutator (setter) methods are a sign of OO principles being broken, as they tend to mean that another class is manipulating (or is being encouraged to manipulate) the internals of the class in question (i.e. breaks encapsulation). SetEmployee is probably more about asking the Project to allocate one -- so something like Project.Allocate (Employee) or Employee.AllocateTo (Project) might be more meaningful and less likely to encourage encapsulation to be broken.