Patterns@Work

1
Patterns_at_Work

• Frank Buschmann
• Siemens AG, Corporate Technology
• Dept. Software Engineering
• Frank.Buschmann_at_mchp.siemens.de

2
Patterns

• Patterns help building high-quality software
  systems by
• presenting a concrete solution schema for
  recurring design problems
• documenting proven design experience
• specifying concepts above the level of
  individual classes and objects
• describing structure and behavior of
  cooperating objects
• providing a common vocabulary and concept
  understanding
• addressing specific quality properties of the
  problems solution and
• covering all ranges of scale and abstraction.

3
Patterns and Systems

• However ...
• every pattern addresses a single problem only,
  without considering other related or dependent
  problems.
• Building complex systems, in contrast, means to
  deal with many problems, which also depend on
  each other.
• A catalog of isolated patterns or even a pattern
  system thus helps locally, but does not support a
  holistic approach to constructing software
  systems with patterns.

4
Pattern-based Software Architecture

• A conflict?
• If a pattern catalog or a pattern system does
  not support constructing software systems with
  patterns as desired ....
• ... how then can patterns help building
  high-quality software systems at all?

Gotcha!
Proxy
Broker
Observer
5
Lets look over an architects shoulder
6
The Domain

• Warehouse Management Systems
• organize warehouse operation storing,
  fetching, commissioning, replenishment, etc.
• control process automation.
• keep books of items stored in the warehouse.
• cooperate with other software systems, such as
  PPS, Database, etc.

7
Challenges

• Key Challenges in Building a Warehouse Management
  System
• specifying the base-line architecture.
• specifying the inter-process communication
  mechanisms.
• designing the warehouse core.
• specifying the warehouse core interface.
• designing the database connection.
• designing the user interface.

8
Base-line Architecture

• The Base-line Architecture
• Requirements analysis reveals 4 factors that
  impact the systems basic architecture
• Distribution. The system is highly
  distributed across a computer network.
• Human-computer interaction. Users
  communicate with the application using a
  huge variety of interfaces.
• Platform independence. The system must
  run in a heterogeneous environment.
• Component Integration. We want to
  integrate 3rd party products, such as
  databases, and legacy software.

9
Communication Infrastructure

• Problem
• A warehouse management system is highly
  distributed across a computer network. Its
  software architecture must
• Provide a communication infrastructure.
• Support location transparency of components.
• Hide platform and component specifics from
  application components.
• Allow for integration of legacy software.

Windows NT Clients
UNIX Server
The System
Basic Automation
Equipment
10
Communication Infrastructure

• Solution
• Provide a communication infrastructure for the
  warehouse management system with the Broker
  pattern
• The broker component is the systems
  central request and data router and hides
  platform specifics.
• Bridges enable communication between
  different brokers.
• Client-side and server-side proxies
  represent components of the system in
  remote address spaces and shield clients
  from broker specifics.
• Clients (e.g., Commissioning Client) and
  servers (Warehouse Core) represent
  application components.

Communication Infrastructure
Application Components
11
User Interface

• Problem
• Users communicate with the application using a
  huge variety of interfaces handheld terminals,
  form-based interfaces, command-line interfaces,
  and event-driven interfaces
• All interfaces operate on the same
  functional core, which thus should be
  independent of interface-specifics.
• Interfaces may change over time, for
  example from command-line interfaces to
  event driven-interfaces.

Commissioning
Equipment
The System
12
User Interface

• Solution
• Separate the user interface of the warehouse
  management system from its functional core with
  the Model-View-Controller pattern
• A model (WarehouseCore) represents the
  applications functionality.
• Views (e.g., Commissioning Client)
  represent application data and information
  in an interface-specific way.
• Controllers (e.g., Commissioning) allow
  to control the application in an
  interface-specific way.

13
Communication

• Problem
• The system must provide a location transparent
  inter-process communication mechanism using
  low-level operating system features
• Different services needed for the location
  transparent IPC differ in their abstraction
  level.
• Self-contained parts of the IPC logic
  should be exchangeable.
• Code changes in one part of the IPC logic
  should not ripple through the whole system.

Logic
Communication
method call
method dispatch
connection management
OS access
14
Persistence

• Solution
• Separate the broker component into different
  parts by applying the Layers pattern
• An Interface Layer provides access to the
  broker component.
• An Adapter Layer implements the
  dispatching of remotely called services on
  the systems objects.
• A Communication Layer implements
  connection handling and event dispatching.
• An OS Layer abstracts from low-level
  operating system APIs.

15
Legacy And 3rd Party Component Integration

• Problem
• The warehouse management system must support the
  integration of legacy code, such as for basic
  process automation, and 3rd party components,
  such as DBMS
• Interfaces of components providing the
  same functionality may vary vendor
  dependent.
• Component interfaces may not match with
  the applications view on the functionality
  they offer.

Application view on Databases
16
Legacy And 3rd Party Component Integration

• Solution
• Integrate legacy and 3rd party components by
  using the Adapter pattern
• A client (WarehouseCore) represents the
  user of the component.
