• Vermittlung des notwendigen Stoffes
• Hervorhebung der sich daraus ergebenden Vorteile
• Laufende Verwendung, sofern möglich
• Bei Bedarf Diskussion und Gegenüberstellung

• Das Projekt wurde nicht ausreichend spezifiziert. Der Auslöser für das Projekt kennt die genauen Anforderungen, brachte diese jedoch nie vollständig in ein Dokument. Sollte ein Dokument vorhanden sein, findet dieses oft nicht den Weg zum Entwickler. Daher erhält dieser oft unzureichende Informationen, um das Projekt erfolgreich durch zu führen.
• Keine Arbeitspakete. Soll ein Projekt durchgeführt werden, muss eine Analysephase durchlaufen werden. Im Zuge dieser Phase sind Arbeitspakete zu definieren. Diese erleichtern zum Einen die Abgrenzung zu anderen ToDo's und ermöglichen eine Kontrolle. Zeitschätzungen dafür werden sehr oft ebenfalls nicht angegeben. Deswegen gestaltet sich eine Kontrolle schwierig.
• "Drauf-los-Entwicklung". Die Vorgaben sind bekannt und es wird einfach einmal entwickelt. Zukünftige Anforderungen werden nicht in Betracht gezogen, auch wird erst bei der Integration der einzelnen Teile in Erfahrung gebracht, ob diese überhaupt miteinander harmonieren. In den meisten Fällen sind größere Änderungen notwendig.
• Kontrolle. Zum Thema Kontrolle gibt es zwei Wege die hauptsächlich durchschritten werden: Entweder findet keine Kontrolle statt (oder erst ca. 2 Wochen vor Auslieferung) oder es wird versucht das ultimative Kontrollsystem einzuführen. Oft wird hierbei jedoch auf notwendige Vorarbeiten vergessen, wodurch eine Kontrolle gar nicht durchgeführt werden kann (Arbeitspakete in Kombination mit Zeitschätzungen als Beispiel).
• Ressourcen-Planung. Ressourcen müssen geplant werden. Freie Kapazitäten sollten vor Annahme eines Projektes bekannt sein. Ebenso sollte bekannt sein, dass eventuell zwischenzeitlich Ressourcen für andere Projekte abgestellt werden müssen - und zu welchem Umfang. Viele Teams werden von plötzlicher Ressourcen-Knappheit überrascht, da plötzlich Entwickler zu anderen Projekten abgezogen werden müssen. Es gilt daher eine saubere Ressourcen-Planung durch zu führen und - wenn notwendig - frühzeitig für Ausgleich zu sorgen.
• Der fehlende Architekt. Nicht jeder Softwareentwickler ist zum Architekten geboren. Großes Wissen und viel Erfahrung ist notwendig, um zukunftssichere Grundgerüste zu entwickeln. Gerade kleine Teams haben oft keinen "gelernten" Architekten zur Verfügung. In diesem Fall kommt es für die meisten Projekte billiger, sich zumindest für das Grundgerüst eine entsprechende Person zu zu kaufen.

Design

Implementierung

public abstract class Command
{
    public abstract void Execute();

    public abstract void Undo();

    public abstract void Redo();
}

public class CommandManager
{
    #region Static Attributes

    private static object _lockObject = new object();
    private static CommandManager _instance = null;

    #endregion Static Attributes

    #region Attributes

    private Stack<Command> _commandStack = new Stack<Command>();
    private Stack<Command> _undoneStack = new Stack<Command>();

    #endregion Attributes

    #region ctor

    private CommandManager() { }

    #endregion ctor

    #region Static Methods

    public static CommandManager GetInstance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lockObject)
                {
                    _instance = new CommandManager();
                }
            }
            return _instance;
        }
    }

    #endregion Static Methods

    #region Public Methods

    public void Execute(Command command)
    {
        command.Execute();
        _commandStack.Push(command);
    }

    public void Redo()
    {
        Command redoCommand = _undoneStack.Pop();
        redoCommand.Redo();
        _commandStack.Push(redoCommand);
    }

    public void Undo()
    {
        Command undoCommand = _commandStack.Pop();
        undoCommand.Undo();
        _undoneStack.Push(undoCommand);
    }

    #endregion Public Methods
}

