Ограничения сотрудников

Question

Я пишу программу на C # для управления расписанием. Теперь каждому сотруднику нужна возможность иметь ограничения в своем графике, например:

Салли может работать только в понедельник, среду, пятницу с 9 до 15 часов

.

Билли может работать только во вторник, четверг, воскресенье с 17:00 до 21:00.

Салли может работать только в понедельник, среду, пятницу с 9 до 15 часов. до тех пор, пока она не встретится, и тогда она сможет работать в разное время и в разные дни.

Это некоторые примеры ограничений, которые мне нужно применить к каждому объекту сотрудника. То, что я хотел, было некоторыми предложениями о том, как построить это максимально эффективно и обобщенно. Очевидно, мне нужно будет иметь доступ к этим данным и применять эти ограничения. Например, когда менеджер пытается составить расписание, он должен видеть, что, когда он планирует Салли во вторник в 4, это проблема. Также, как я должен хранить эти данные каждого сотрудника?

Answer 1

Я бы пошел с Rules, используя шаблон стратегии .

public interface Rule
{
    bool Satisfies(Employee employee);
}

public class ScheduleRule : Rule
{
    ScheduleRule(Schedule schedule)
    { ... }

    bool Satisfies(Employee employee)
    {
        // Ensure the employee is available
    }
}

public class HolidayRule : Rule
{
    HolidayRule(Datetime date)
    { ... }

    bool Satisfies(Employee employee)
    {
        // Checks if the employee as volunteered for this holiday
    }
}

Этот шаблон обеспечивает легкую расширяемость и ремонтопригодность.

Информация о доступности (и другая информация, связанная с правилами) может храниться у сотрудника (см. Ответ Майка Джейкоба). Однако он может храниться вместе с сотрудником или в отдельной таблице.

Вы также можете хранить эту информацию о доступности отдельно от сотрудника, если вы ожидаете большой объем информации, связанной с правилами. В этом случае Rules может быть нацелен на другой класс:

...
bool Satisfies(RuleInfo info)
...

Answer 2

как то так:

public class Employee
{
    public string Name { get; set; }
    // other important info

    private List<WorkTime> _availability = new List<WorkTime>();
    public List<WorkTime> Availability
    {
        get { return _availability; }
        internal set { _availability = value; }
    }
}

public class WorkTime
{
    public DayOfWeek Day { get; private set; }
    public int StartHour { get; private set; }
    public int EndHour { get; private set; }

    public WorkTime(DayOfWeek day, int startHour, int endHour)
    {
        // validation here (e.g. day and time range during store hours, start<end, etc.)

        Day = day;
        StartHour = startHour;
        EndHour = endHour;
    }
}

и используйте LINQ (или foreach) для запросов по коллекции сотрудников, а также в доступность каждого сотрудника, чтобы найти кого-то, у кого есть часы, чтобы встретить какую-то смену.

Может также быть полезным для создания некоторой служебной функции (расширений) для сравнения объектов WorkTime на основе ваших бизнес-правил (например, IsAvailable сравнивает два объекта WorkTime и возвращает true, если это один и тот же DoW и перекрытие не менее 4 часов)

и вы, скорее всего, будете хранить это в базе данных, поэтому смоделируйте таблицы с полями, такими как свойства в классах.

Answer 3

У Мартина Фаулера есть интересная статья о повторяющихся календарных событиях и различных подходах, которые вы можете использовать; Я нашел это очень полезным, когда писал что-то подобное:

http://martinfowler.com/apsupp/recurring.pdf

Answer 4

Я сделал нечто похожее на это, и я создал общий интерфейс, а затем создал отдельные реализации для разных сценариев. Интерфейс может иметь проверку IsInSchedule (dateTime). Затем вы можете создавать различные реализации по мере необходимости.

Answer 5

Это аналог проблемы сопоставления графиков , а также может быть смоделировано как Проблема удовлетворения ограничений . Вам может пригодиться NSolver или Cassowary.Net

Answer 6

«Разработайте это максимально эффективно и обобщенно»

Они не являются взаимоисключающими, как таковые, однако эффективными и универсальными - это действительно , которые трудно осуществить, особенно в системе планирования Планирование является нетривиальной проблемой.

Ваш вопрос, вероятно, лучше сформулировать как "Какие книги я должен прочитать, чтобы начать работу над этим?" и / или сделать это вики-сообществом.

Answer 7

Я бы посоветовал дать возможность хранить «перерыв» как конкретные даты с временными диапазонами или как шаблон. Я работал над несколькими системами планирования, которые имели очень сложные способы работы с правилами профсоюзов и доступности сотрудников, и вот как мы справились с этим.

Либо сотрудник говорит, что я хочу, чтобы день X от y до z был легко проверен, либо они могли определить шаблоны, которые они хотели или не хотели (например, я не хочу работать по пятницам), а затем при планировании вы могли проверьте, не нарушает ли их применение к определенной смене установленное правило (выходной) или не соответствует определенному шаблону.

Также, как я должен хранить эти данные каждого сотрудника?

Иметь таблицу для хранения конкретных исключений сотрудника. Я хочу, чтобы день X от y до z выключился. У вас есть сотрудник, дата и промежуток времени. Довольно просто.

Что касается шаблонов, вам нужно придумать схему какого-то типа. И есть типы или что-то.

Таким образом, у вас может быть такой тип, как «шаблон недельного выключения», который будет хранить полные выходные недели, которые могут быть сохранены в виде простой строки, представляющей выходные дни: 1000001. Если предположить, что первый бит - воскресенье, это будет означать выходные по выходным. Затем вы можете сохранить шаблон в виде строки или чего-то еще, а затем на основе определенного типа вы будете знать, как обращаться со строкой.

Это может быть очень сложная или простая проблема, она зависит только от того, сколько настроек вам нужно учесть. Надеюсь, это даст вам достаточно идей, чтобы начать работу.

Автоматическая генерация расписания НАМНОГО сложнее в зависимости от исключений / правил, которые необходимо поддерживать.