• Adaptees (DBMS, BasicAutomation)
  represents the components to be
  integrated.
• Adapters (DBMS-Adapter, BA-Adapter) map
  between client interfaces and the
  adaptees interfaces.

17
Summary (1)

• 4 Patterns define the Base-line Architecture
• Broker defines the fundamental
  communication infrastructure.
• Model-View-Controller helps keeping the
  functional core independent of
  customer-specific user interfaces.
• Layers separates the functional core from
  communication aspects.
• Adapter supports the integration of legacy
  and pre-fabricated 3rd party components.

18
Summary (2)

• The Result
• A classical 3-tier architecture for distributed
  systems.
• Known Uses _at_ Siemens
• Warehouse Management
• Hot Rolling Mill Automation
• Medical Imaging
• Network Management
• ComUnity

19
Communication Infrastructure

• The Communication Infrastructure
• 4 factors characterize the communication
  infrastructure
• Heterogeneous computing environment.
• Efficient inter-process communication.
• Location transparency of components.
• Plug n Play environment.

20
The Basic Concept (1)

• Broker Provides the Concept
• The Broker pattern provides the conceptual
  principles on which the communication
  infrastructure relies.
• CORBA compliant Object Request Brokers, such as
  IONA Orbix, Inprise Visibroker and Sun Cool,
  Microsofts DCOM, and the Java RMI all follow the
  Broker pattern.
• We do not need to build our own communication
  infrastructure, but to use an existing product
  most effectively, we need to know its key design
  principles.

Communication Infrastructure
Application Components
21
The Basic Concept (2)

• Layers Provides the Abstraction
• The Layers pattern divides the communication
  functionality into different parts of different
  purpose and abstraction.
• CORBA compliant Object Request Brokers all follow
  the Layers pattern
• The Interface Layer corresponds to the ORB
  Interface.
• The Adapter Layer corresponds to the
  Portable Object Adapter.
• The Communication Layer corresponds to the
  ORB Core.

22
Accessing OS APIs

• Problem
• Developing communication software is hard if
  developers must wrestle with low-level-system
  APIs.
• OS APIs differ from platform to platform.
• OS dependencies in system code.
• Mismatch between procedural programming
  style of OS APIs and the object paradigm
  used in the warehouse management
  application.

if defined (_WIN32) static CRITICAL_SECTION
lock else static mutex_t lock endif /
_WIN32 / ... // Handle UNIX/Win32 portability //
differences. if defined (_WIN32) SOCKET h
DWORD t_id else int h thread_t
t_id endif / _WIN32 / ... if defined
(_WIN32) ThreadCreate( ... ) else
thr_create( ... ) endif / _WIN32 /
23
Accessing OS APIs

• Solution
• Hide dependencies to the operating system via
  the Wrapper Facade pattern.
• Wrapper Facades (e.g., ThreadManager,
  Sockets) provide a uniform object-oriented
  access to low-level operating system
  services.
• Functions (thr_create(), ThreadCreate())
  are the operating system functions needed
  to implement the communication software.
• Clients (Communication) use the wrapper
  facades to get access to operating system
  services.

Warehouse Core Server
A Client
Telegram Office
Commis-sioning
TelegramOfficeStub
TelegramOfficeSkeleton
24
Accessing OS APIs
class SOCK_Stream public // Constructor.
SOCK_Stream(void) handle_(INVALID_HANDLE_V
ALUE) // Initialize from an existing
HANDLE. SOCK_Stream(SOCKET h) handle_(h)
// Close the handle on destruction.
SOCK_Stream(void) close(handle_) // Set
and get. void set_handle(SOCKET h)
handle_ h SOCKET get_handle (void)
const return handle // I/O
operations. int recv(char buf, size_t len,
int flags 0) int send(const char buf,
size_t len, int flags 0) private
SOCKET handle_
class Thread_Manager public // Creates a
new thread. static int spawn (THR_FUNC
func, void args 0, long flags
THR_NEW_LWP, thread_t t_id 0,
hthread_t t_handle 0, long priority
DEFAULT_THREAD_PRIORITY, int
grp_id -1, void stack 0,
size_t stack_size 0) // Join a thread
specified by lttidgt. static int join
(ACE_thread_t tid, void status 0)
// Suspend and resume a single thread. int
suspend (thread_t) int resume (thread_t)
// Many more functions ...
25
Inter-Process Communication

• Problem
• We need to implement the GIOP on top of a
  specific inter-process communication mechanism.
• Different platforms provide different IPC
  mechanisms.
• The IPC mechanism to be used may change
  over time.
• Stubs and Skeletons know where the
  components they represent are located and to
  be invoked, but they are unaware of the
  platforms IPC mechanisms.

Peer 2
There
Request
GIOP processing
Request
Here
Peer 1
26
Inter-Process Communication

• Solution
• Encapsulate the GIOP processing into objects with
  the Forwarder-Receiver pattern
• Peers (Commissioning, TelegramOffice
  inclusive its stub and skeleton) represent
  components that want to communicate.
• A forwarder (ConnectionHandler on the
  client-side) is responsible for forwarding
  requests to a remote peer using a specific
  GIOP implementation.