public class Person : ICloneable
{
    #region Properties

    public String Firstname { get; set; }
    public String Lastname { get; set; }

    #endregion Properties

    #region ICloneable Members

    public object Clone()
    {
        Person p = new Person();
        p.Firstname = this.Firstname;
        p.Lastname = this.Lastname;
        return p;
    }

    #endregion ICloneable Members

    #region Overrides

    public override string ToString()
    {
        return String.Format("{0}, {1}", Lastname, Firstname);
    }

    #endregion Overrides
}

public class PersonCommand : Command
{
    private Person _person;
    private Person _personStateBefore;

    public PersonCommand(Person person)
    {
        _person = person;
    }

    public override void Execute()
    {
        _personStateBefore = _person.Clone() as Person;

        _person.Firstname = "Norbert";
        _person.Lastname = "Eder";
    }

    public override void Undo()
    {
        _person.Firstname = _personStateBefore.Firstname;
        _person.Lastname = _personStateBefore.Lastname;
    }

    public override void Redo()
    {
        Execute();
    }
}

CommandManager manager = CommandManager.GetInstance;

Person p = new Person();
p.Firstname = "<not set>";
p.Lastname = "<not set>";
Console.WriteLine(
    String.Format("Before first execution: " + p.ToString()));

manager.Execute(new PersonCommand(p));
Console.WriteLine(
    String.Format("After first execution : " + p.ToString()));

manager.Undo();
Console.WriteLine(
    String.Format("After undo            : " + p.ToString()));

manager.Redo();
Console.WriteLine(
    String.Format("After redo            : " + p.ToString()));

Console.Read();

Fazit

Abgrenzung

• Austauschen von Verhaltensweisen via Konfiguration als auch zur Laufzeit
• Austauschen von einzelnen Methoden via Konfiguration als auch zur Laufzeit

Einführung

Strategy Pattern hilft bei Verhaltensänderungen

public interface IStrategy
{
    void DoWork();
}

public class ConcreteStrategy1 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy1");
    }

    #endregion
}

public class ConcreteStrategy2 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy2");
    }

    #endregion
}

public class StrategyContext
{
    private IStrategy _strategy;

    public StrategyContext(IStrategy strategy)
    {
        _strategy = strategy;
    }

    public void DoWork()
    {
        _strategy.DoWork();
    }
}

class Program
{
    static void Main(string[] args)
    {
        StrategyContext context = new StrategyContext(new ConcreteStrategy1());
        context.DoWork();
    }
}

Austausch von einzelnen Methoden

public interface ICommand
{
    void Execute();
}

public class CustomWorker1 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker1");
    }

    #endregion
}

public class CustomWorker2 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker2");
    }

    #endregion
}

public class StrategyProxy
{
    private IStrategy _usedStrategy;

    public StrategyProxy(IStrategy usedStrategy)
    {
        _usedStrategy = usedStrategy;
    }

    public void DoWork()
    {
        _usedStrategy.DoWork();
    }

    public void DoWork(ICommand customWorker)
    {
        customWorker.Execute();
    }
}

Fazit

• Case Diagrams
• Component Diagrams
• State Charts
• Class Diagrams
• Activity Diagrams
• Persistent Object Models

• Erweiterungen Data Access Application Block: Provider für MySql, SqLite und SqlEx
• Erweiterungen Exception Handling Application Block: SqlException Wrap Handler
• Erweiterungen Logging Application Block: LogParser
• Erweiterungen Policy Injection Application Block: PostSharp4EntLib, neue Matching-Regeln und neue Call-Handler
• Erweiterungen Validation Application Block: CollectionCountValidator, TypeValidator, ObjectValidator usw.