Overview

• Course concept
• Analysis and Design Solutions
  • Analysis Unified Chart
  • Design Unified Chart
• Fundamental Design Strategies
  • Design Strategies
  • Design Patterns Selection Map

Design Strategies and Patterns Selection
The seven fundamental reasons to use Design Patterns

Surprisingly enough, the 7 Design Strategies and Techniques, and the 24 "Gang of Four" (GOF) Design Patterns all depend upon 7 simple categories. Here is a two-page Decision Map starting from those 7 categories and guiding us down to the selection of the proper Design Patterns best suited to solve the problem(s) at hand.

• Decision Map concept and overview
• Seven Categories:
  • Methods Implementation
  • Object Construction
  • Complex Object Structures
  • Making Object Work Together
  • Handling objects that are hard to handle
  • Object States
  • Small Languages
  

Business Concept Modeling (BCM)—optional
Class Diagrams to describe an organization's or a system's business concepts, algorithms, rules, and policies

This optional chapter is for students who are not familiar with UML Analysis yet, especially Class Diagrams. These models are crucial in understanding what a system's subject matter, concepts, and mission precisely are. Class diagrams are also extensively used throughout Design Patterns as well as System's Architecture. Though not a substitute for the 5-day UML Analysis class this chapter is a valuable "survival kit".

• Decision Map to decide which class diagram model element should be used, in each situation

• Overview
• Examples
• Model Elements: Theory, Syntax
• Examples and Exercises for:
  • Business Concepts
    • Class
  • Business Concept Relationships
    • Inheritance
    • Composition
    • Association
    • Association Role
    • Association Class
• BCM Decision Tree
• BCM Practices:
  • A Public Class Enrolment Domain
  • The Autonomous Mission System (AMS)

Object Design Fundamentals
The basis of all advanced OO principles, techniques, and patterns

This chapter explains the fundamental principles of object design and the best strategies to implement them.

We first cover the best basic OO Design techniques that implement Encapsulation & Specialization as well as Inheritance & Polymorphism. Then we we examine the best implementations of Associations and Association Classes.

• OO Principles
  • Encapsulation
  • Specialization
  • Self-Sufficiency
  • Interface
  • Instantiation
  • Abstraction
  • Inheritance
  • Polymorphism
• Design Unified Chart
• 
• Encapsulation & Specialization (E&S)
• Inheritance & Polymorphism (I&P)
• Association Implementation
• Association Class Implementation
• Ternary Association and Association Class Implementation
• Labs for each topic

An Associations Framework (1 hour)
A modern way to deal with all types of association and association classes

Here is a great example of the "Write Once, Use Multiple Times" principle. This chapter, while solving a classical problem, is an opportunity to walk students through the process of designing general solutions to thorny problems.

After appreciating how much extra work is usually deployed for the implementation of associations and association classes, we devise a sophisticated yet straightforward generic solution. We start with the UML design to generalize that code and review its implementation in C++, Java, and C#. The result is a powerful Association Framework.

• The volume of associations in real-life domains
• Association code invading the Domain classes
• Building links with generic maps and lists
• Generic solution with "parametized" classes
• Association definition and instantiation
• Association Class definition and instantiation
• Ternary Association and Association Classes
• General, simple methods to traverse all links
• Removing most of the Associations code, thanks to the Association Framework
• Lab on either the Brokerage Model or the AMTS

Implementing Methods
The whole range of Method Implementation with or without Polymorphism, possibly combined with Associations for greater power

Discover the world of Method Implementation. Those techniques go way beyond simple class methods and take advantage of Inheritance, Polymorphism, and Associations. You will cover the three Polymorphism Design Strategies and four "GOF" Design Patterns.

• Decision Map to decide upon Method Implementations

• Within a Polymorphic Structure
  • Replacement Method
  • Extension Method
  • Template Method
• Within a Single Class
  • Strategy Pattern
  • Bridge Pattern
• Command Design Pattern
• One lab per topic
  • Business examples
  • Engineering examples

Constructing Objects
The different ways of constructing objects way beyond their constructors

Discover the 9 different ways of constructing objects when many building options are needed and/or other objects are linked to the newly constructed one. You will cover 4 Design techniques and 5 GOF Design Patterns, just for the sake of constructing objects.

• Decision Map to decide upon construction implementations

• Singleton Desigh Pattern
• Constructors
• Creation Method
• Object Factory
  • Case study: The Human Capital Management (HCM) System
• Factory Method Design Pattern
• Abstract Factory Design Pattern
• Prototype Design Pattern
• Builder Design Pattern (Note: also a solution to build complex structures)

Designing Complex Object Structures
Properly design any object structure, no matter how sophisticated it might be

Here are one general Design Strategy and two Design Patterns to build any sophisticated object structure in the simplest, most elegant ways.