• A receiver (ConnectionHandler on the
  server-side) is responsible for receiving a
  GIOP request and calling the addressed peer
  to process the request.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOffice Skeleton
request/response
ConnectionHandler
ConnectionHandler
Thread Manager
SOCKET
SELECT
Operating System
27
Inter-Process Communication
class Client_Connection_Handler public
Service_Handler public Client_Connection_Hand
ler (Thread_Manager t 0) virtual
Client_Connection_Handler () // ltConnectorgt
hook. virtual int open (void ) //
Activation template method. virtual int
send_request (ORB_Core orb_core,
OutputCDR stream, int is_twoway) //
Event Handler overloads. virtual int
handle_input (HANDLE) virtual int
handle_close (HANDLE, Reactor_Mask)
// Perform appropriate closing. virtual int
close (u_long flags 0) protected // ...
class Server_Connection_Handler public
Service_Handler public Server_Connection_Hand
ler (Thread_Manager t 0) virtual
Server_Connection_Handler () // ltAcceptorgt
hook. virtual int open (void ) //
Activation template method. virtual int
activate (/ many parameters /) //
Called when the handler is turned // into an
active object virtual int svc (void) //
Message processing. virtual int handle_message
(InputCDR msg, OutputCDR response,
bool response_required, long
request_id, Environment _env) protected
// ...

28
Event Demultiplexing

• Problem
• Incoming events from remote clients must be
  demultiplexed onto the corresponding object and
  method.
• Different platforms provide different event
  demultiplexing mechanisms.
• Event demultiplexing should be decoupled
  from subsequent event handling.

Object1
Object2
service1
service2
Dispatch
select()
WaitForMultipleObjects()
Event
29
Event Demultiplexing

• Solution
• Decouple the general event demultiplexing and
  service provider dispatching from
  service-specific event processing with the
  Reactor pattern
• An event demultiplexer (SELECT) is a
  Wrapper Facade which blocks awaiting events
  to occur.
• An initiation dispatcher (Reactor)
  provides a general mechanism for
  dispatching events to service providers.
• Event handlers (ConnectionHandler,
  TelegramOfficeSkeleton, Telegram- Office)
  are responsible for application- specific
  service processing.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOffice Skeleton
request/response
ConnectionHandler
ConnectionHandler
Reactor
Thread Manager
SOCKET
SELECT
Operating System
30
Event Demultiplexing
int Select_Reactorhandle_events()
(Time_Value max_wait_time) int result
-1 SEH_TRY Select_Reactor_Handle_Set
dispatch_set int number_of_active_handle
s this-gtwait_for_multiple_events
(dispatch_set, max_wait_time)
result this-gtdispatch
(number_of_active_handles,
dispatch_set) SEH_EXCEPT
(this-gtrelease_token ()) // As it stands
now, we catch and // then rethrow all
Win32 structured // exceptions so that we
can make // sure to release the lttoken_gt
// lock correctly. return
result
int Select_Reactordispatch (int
number_of_active_handles, dispatching
dispatch_set) do // Keep track of
changes to our state. state_changed_ 0
// Dispatch timers first. if
(dispatch_timer_handlers () -1) //
State has changed. break //
Dispatch notification handlers. else
if (dispatch_notification_handlers
(...) -1) // State has
changed. break // Dispatch
I/O handlers. else if (this-gtdispatch_io_
handlers (...) -1)
// State has changed. break
while (number_of_active_handles gt 0) return
1

31
Connection Establishment

• Problem
• Before peers in a distributed system can
  communicate, a connection between them must be
  established.
• Adding new peers should not affect
  existing connection establishment code.
• Connection roles of peers should be
  decoupled from their communication roles.
• Connection strategies change much less
  frequently than service implementations.

Peer 2
The Network
Connect me to Peer 2, please.
Peer 1
32
Connection Establishment

• Solution
• Separate connection establishment from service
  processing with the Acceptor-Connector pattern