• Decision Map to decide upon a Complex Object Structure Design

• Composite Design Pattern
• Builder Design Pattern (review from previous chapter)
• Decorator (Note: also a type of Polymorphism for method implementation)
• Domain Model Implementation for larger structures
  • Case Study : The Autonomous Mission System (AMS).

The Autonomous Mission System (AMS)
Case Study of a Distributed Mission Control System for multiple-asset, real-time deployments

This is a case study sophisticated enough to exhibit the real power of class diagrams in building Business Concept Models or System Concept Models. It appeals to anyone aiming at automating and synchronizing operations among multiple, physical assets acting towards a common purpose or mission. Such assets may be fixed or mobile, like vehicles, drones, aircrafts, and computer systems—portable or not. Control of the entire operations is distributed to keep missions resilient in case any controlling assets would be lost due to hostile conditions. This is a key topic for Humanitarian, or Engineering, or Defense-related organizations. We use this AMS case study multiple times throughout this course.

• The Autonomous Mission System (AMS) Domain Model

• UML Classes and Packages
• Design Strategies and Design Patterns used to implement the AMS Domain Model

Making Objects Work Together
The collaboration of objects working together is the "muscle" of all Object-Oriented applications

Now that we can design and construct any objects—no matter how complex they might be—another, major challenge lies ahead of us. Objects must be able to communicate, collaborate, and work in synchrony for an application to play its role. Enter the world of object and system's behavior, serviced by the ubiquitous "Propagation" Design Strategy and 7 powerful Design Patterns.

• Decision Map to select upon a series of Design Patterns to make objects work together

• Object Collaboration Fundamentals
• Iterator Pattern
• Propagation Strategy + Sequence and Collaboration Diagrams
• Visitor Design Pattern
• Mediator Design Pattern
• Façade Design Pattern
• Observer Design Pattern
• Adaptor Design Pattern
• Chain of Responsibility Design Pattern
  • A dynamic method implementation solution too
• One lab per chapter + AMS examples

Objects that are Difficult to Handle
Handling objects that are difficult to handle, in a simple and elegant way

Some objects or object structures are difficult to handle due to the unusual "weight" they represent. Those objects typically control sophisticated resources, carry with them large amounts of data, work with different layers of networking, or depend upon multiple domain spaces. The solutions presented in this chapter show how to keep their usage simple while properly handling their background responsibilities. Front-end simplicity is combined with back-end, heavy-duty work.

• Decision Map to select upon Design Patterns making it easy to work with objects that are hard to handle

• Flyweight Design Pattern
• Proxy Design Pattern for:
  • Object life-cycle management
  • Remote objects
  • Objects with security requirements
• Examples with the AMS (Autonomous Mission System)

Handling an Object's States
Implementing states in an object-oriented way, for greater clarity, flexibility, and scalability

Capture, restore, or manage the different States of an object, a structure, or a system. There are two important patterns allowing to do so in a safe, elegant, and reliable way. Though States have historically been implemented with long, cumbersome series of "switches", "cases" or even pointer tables. Here are very elegant, scalable, object-oriented solutions to implement States in a much more better way.

• Decision Map to select upon Design Patterns to implement the states of an object of system

• Memento Design Pattern
  • Application to the AMS Case Study
• State Design Pattern
• One lab per chapter + an example from the AMS case study

Small Languages
Represent data or algorithms with a small language

Handle dynamic business rules, special queries, and flexible algorithms or structures with a small language and its interpreter. Get possibly closer to human language and open new possibilities.

• Decision Map to decide whether the Interpreter Design Pattern is adequate for the problem at hand

• Interpreter Design Pattern

• A Rules Engine Case Study (optional):
  • Analysis
  • Architecture
  • Design
  • Coding

  
  Note: This is an advanced, real-life case study that uses the Interpreter as well as other Design Patterns, including Command, Façade, and Composite. It is an opportunity to combine several Design Patterns within the same problem domain.

Anti-Patterns
Typical Architectural, Design, or Programming Mistakes and how to avoid them

Some mistakes keep recurring throughout the history of systems and application development but there is a way to fight back. Here is a classification of a few, main mistakes, or "Anti-Patterns", to help recognize, fix, or prevent them altogether. After having devoted so much time on what to do in this class it is now appropriate to also point out what should not be done.

• For each Anti-Pattern:
  • Name
  • Synopsis
  • How it happened
  • Symptoms
  • How to prevent it
  • How to fix it
• Definition of an Anti-Pattern
• Anti-Pattern Categories
• Stovepipe
• Vendor Lock-in
• Avalanche Model
• Circular Dependency
• The "God" Object
• Object "Orgy"
• Functional Decomposition
• Golden Hammer
• Poltergiests
• Cut & Paste