• Event handlers (ConnectionHandlers, are
  responsible for GIOP processing.
• An acceptor passively accepts connection
  requests from remote peers.
• A connector actively initiates connections
  to remote service handlers.
• A dispatcher (Reactor) is responsible for
  routing connection requests.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOfficeSkeleton
request/response
ConnectionHandler
ConnectionHandler
create
create
Connector
Acceptor
connect
Reactor
Thread Manager
SOCKET
SELECT
Operating System
33
Connection Establishment
template ltclass HANDLER, class PEER_ACCEPTORgt
class Acceptor public Event_Handler public
// Initialize transport enpoint. virtual
int open (const PEER_ACCEPTORPEER_ADDR
local_addr,
Concurrency_StrategyltHANDLERgt s) // Factory
Method that creates, connects, // and
activates HANDLER's. virtual int accept
() protected // Handler creation,
connection. and // concurrency strategies.
virtual HANDLER make_handler (void) virtual
int accept_handler (HANDLER ) virtual int
activate_handler (HANDLER ) // Handling
connection requests. virtual int
handle_event (HANDLE, EVENT) private
HANDLER handler PEER_ACCEPTOR
peer_acceptor_ Concurrency_StrategyltHANDLERgt
con_s
template ltclass HANDLER, class PEER_ACCEPTORgt
int AcceptorltHANDLER,
PEER_ACCEPTORgtaccept () // Create a new
HANDLER. HANDLER handler make_handler
() // Accept connection from client.
accept_handler (handler) // Activate HANDLER
by calling // its open() hook.
activate_handler (handler)

34
Concurrency
A Thread

• Problem
• We like to support concurrency.
• Different platforms provide different
  threading libraries.
• Whether or not we use concurrency, and if
  so, the use of a particular concurrency
  mechanism, should be transparent to other
  components in the communication software.

Object
Object
Another Thread
Request Dispatch
Request
35
Concurrency

• Solution
• Transparently support concurrency with the Active
  Object pattern
• A proxy (TelegramOfficeStub) receives client
  requests and forwards them (via the
  ConnectionHandler) to the Active Object.
• A scheduler (Reactor) receives requests
  from the proxy and dispatches them on the
  servant when they become runnable.
• An activation queue (SOCKETsocket queue)
  maintains pending method requests for the
  scheduler.
• A servant (ConnectionHandler,
  TelegramOfficeSkeleton, Telegram- Office)
  processes the requested service.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOfficeSkeleton
request/response
ConnectionHandler
ConnectionHandler
create
create
Connector
Acceptor
connect
Reactor
Thread Manager
SOCKET
SELECT
Operating System
36
Concurrency
template ltclass HANDLERgt int
Concurrency_StrategyltHANDLERgt
activate_handler (HANDLER handler,
void arg) // Call up to our parent to do
the // HANDLER initialization. if
(inheritedactivate_handler (handler,
arg) -1) return -1 else //
Turn the lthandlergt into an // active
object (if it isn't already // one as a
result of the first // activation...)
return handler-gtactivate (thr_flags_,
n_threads_)
int Task_Baseactivate (/ many params /)
// If the task passed in is zero, we will //
use ltthisgt. if (task 0) task
this if (thr_count_ gt 0 force_active
0) return 1 // Already active. else
thr_count_ n_threads // Use the
Thread_Manager singleton if // the caller
didn't supply us // with a Thread_Manager.
if (thr_mgr_ 0) thr_mgr_
Thread_Managerinstance () if (thread_names
0) // thread names were not specified
grp_id_ thr_mgr_-gtspawn_n(/ ... /)
else // thread names were specified
grp_id_ thr_mgr_-gtspawn_n(/ ... /) if
(grp_id_ -1) return -1 else
return 0

37
Concurrency Strategies
A Thread

• Problem
• There are different concurrency strategies.
• The component which spawns new threads, the
  Acceptor, should not depend on a particular
  concurrency strategy.
• Without breaking existing code, the
  system should be extensible with new
  concurrency strategies.

Object
Thread per Request Thread per Connection Thread
Pool
Request Dispatch
Request
38
Concurrency Strategies

• Solution
• Support multiple concurrency strategies with the
  Strategy pattern
• A context (Acceptor) uses a particular
  concurrency strategy to create threads for
  running Active Objects.
• An abstract strategy (Concurrency- Strategy)
  provides a common interface for all specific
  concurrency strategies.
• Concrete strategies (ThreadPer- Connection)
  implement a particular concurrency strategy.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOfficeSkeleton
request/response
ConnectionHandler
ConnectionHandler
create
create
Connector
Acceptor
connect
Concurrency Strategy
Reactor
ThreadPer Connection
Thread Manager
SOCKET
SELECT
Operating System
39
Initialization (1)

• Problem
• There are many different strategies for different
  purposes in the communication software.
• Not all of these strategies can be combined
  in a semantically consistent manner, since
  some mutually exclude themselves.
• The configuration of the system with a
  consistent set of strategies should be easy.

Concurrency Strategy
Concurrency Strategy
Demux Strategy
Demux Strategy
Protocol
Protocol
40
Initialization (1)
Warehouse Core Server

• Solution
• Configure the communication infrastructure with
  semantically consistent strategies via the
  Abstract Factory pattern
• An abstract factory provides a generic
  interface for configuring the communication
  software with strategies.
• Concrete factories (QuelleFactory)
  implement the configuration of the system
  with a semantically consistent set of
  concrete strategies for a specific customer.
• Products (ThreadPerConnection) are the
  strategies with which concrete factories
  can configure the system.

Telegram Office
TelegramOfficeSkeleton
Abstract Factory
ConnectionHandler
create
Acceptor
Concurrency Strategy
QuelleFactory
Reactor
ThreadPer Connection
Thread Manager
SOCKET
SELECT
Operating System
41
Initialization (2)

• Problem
• It may be necessary to re-configure the
  communication software with different
  strategies.
• However, we cannot afford any downtime of the
  system.

42
Initialization (2)

• Solution
• Support run-time (re-)configuration of the
  communication infrastructure with the Service
  Configurator pattern
• A service (AbstractFactory) defines a common
  interface for configuring and executing a
  particular factory.
• Concrete services (QuelleFactory) are
  factories that configure a particular set
  of strategies with the system.
• A service repository maintains the
  currently configured and loaded factories.
• A service configurator can dynamically
  load factories to, and unload from, the
  service repository, and execute them.

Warehouse Core Server
Service Configurator
Telegram Office
Service Repository
TelegramOfficeSkeleton

Abstract Factory
ConnectionHandler
create
Acceptor
Concurrency Strategy
QuelleFactory
Reactor
ThreadPer Connection
Thread Manager
SOCKET
SELECT
Operating System
43
Summary (1)

• 8 Patterns Define the Communication Layer
• Wrapper Facade shields it from the OS.
• Forwarder-Receiver encapsulates the IPC.
• Reactor performs general event dispatching.
  
• Acceptor-Connector supports connection
  establishment.
• Active Object supports concurrency.
• Strategy supports different communication
  layer personalities.
• Abstract Factory helps configuring a
  concrete personality.
• Service Configurator supports a run-time
  (re-) configuration of these personalities.

Warehouse Core Server
A Client
Commis-sioning
Telegram Office
TelegramOfficeStub
TelegramOfficeSkeleton
request/response
ConnectionHandler
ConnectionHandler
create
create
Connector
Acceptor
connect
Concurrency Strategy
Reactor
ThreadPer Connection
Thread Manager
SOCKET
SELECT
Operating System
44
Summary (2)

• The Result
• A flexible communication middleware for
  distributed systems.
• Known Uses _at_ Siemens
• Warehouse Management
• Hot Rolling Mill Process Automation
• Medical Imaging

45
Warehouse Core Interface

• The Warehouse Core Interface
• 6 factors impact the design of the warehouse core
  interface
• Multiple clients. There are many clients
  that operate on the warehouse core.
• Client diversity. Different kinds of clients
  use the warehouse core differently.
• Independence. Client views on the ware-
  house core should not affect its design.
• Extensibility. Integrating new client
  views should neither affect the warehouse
  core design nor its code.
• Housekeeping. Logging and, where possible,
  undo/redo should be supported.
• Real-time. The system has soft real-time
  requirements.

46
Client Access

• Problem
• When designing the client access to the warehouse
  core services we must consider two aspects
• Every kind of client uses the warehouse
  core differently. The warehouse core,
  however, should be independent of
  client-specific views on its services.
• It must be possible to integrate new kinds
  of use cases for the warehouse core using
  existing services, but without affecting
  its design and implementation.

Equipment
Commissioning
Basic Automation
Administration
Interface
Warehouse Core
47
Client Access

• Solution
• Shield the warehouse core interface from the way
  it is used by clients with the Command pattern
• Clients (e.g., Basic AutomationProxy)
  create concrete command objects that
  represent the operation they want to
  execute on the warehouse core.
• An Abstract Command class declares an
  interface for executing an operation.
• Concrete Commands (e.g., StoreItem)
  implement a concrete operation on the
  warehouse core.
• The Receiver (WarehouseCore) knows how to
  perform operations.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

AbstractCommand
FetchItem
StoreItem
ItemTransport
Warehouse Core
48
Optimizing The Command Hierarchy

• Problem
• Using the Command pattern results in overly many
  Concrete Command classes. How can we minimize
  their number?
• The expressiveness of the original Command
  class hierarchy should be preserved.
• Many concrete commands can be composed of
  more elementary commands, such as Item
  Transport.

AbstractCommand
StoreItem
ItemTransport
Search forLocation
FetchItem
TransportPlanning
BookLocation
BookEquipment
ReleaseLocation
...
ReleaseEquipment
...
Warehouse Core
49
Optimizing The Command Hierarchy

• Solution
• Reduce the size of the Command hierarchy by
  applying the Composite pattern
• A Component (AbstractCommand) declares an
  interface for objects in a command
  composition.
• Leafs (e.g., FetchItem) represent the
  atomic commands in the composition.
• A Composite (MacroCommand) implements the
  behavior for composed commands.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

AbstractCommand

FetchItem
StoreItem
MacroCommand
Warehouse Core
50
Simple Undo

• Problem
• Sometimes clients like to cancel a request.
• Commands should support their own
  cancellation, if allowed.
• The warehouse core should not be blown up
  with additional infrastructure, just because
  few commands are undoable.

4!
Interface
Warehouse Core
51
Simple Undo

• Solution
• Support undoing individual commands with the
  Memento Pattern
• A Memento stores parts of the internal
  state of the warehouse core before an
  undoable command is executed.
• Originators (e.g., MacroCommand) create a
  memento before they start an operation on
  the warehouse core.
• The originators also embody the Caretaker
  role of the pattern. They are responsible
  for the mementos safekeeping.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
52
Command Housekeeping

• Problem
• Client requests must be logged and scheduled, and
  we want to support multiple undo/redo.
• However, integrating housekeeping functionality
  with the existing commands is either tedious,
  such as for logging, or next to impossible, as
  with scheduling and multiple undo/redo.

4
1. FetchItem 2. BookEquipment 3.
SearchforLocation 4. ... 5. ...
Logging
MultipleUndo/Redo
Scheduling
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
53
Command Housekeeping

• Solution
• Support command housekeeping by using the Command
  Processor Pattern
• A Controller (TelegramOffice) creates
  command objects upon client requests and
  passes them to the Command Processor for
  execution.
• A Command Processor executes operat- ions
  on the warehouse core. Internally, it logs
  and schedules commands, and organizes their
  multiple undo/redo.
• Commands (e.g., StoreItem) implement the
  operations on the warehouse core.
• The Supplier (Warehouse Core) knows how to
  perform operations.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

TelegramOffice
CommandProcessor
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
54
Central Command Handling

• Problem
• To organize housekeeping functionality correctly,
  specifically scheduling, only one Command
  Processor is allowed for the warehouse core.
• Clients need a defined access point to the
  one instance of the Command Processor.
• When requesting access to the Command
  Processor clients should be unaware of
  whether or not it already exists.

4
4
1. FetchItem 2. BookEquipment 3.
SearchforLocation 4. ... 5. ...
1. FetchItem 2. BookEquipment 3.
SearchforLocation 4. ... 5. ...
Logging
Logging
MultipleUndo/Redo
MultipleUndo/Redo
Scheduling
Scheduling
CommandProcessor 1
CommandProcessor 2
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
55
Central Command Handling

• Solution
• Ensure that the Command Processor class has only
  one instance with the Singleton Pattern
• A Singleton (CommandProcessor) is
  responsible for creating its own unique
  instance and for providing an operation
  that lets clients access this instance.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

TelegramOffice
CommandProcessor
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
56
Logging and Scheduling

• Problem
• Different customers require different logging and
  scheduling mechanisms.
• Integrating different logging and
  scheduling mechanisms should not affect
  general command handling.
• We may need to integrate new mechanisms at
  a later point in time, but do not want to
  touch existing code.
• Logging mechanisms may change at run-time,
  for example from logging everything to only
  logging specific kinds of commands.

MaximumUrgencyFirst
Earliest Deadline First
Minimum Latency First
Scheduling
1. FetchItem 2. BookEquipment 3.
SearchforLocation 4. ... 5. ...
Execution
Warehouse Core
57
Logging and Scheduling

• Solution
• Integrate logging and scheduling mechanisms with
  the Strategy Pattern
• Two Strategies (LoggingStrategy,
  SchedulingStrategy) declare an interface
  common to all supported logging and
  scheduling strategies, respectively.
• Concrete Strategies (LogEverything, MUF)
  implement the logging and scheduling
  interface.
• The Context (CommandProcessor) is
  configured with a concrete logging strategy
  and a concrete scheduling strategy.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

TelegramOffice
CommandProcessor
LoggingStrategy
1
SchedulingStrategy
1
LogEverything
MUF
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
58
Telegram to Command Conversion

• Problem
• Clients deliver telegrams to the warehouse core,
  but it only understands commands.
• The general mechanism for accepting a telegram
  and converting it into a command object should
  thus be separated from converting a specific
  telegram.

A Client
Telegram
Telegram Office
Command
Command Objects
59
Telegram to Command Conversion

• Solution
• Separate general telegram handling from their
  conversion into command objects with the Abstract
  Factory Pattern
• A Concrete Factory (CommandFactory)
  declares and implements an interface for
  creating commands from telegrams.
• An Abstract Product (AbstractCommand)
  declares an interface for a type of product
  object.
• Concrete Products (e.g., StoreItem) define
  product objects to be created.
• An abstract factory is not needed, since there
  are no multiple ways to convert a specific
  telegram into a command.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

TelegramOffice
CommandFactory
CommandProcessor
LoggingStrategy
1
SchedulingStrategy
1
LogEverything
MUF
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
60
Summary (1)

• 7 Patterns Define the Warehouse Core Interface
• Command shields the warehouse core from
  client-specific views on it.
• Composite helps minimizing the Command
  hierarchy.
• Memento supports command undo/redo.
• Command Processor supports logging,
  scheduling, and multiple undo/redo.
• Singleton helps creating only one Command
  Processor instance.
• Strategy supports configuring the Command
  Processor with specific scheduling and
  logging mechanisms.
• Abstract Factory separates telegram hand-
  ling from their conversion to commands.

AdministrationProxy
Basic Autom.Proxy
EquipmentProxy

TelegramOffice
CommandFactory
CommandProcessor
LoggingStrategy
1
SchedulingStrategy
1
LogEverything
MUF
AbstractCommand
Memento
0..1

FetchItem
StoreItem
MacroCommand
Warehouse Core
61
Summary (2)

• The Result
• A flexible framework for amessage- or
  telegram-oriented interface to a service
  component.
• Known Uses _at_ Siemens
• Warehouse Management
• Passenger Information
• Hot Rolling Mill Process Automation
• Medical Imaging

62
Warehouse Core

• The Warehouse Core
• 4 factors key factors impact the design of the
  warehouse core
• Physical Storage Representation. The
  physics of a real-world storage must be
  represented exactly.
• Storage Efficiency. Memory is a critical
  resource. It must be possible to represent
  even the largest warehouses though.
• Extensibility. Integrating new functionality
  and extending the representation of the
  warehouse structure should not affect the
  existing code, if possible.
• Task-orientation. Different user services
  should be executable as independent tasks.

63
Physical Storage

• Problem
• There are many different real-world warehouses.
• Storage is organized hierarchically.
• The class structure of the system must
  allow to represent arbitrary storage
  structures.
• Customers sometime re-organize their
  warehouse structure. The system must follow
  such re-organizations at run-time.
• The structure must be extensible with new
  kinds of storage types.

64
Physical Storage

• Solution
• Represent physical storage with the Composite
  Pattern
• A Component (AbstractStorage) declares an
  interface for objects in a storage
  representation.
• Leafs (e.g., Bin, Door) represent atomic
  storage types. Transport Equipment is
  considered as mobile storage.
• A Composite (CompositeStorage) implements
  the behavior for composed storage, such as
  aisles, sides, and racks.

AbstractStorage

Door
Bin
CompositeStorage
Equipment
65
Physical Storage

• Problem
• Clients are unaware to which storage component
  they deliver a request.
• The storage which receives the request
  might not be the intended receiver.
• The storage which receives the request
  does not know the intended receiver.

66
Physical Storage

• Solution
• Forward requests upwards the storage hierarchy
  via the Chain of Responsibility Pattern
• A Handler (AbstractStorage) defines an
  interface for handling requests.
• Concrete Handlers (e.g., Bin, Door,
  CompositeStorage) handle requests they are
  responsible for, otherwise they forward a
  request to their successor.

AbstractStorage

Door
Bin
CompositeStorage
Equipment
67
Storage Organization

• Problem
• Storage is organized according to different
  organization criteria.
• Organization criteria are assigned to every
  single storage.
• There should not be too much memory
  consumption for criteria representation.
• Significant parts of a warehouse share
  common organization criteria, such as all
  bins in an aisle.

HazardousClass
TemperatureClass
68
Storage Organization

• Solution
• Represent storage organization criteria with the
  Flyweight Pattern
• A Concrete Flyweight (SOC) declares and
  implements an interface for accessing a
  vector of storage organization criteria.
• A Client (AbstractStorage) maintains a
  reference to a flyweight.
• Not shown here A Flyweight Factory
  (Initialization) creates and assigns new
  flyweights to a storage.
• An abstract Flyweight is not needed, since only
  one flyweight type is needed in the system.

SOC
1
AbstractStorage

Door
Bin
CompositeStorage
Equipment
69
Storage-specific Behavior

• Problem
• Storage may have individual behavior.
• Each individual storage should be
  configurable with appropriate behavior.
• Storage-specific behavior may change at
  run-time.
• Integrating new kinds of storage-behavior
  with the system should be possible, with as
  little modification of existing code as
  possible.

Storage Load-Behavior Options
70
Storage-specific Behavior

• Solution
• Represent storage-specific behavior with the
  Strategy Pattern
• An Abstract Strategy declares an interface
  for objects that represent storage-specific
  behavior.
• Concrete Strategies (e.g., LoadInLayers)
  implement the Abstract Factory interface in a
  specific manner.
• A Context (AbstractStorage) is configured
  with a Concrete Strategy which represents
  its specific behavior.

AbstractStrategy
LoadInLayers
SOC
1

AbstractStorage

Door
Bin
CompositeStorage
Equipment
71
Warehouse Behavior

• Problem
• Some services operate on the whole warehouse
  structure.
• The implementation of such services should
  not depend on a a concrete warehouse
  representation.
• A concrete warehouse structure should not
  be polluted with service-specific code.
• New such services may emerge over time and
  must be integrated.

Occupation?
72
Warehouse Behavior

• Solution
• Integrate warehouse behavior with the Visitor
  Pattern, thereby preparing the system for future
  extensions
• A Visitor (AbstractVisitor) declares a visit
  operation for each class in the Element
  structure.
• ConcreteVisitors (e.g., Occupation)
  implement the visit operation for the
  specific Concrete Element it visits.
• An Element (AbstractStorage) declares an
  accept operation that takes a visitor as an
  argument.
• Concrete Elements (e.g., Door) implement
  the accept operation in an element- specific
  manner.

AbstractVisitor
AbstractStrategy
LoadInLayers
Occupation
SOC
1

AbstractStorage

Door
Bin
CompositeStorage
Equipment
73
Traversal

• Problem
• Some operations must traverse the warehouse
  storage structure.
• Different operations require different
  traversal strategies.
• The operation should not be dependent on the
  structure to be traversed.
• The traversal strategies an operation uses
  may change.

Occupation?
74
Traversal

• Solution
• Encapsulate traversal strategies as objects with
  the Iterator Pattern
• An Iterator (AbstractIterator) declares an
  interface for accessing and traversing an
  object structure.
• Concrete Iterators (e.g., LeafsOnly)
  implement a specific traversal algorithm on
  the object structure.
• An Aggregate (AbstractStorage) defines an
  interface for creating concrete Iterator
  objects that are able to traverse its inner
  structure.

AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage

Door
Bin
CompositeStorage
Equipment
75
Direct Access

• Problem
• Some operations need direct access to all
  entities of a certain kind.
• The operation should not be dependent on
  the entities to which it requires access.
• The operation should not need to provide
  special data structures for maintaining the
  entirety of all entities.
• Individual entities should not need to
  provide infrastructure for maintaining their
  entirety.

Who is driving forklift 42?
76
Direct Access

• Solution
• Introduce components for managing entities of a
  specific kind with the Manager Pattern
• A manager (StorageManager) implements
  services for maintaining entities of a
  certain kind.
• Subjects (AbstractStorage) represent the
  entities being managed.
• Clients (not shown here) use the manager
  to get direct access to a specific entitiy.

StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
77
Load on Demand

• Problem
• A complete representation of the warehouse
  structure is too memory expensive. It is thus
  stored in a DBMS.
• However, we need every concrete part of the
  structure in memory as soon as a client requires
  access to it.

DBMS
78
Load on Demand

• Solution
• Defer loading an object into memory with the
  Proxy Pattern
• A client (e.g., a Visitor) needs access to a
  certain storage data which is not available
  in memory.
• A proxy (e.g., AbstractStorage) represents
  the data and organizes its loading on
  demand as well as its release after usage.
• An original (StorageOriginal) contains the
  data that the proxy loads.

StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
79
Integration (1)

• Using the Warehouse Structure
• The design of the warehouse structure
  representation and management is implemented as a
  separate component within the systems functional
  core.
• It is used by so-called task-components which
  represent the user services the system offers,
  such as Item Transport, Item Storing, Item
  Fetching, and Replenishment.
• The task-components also shield the warehouse
  structure from unauthorized access, and its
  clients from design specifics.

ItemTransport
StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
80
Integration (2)

• Communication with the System
• The Warehouse Structure component communicates
  with the real-world warehouse via telegrams.
• Objects representing proactive physical entities
  of the warehouse, such as forklifts, transport
  belts, and rack servers, communicate with the
  telegram office to control the real-world.
• The telegram office receives messages from the
  warehouse structure, converts them, with help of
  a telegram factory into telegrams and sends them
  to their receiver.

TelegramOffice
TelegramFactory
StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
81
Summary (1)

• 8 Patterns Define the Representation of the
  Warehouse Structure
• Composite and Chain of Responsibility
  specify the storage hierarchy.
• Flyweight supports implementing storage
  organization criteria efficiently.
• Strategy supports the integration of
  storage-specific behavior.
• Visitor helps implementing storage- general
  services.
• Iterator supports traversing the warehouse
  structure.
• Manager allows direct access to elements of
  the warehouse structure.
• Proxy supports loading data on demand.

StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
82
Summary (2)

• The Result
• An adaptable and extensible design for
  representing arbitrary warehouse structures.
• Known Uses _at_ Siemens
• SICALIS Warehouse Management

StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
83
Lets reflect on the stuff
84
Projects

• Project Experience
• Warehouse Management
• Hot Rolling Mill Process Automation
• Medical Imaging
• Network Management
• Passenger Information
• Object Request Brokers

TAO, The Ace ORB
85
Observation (1)

• Frameworks were often NOT our original goal
• For most projects the primary goals were
  extensibility and adaptability.
• Through careful design for evolution and change
  we received software architectures that are
  stable in their core, yet being extensible with
  new structures, modifiable with respect to
  existing structures, and adaptable to
  customer-specific requirements.
• In other words, the frameworks were just a
  by-product.

TelegramOffice
TelegramFactory
StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
86
Observation (2)

• One Size Does Not Fit All
• Patterns alone are NOT sufficient enough for
  building systems that meet todays tough
  requirements.
• DOC provides the communication
  infrastructure.
• Frameworks support building architectures
  for system families.
• Patterns help designing the frameworks.
• Components help configuring the frameworks
  to a customer-specific application.

TelegramOffice
TelegramFactory
StorageManager
AbstractIterator
AbstractVisitor
AbstractStrategy
1
1
LoadInLayers
LeafsOnly
Occupation
SOC
1

AbstractStorage


Door
Bin
CompositeStorage
Equipment
DBMS
Storage Original
87
Benefits

• Benefits
• Solutions to design problems are based on
  well-proven standard concepts.
• Consideration of alternatives are possible.
• Explicit consideration of non-functional
  aspects.
• Improved Communication.
• Improved Documentation.
• Knowledge is available to the whole
  organization.

88
Problems

• Problems
• Hype.
• Finding the right patterns is not always
  easy.
• Implementing a pattern correctly needs
  some experience.
• Using patterns does not necessarily results
  in a high-quality design.
• People often see patterns as blueprints.

89
Lessons Learned

• Lessons Learned
• Patterns help, but are no silver bullet.
• Patterns complement but do not replace
  existing technology and methods.
• Education is crucial for success.
• Dont force developers in using the
  patterns.
• Apply patterns carefully.
• JUST DO IT!

90
The Patterns
Slide