Presentation on theme: "Information System Architecture Information system The data is the raw material of any I.S. Before becoming information, the data must be created, stored,"— Presentation transcript:
Information System Architecture
Information system The data is the raw material of any I.S. Before becoming information, the data must be created, stored, processed, analyzed and distributed. Information systems can be characterized by their functions: the generation, storage, presentation, exchange, interpretation, transformation, and transportation of information.
An application-centric view of IS Applications, developed independently of each other, provided functionality that can only be used within the boundaries of each application. Differences between platforms, programming languages, and protocols created technology boundaries that are not easy to cross. As a result enterprises lost the flexibility the agility they need in the marketplace; IS stopped being part of a solution and became more of a problem; enterprises ISs locked them into specific ways of, and created barriers to, carrying out Business.
Architecture Design 1/3 An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. IEEE STD Is used to: Make buy decisions. Discriminate between options. Discover the true requirements. Drive one or more systems to a common use or purpose. Develop system components. Build the system. Understand and conduct changes in the system as the BP is modified.
Architecture Design 2/3 It focuses on the creation of new systems designed to play a role in some business environments. A key factor is the systematic, controlled and coordinated development of systems components and the ability to keep overview over the complexity of the system. The way to do this is to use models to describe parts or aspects of a system. A set of models that together define the essentials of a system is called the architecture of the system. The architecture of a system plays different roles, in the development process and during the life cycle of a system.
Architecture Design 3/3 Besides the development of totally new systems it becomes more and more important to consider the renewal or renovation of existing systems. This requires different approaches and introduces new challenges. One of the major issues is that the systems engineers have to understand the system that has to be renovated. An existing system puts extra constraints on the development of new parts which makes renovation different from development from scratch.
Architecture Framework An architecture framework is a tool… It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. [TOGAF 8, OpenGroup]TOGAF 8, OpenGroup
Enterprise engineering Resources management, enterprise organization, production management.
Business Management Economiy, cognitive, trust management… etc.
Computer science Information system, decision making systems…etc.
Architecture Products: Graphic, Textual, and Tabular… Organizations Locations Functions Applications Entities Database/file Technology Platforms Organizations Locations Functions Applications Entities Database/file Tech Platform X X XX X X X X X X X GraphicTextDictionary Relationships Communicate Capture Analyze Use products to: Tabular Systems Node Name System Name System Function Name System Component Name Operational Node Name Operational Activity Link Name/ID Needline Name Component Interface Name
Enterprise competitive edge An enterprises competitive edge and ultimate success are enabled by its ability to rapidly respond to changing business strategies, governance, and technologies. The competitive edge translates into higher levels of customer satisfaction, shorter work cycles, and reductions in schedules, maintenance costs, and development time, all resulting in lower overall cost of ownership.
Enterprise Architecture Enterprise Architecture is the key facilitating ingredient providing a holistic view and a mechanism for enabling the design and development as well as the communication and understanding of the enterprise. The goals of enterprise architecture are to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages. IS Enterprise Architecture is like urban planning.
City planning metaphor
Urban planning …..What!!? Consists of cutting out IS in autonomous modules, of more and more small size, in a way similar to the city. Between these modules we establish zones of information exchange, which render possible to decouple the various modules.
Urbanisation: the goal? They can be evolved/removed separately while preserving their ability to: Interact with the remainder of the system. Replace some of these subsystems (inter- changeability). Guarantee the possibility to integrate subsystems of various origins (integration). Strengthen the capability to interact with others ISs (Interoperability).
Important rules of Urbanisation The autonomy of functional systems components. The crosscutting nature of the functionalities applied on all system components should be thought to provide an end to end homogenous solutions. Avoiding the spaghetti effect in the enterprises information system. These principles enable the agility of the information system to align with the changes in the enterprise organisation and strategy entrained by markets changes.
Urbanization, the what and why? City planning metaphor: How to re-organize or evolve a city while keeping a normal life for citys inhabitants during the construction or re- construction? In the same way: how to re-organize the IS without totally destroying the existing applications and while maintaining IS functionalities during the re- construction; IS must be reorganized to facilitate its evolution while protecting its informational legacy.
Urbanisation : what else? Allows establishing the link between: mission of the organization, exchanges, internal and external actors, business event, business process, information, applications and infrastructure. Provide a complete description of IS on functional, organisational and technical levels. Being a decision-making support tool to understand change impacts during the evolutions (business, functional, applicative, and technical).
Multilayer approach! The methodology is based on a reference framework integrating four views from the information system: Business view: it describes all the business activities of the enterprise that the information system must support. Functional view: it describes the information system functions which support the business process. Applicative view: it describes all the applicative elements of a data processing system. Technical view: it describes all the hardware, software and technologies used to support the functionality of the information system.
Ishikawa diagram The strategy is modelled by a hierarchy of goals represented by ISHIKAWA diagrams, breaking up them into sub-objectives until reaching the lower level in which all the objectives are achieved by at least one process. This diagram is constrained by the following rules (urbanisation rules for the diagram of objectives): The same objective appears once and only once in the diagram. If an objective is divided in sub-objectives the list of those must be exhaustive. An objective of the lower level must be associated to one or more of performance indicators.
Urbanisation and strategy
Urbanisation and BP Tiré des cours: C. Costaz
Urbanisation Modeling Tiré des cours: C.Costaz
Support Monitoring and Governance Operational processes Processes Identification
Urbanization rules IS urbanization initiative should satisfy the following rules: Affiliation: in the hierarchical decomposing of an information system, each component belongs to one and only one unit. Autonomy: no dependency should exist between units; a unit can deal with an Event from start to end, without the need for treatment in another unit. Asynchronism: a unit can handle an event and send the result without waiting for the response from the receiver. Data Normalization: the results produced by each unit are based on recognized standards. Single Exit Point: the information in each unit is sent by a single point. Data Ownership: each unit is responsible for its own data; updates of these data are carried out by each individual unit. Passage Point: units communicate indirectly via an Entity which is responsible for data flow management.
Urbanisation Business Functions Tiré des cours: C.COSTAZ
Service Oriented Architecture Today, component based development is considered to be the most promising way of developing information systems. The idea is instead of constructing the software from scratch; we achieve a selection, re-configuration and assembly of existing components. Of course there is always a need for new components. The idea is to reuse existing components to compose different functions using particular mechanisms in order to satisfy specific needs of a given business domain or environment.
What is SOA? Applications must open up their capabilities for use by other existing/new applications. It must be possible to combine the services offered by different applications to create higher-level services or composite applications. Technology differences must not matter; interoperability must be a key goal. Open standards must be adopted to enable integration across enterprises. Attention must be paid to governance and manageability in order to make sure that flexibility granted by the first three principles does not lead to chaos.
What is SOA? Services: distinct units of loosely coupled technical or business functions, which can be distributed over a network and can be invoked, combined and reused to create new business processes. These services communicate with each other by passing messages from one service to another, and by coordinating their activities using an orchestrator. Orchestrator: a part of the middleware assembling published services and coordinating their interactions into business flows.
SOA principals? The use of explicit implementation-independent interfaces to define services (adaptors). The use of communication protocols that stress location transparency and interoperability. The definition of services that encapsulate reusable business function.
Middleware capabilities Security. Transformation (Data). Mediation (functional and semantic). Routing. Monitoring. Tracing. End to end QoS. Searching and matching. Invocation.
What qualifies as a service? A service is defined at the right level of granularity, from the point of view of a service consumer. A service is discoverable. Consumers looking for a service can discover its presence, usually by looking up a service registry (as la the yellow pages in a phone directory). A service is self-describing. Potential consumers can learn by themselves how to invoke the service. A service is technology-agnostic. Potential consumers are not constrained from using the service because of a mismatch in hardware or software platforms. A service can be composed with other services to create a higher-level service.
SOA « typical » standards UDDI: Universal Description, Discovery and Integration. WSDL: Web Services Description Language. SOAP: Simple Object Access Protocol.
ServicesServices Services directory (UDDI) Seache a service service Invocation 2 - HTTP Get 3 – WSDL (encapsulaed in a SOAP) service Publication Client Service Provider 4 - request Soap 5 - response Soap 1
Composite service I want to pass tow weeks in a cold, dry, not very far, and cheap country with a lot of touristy views geographic Info. touristy Info. Weather Info. Plane tickets Hotels Car rental Services Travel Agency ?
What is UDDI Stands for Universal Description, Discovery and Integration. UDDI is a directory for storing information about web services. UDDI is a directory of web service interfaces described by WSDL. UDDI communicates via SOAP. For more information see:
How can UDDI be Used? If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. Travel agencies could then search the UDDI directory to find the airline's reservation interface. When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.
UDDI structure A business or company can register three types of information into a UDDI registry. This information is contained into three elements of UDDI. These three elements are : White pages: contains: information which allows others to discover your web service based upon your business: Basic information about the Company and its business. Basic contact information including business name, address, contact phone number etc. A unique identifiers for the company. Yellow pages, contains: More details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want. Green pages, contains technical information about a web service. This is what allows someone to bind to a Web service after it's been found. This includes: The various interfaces The URL locations Discovery information and similar data required to find and run the Web service.
UDDI data structure UDDI includes an XML Schema that describes four core data structures: businessEntity businessService bindingTemplate
BusinessEntity data structure The business entity structure represents the provider of web services. Within the UDDI registry, this structure contains information about the company itself, including contact information, industry categories, business identifiers, and a list of services provided. Here is an example of a fictitious business's UDDI registry entry: Acme Company We create cool Web services General Information John Doe (123)
BusinessService data structure The business service structure represents an individual web service provided by the business entity. Its description includes information on how to bind to the web service, what type of web service it is, and what taxonomical categories it belongs to. Here is an example of a business service structure for the Hello World web service: Hello World Web Service A friendly Web service... Notice the use of the Universally Unique Identifiers (UUIDs) in the businessKey and serviceKey attributes. Every business entity and business service is uniquely identified in all UDDI registries through the UUID assigned by the registry when the information is first entered.
bindingTemplate data structure Binding templates are the technical descriptions of the web services represented by the business service structure. A single business service may have multiple binding templates. The binding template represents the actual implementation of the web service. Here is an example of a binding template for Hello World: Hello World SOAP Binding Because a business service may have multiple binding templates, the service may specify different implementations of the same service, each bound to a different set of protocols or a different network address.
WSDL Web Services Description Language. Written in XML. Used to describe and to locate Web services. For more information see:
The main structure of WSDL It contains set of definitions to describe a service. A WSDL document describes a web service using these major elements: The operations performed by the web service. The messages used by the web service. The data types used by the web service. The communication protocols used by the web service.
WSDL PortType The element is the most important WSDL element. It defines for a web service, the operations that can be performed, and the messages that are involved in these operations. The port defines the connection points to a web service. It can be compared to a functions library in a traditional programming language(or a class in OO language). Each operation can be compared to a function in a traditional programming language.
WSDL Messages The element defines the data elements of an operation. Each message can consist of one or more. Parts can be compared to the parameters of a function call in a traditional programming language.
WSDL Types The element defines the data type that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
In this example element defines " VoyageDirectory " as the name of a port, and " getVoyage " as the name of an operation. The "getTerm" operation has an input message called "getVoyageRequest " and an output message called " getVoyageResponse ". The elements define the parts of each message and the associated data types. Compared to traditional programming, "VoyageDirectory" is a functions library, "getVoyage" is a function with "getVoyageRequest" as the input parameter and "getVoyageReponse" as the return parameter.
Operation Types One-way: The operation can receive a message but will not return a response. Request-response: The operation can receive a request and will return a response. Solicit-response: The operation can send a request and will wait for a response. Notification: The operation can send a message but will not wait for a response
One-Way Operation An example: In this example the port " newVoyageValues " defines a one-way operation called "setVoyage". The " setVoyage " operation allows input of new voyage items messages using a "newVoyageValues" message with the input parameters Date,Destination and Price. However, no output is defined for the operation.
WSDL bindings (1) Defines the message format and protocol details for a service, example binding to SOAP a request-response operation :
WSDL bindings (2) The binding element has two attributes - the name attribute and the type attribute. The name attribute (you can use any name you want) defines the name of the binding, The type attribute points to the port for the binding, in this case the "VoyageDirectory " port. The soap:binding element has two attributes - the transport attribute and the style attribute. The transport attribute defines the SOAP protocol to use. In this case we use HTTP. The style attribute defines the message style, it can be "rpc" or "document". In this case we use document. The operation element defines each operation that the port exposes. For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".
SOAP 1.SOAP is transport neutral; SOAP can be used across HTTP, FTP, SMTP …etc. 2.SOAP includes a whole stack of composable WS- * specifications; WS-Security for inserting security tokens into SOAP headers, WS-ReliableMessaging, WS-Transactions, ….etc. 3.For details see:
SOAP Used for both Messaging and RPC Simple structure Envelope Header (optional) Body
The SOAP Header Element The optional SOAP Header element contains application specific information (like authentication,) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. If you add "mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header.
The Actor Attribute A SOAP message may travel from a sender to a receiver by passing different points along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path. The SOAP actor attribute may be used to address the Header element to a particular endpoint.
The SOAP Body Elements The SOAP Envelope element is the root element of a SOAP message. It defines the XML document as a SOAP message. It should always have the value of: The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.
SOAP over HTTP An HTTP client connects to an HTTP server using TCP. Client sends an HTTP request message to the server, example: POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 The server then processes the request and sends an HTTP response back to the client. The response contains a status code that indicates the status of the request: 200 OK Content-Type: text/plain Content-Length: Or: 400 Bad Request Content-Length: 0
SOAP/HTTP Binding A SOAP request could be an HTTP POST or an HTTP GET request SOAP=HTTP + XML, example: POST /login.ispatu-ryukyus, HTTP/1.1 Host:www.u-ryukyus.ac.jp Content-Type: application/soap+xml; charset=utf-8 Content-Length:1000 > Layth Okinawa ……………..
Messaging Quality of Service Transport Description Components Transport Interface + Bindings Composite XMLNon-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model
Service Orientation « review » Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us. Similarly to objects and components, a service is a fundamental building block that: Combines information and behaviour. Hides the internal workings from outside intrusion. Presents a relatively simple interface to the rest of the organism. Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspects. Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations.
Messaging Quality of Service Transport Description Components Transport Interface + Bindings Composite XMLNon-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model WS-RM WSDL*WS-Policy* HTTP, TCP/IP, SMTP, FTP, … UDDI, WS-Addr, Metadata Exch.,… WS-C WS-N* WS-RFWS-BPEL WS-Security* WS-AT WS-BA SOAP, WS-Addr* JMS, RMI/IIOP,... SCA Other SOA standards
Messaging Quality of Service Transport Description Components Transport Interface + Bindings Composite XMLNon-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model WS-RM WSDL*WS-Policy* HTTP, TCP/IP, SMTP, FTP, … UDDI, WS-Addr, Metadata Exch.,… WS-C WS-N* WS-RFWS-BPEL WS-Security* WS-AT WS-BA SOAP, WS-Addr* JMS, RMI/IIOP,... SCA
SOA and BPM SOA is about constructing software components that can be reused in context unknown at design time Composition. BPM is about being able to precisely model and possibly change the context in which enterprise components are used But how the two meet?
Entity Elements of BPM Activity State Event Actor Content performs Initiates changes generates Services Represented by
BPEL BPEL is an XML language for defining the composition of (web) services into (new) services (Paul Brown, FiveSight) BPEL is above all a simple Orchestration language not a Business Process Language. A process is composed of a large set of orchestration definitions interacting with each other. BPEL assumes that business processes can be fully captured in a single definition, including all possible exception paths.
A very simple example A buyer orders some goods from a supplier. The supplier performs a series of steps to fulfill the order. Approve the order Update the order entry system Update the billing system …
Web Services Business Process Execution Language (WS-BPEL) is a language for describing business processes based on Web Services Processes described using WS-BPEL execute functionality by using Web Service interfaces exclusively WS-BPEL Specification is administered by OASIS WS-BPEL is an orchestration language, not a choreography language Orchestration specifies an executable process that involves message exchanges, such that that the message exchange sequences are controlled by the orchestration designer. Choreography specifies a protocol for peer-to-peer interactions, defining the legal sequences of messages exchanged with the objective of guaranteeing interoperability A choreography is not directly executable A choreography can be implemented through an orchestration (i.e. a BPEL process)
Executable process vs. Abstract process Business processes may be classified as either executable or abstract. These and other related terms are defined as follows. Executable process An executable process defines a coordinated set of activities that are performed within a single scope of control in response to a business event. The single scope of control aspect is important because it allows an executable process to be controlled directly by a system. In an electronic commerce context, executable processes exist within business entity boundaries, and their details are not visible externally. Hence they are also referred to as private. The term orchestration has come into common use to refer to the coordination of Web services in a private executable context. Abstract process An abstract process defines the interaction between two or more independent systems via their external interfaces in response to a business event. It can also be referred to as a business protocol. An abstract process is by definition not directly controlled by any of its participating entities, and hence cannot be implemented as an executable system. In an electronic commerce context, abstract processes exist between business entity boundaries and are visible externally. Hence they are also referred to as public. The term choreography has come into common use to refer to the coordination of Web services in a public abstract context. BPEL exploits the synergy between abstract processes and executable processes by defining a core set of common constructs with extensions added to support each of these distinct process types.
Business processes defined using an XML-based language Web services are the model for process decomposition and assembly. The same orchestration concepts are used for both the external (abstract) and internal (executable) views of a business process. An identification mechanism for process instances is provided at the application message level. The basic lifecycle mechanism is in implicit creation and termination of process instances. A long-running transaction model is defined to support failure recovery for parts of long-running business processes. Language built on compatible Web services standards in a composable and modular manner.
BPEL key elements 1/2 The language includes the following key elements: Partner link type A partner link type defines the relationship between two Web services by specifying the role played by each of the services and the port types used in the interaction. Variable A variable is used to store a local copy of a message or data in a process instance. Correlation set A correlation set defines the message properties (aliases for message parts) to be used to match incoming messages to the correct process instance. A correlation set is needed if a process has more than one receive or pick activity. A correlation set, once initialized, acts as a constant for the rest of the process lifetime. Receive A receive is used to wait for a request message sent to a Web service implemented by the process. Reply A reply is used to send a response message to the sender of the request message that initiated the process instance. Pick A pick is used to receive a message via one or more port types and select a branch based on message type received.
BPEL key elements 2/2 Sequence A sequence is used to perform a set of activities in a series. Flow A flow is used to perform a set of activities in parallel. Link A link is used to create a synchronization point between parallel activities. Switch A switch is used to select a branch based on the evaluation of an expression. While A while loop is used to iterate under the control of a boolean expression. Invoke An invoke is used to call a Web service. Wait A wait is used to delay for a period of time. Empty An empty activity does nothing. It may be used as a placeholder for an activity yet to be specified, or when a fault needs to be caught and suppressed. BPEL also has constructs for expression handling, defining scope, event handling, fault handling within units of work, and compensation to reverse the effect of committed units of work. BPEL is dependent on the WSDL 1.1 standard:
WS-BPEL process definition Recursive composition and partner links Variables Correlation sets Basic and structured activities Scopes Compensation handling
process imports Declare dependencies on external XML Schema or WSDL definitions extensions Declare namespaces of WS-BPEL extension attributes and elements variables Data holding state of a business process or exchanged with partners partner links Relationships that a WS- BPEL process will employ in its behavior correlation sets Application data fields that together identify a conversation message exchanges Relationship between inbound and outbound message activities event handlers Concurrently process inbound messages or timer alarms fault handlers Deal with exceptional situations in a process primary activity Perform the process logic – any number of activities may be recursively nested XML schemas WSDL definitions
Web Service Financial institutions Web service implementation (Loan Approver) Web Service WSDL Loan Approval PortType Loan Approval Process invoke receive reply WS-BPEL processes are exposed as Web services to business partners WS-BPEL processes interact with Web services exposed by business partners
WDSL describes functionality of services provided by a partner Partner Link describes the shape of the relationship with a partner by describing the Port Types used in a peer to peer relationship Example: Reference to WDSL portType element
process partner link partner link type Peer-to-peer conversational partner relationship WSDL port type myRole Provided port type WSDL port type partnerRole Required port type receive Inbound request – service provided by the process invoke Outbound request – service required by the process
Variable construct is used to state information related to workflow logic Variables can contain entire messages and data sets formatted as XML schema types Example: Message Name from Partner Process Definition
process assign xsl:transform receive request response invoke request reply response 42 WSDL message WSDL message WSDL messages Variables defined using WSDL messages 42 XML schemas XML Schema elements / types Variables defined using XML schema elements or types
How to identify stateful instances via stateless WS interfaces? A process instance is assigned one or more keys Business data is used as key, e.g., customerID A key can be compound, e.g., (customerID, orderNumber) WS-BPEL calls a key a correlation set – it is used to correlate an incoming message with a process instance Process 4 (0123,15) Process 3 (0815,42) Process 2 (4711,37) Process 1 (0815,12) Message 2 customerID orderNumber Message 1
process receivereply invoke Invoke a one-way or request-response operation Do a blocking wait for a matching message to arrive / send a message in reply validate assign Update the values of variables or partner links with new data Validate XML data stored in variables throw rethrow Generate a fault from inside the business process Forward a fault from inside a fault handler exit Immediately terminate execution of a business process instance compensate compensateScope Invoke compensation on all completed child scopes in default order Invoke compensation on one completed child scope wait Wait for a given time period or until a certain time has passed empty No-op instruction for a business process extensionActivity Wrapper for language extensions
process flow Contained activities are executed in parallel, partially ordered through control links sequence Contained activities are performed sequentially in lexical order while Contained activity is repeated while a predicate holds repeatUntil Contained activity is repeated until a predicate holds pick Block and wait for a suitable message to arrive (or time out) forEach Contained activity is performed sequentially or in parallel, controlled by a specified counter variable if-elseif-else Select exactly one branch of activity from a set of choices scope Associate contained activity with its own local variables, partner links, etc., and handlers 2.N.1. … B C A c c c1c2 … 2.N.1. … … AM2M1
Prescribes Standards and Conventions StandardsRules Conventions Technical Standards View DoDAF An Integrated Architecture with Three Views Information Flow Operational Elements Activities/ Tasks Identifies What Needs To Be Done And Who Does It Operational View Systems Data Flow Communications X Y X Z X Y Y Relates Systems and Characteristics to Operational Needs Systems View
DODAF Products The DODAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture The 26 DODAF views are designed to document the entire architecture, from requirements to implementation
DODAF Products - Views The list of products is refined into four views: All Views (AV): is the overarching information describing the architecture plans, scope, and definitions Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects System View (SV): describes the system and applications supporting the mission functions Technical Standards View (TV): describes the policies, standards and constraints
DODAF Products - Essential The current DODAF version indicates a subset of work products that should be developed at a minimum (essential) AV-1: Overview and Summary Information AV-2: Integrated Dictionary OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Operational Activity Model SV-1: System Interface Description TV-1: Technical Standards Profile
OV-3 – Operational Information Exchange Matrix Table Headers Specified in Framework: Name of Operational Needline Supported (from OV-2) Name of Information Exchange Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?) Purpose or Triggering Event Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID) Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID) Performance Requirements (Frequency, Timeliness, Throughput, Other) Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive) Threats (Physical, Electronic, Political/Economic) Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)
OV-5 – Operational Activity Model
SV-1 – System Interface Description
TV-1 – Technical Standards Profile
References Elements of this presentation are obtained from: Constructing Software For Service Oriented Architecture Jean-Jacques Dubray, The Pennsylvania State University, The Smeal College of Business Administration. DoD Architecture Framework Overview, Alessio Mosto, OS.html#SA00005_table OS.html#SA00005_table 122
An Introduction to Knowledge Management
Objectives for this session History & theory of Knowledge Management (KM) KM models Ontology and its design methodology
What is Knowledge Modeling? Knowledge modeling is a process of creating a computer interpretable model of knowledge or standard specifications about a kind of process and/or about a kind of facility or product. The resulting knowledge model can only be computer interpretable when it is expressed in some knowledge representation language or data structure that enables the knowledge to be interpreted by software and to be stored in a database or data exchange file.knowledge representation
Seek knowledge from the cradle to the grave Expertise, and skills acquired by a person through experience or education; the theoretical or practical understanding of a subject: Knowing that (facts and information) Knowing how (the ability to do something)
What is Knowledge? Knowledge is justified true belief. Ayer, A.J. (1956). The Problem of Knowledge. Knowledge is a fluid mix of framed experience, values, contextual information and expert insight that provides a framework for evaluating and incorporating new experience and information. It originates and is applied in the minds of knowers. In organizations it often becomes embedded not only in documents or repositories but also in organizational processes, practices and norms. Davenport, T.H. & Prusak, L (1998). Working Knowledge. Knowledge is information in action. ODell C. & Grayson Jr., C.J. (1998). If only we knew what we know.
Two types of knowledge Explicit knowledge Formal or codified Documents: reports, policy manuals, white papers, standard procedures Databases Books, magazines, journals (library) Implicit (Tacit) knowledge Informal and uncodified Values, perspectives & culture Knowledge in heads Memories of staff, suppliers and vendors Documented information that can facilitate action. Know-how & learning embedded within the minds people. Knowledge informs decisions and actions. Sources: Polanyi, M. (1967). The tacit dimension. Leonard, D. & Sensiper, S. (1998). The Role of Tacit Knowledge in Group Innovation. California Management Review.
Layers of knowledge Implicit (Tacit) Explicit Individual Organizational In peoples heads. Undocumented ways of working in teams, teaching. Cultural conventions known and followed but not formalized. Personal documents on my C:\ Formalized process for developing curriculum. Corporate polices and procedures. Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto.
One Perspective of KM KM [Knowledge Management] involves blending a companys internal and external information and turning it into actionable knowledge via a technology platform. Susan DiMattia and Norman Oder in Library Journal, September 15, 1997.
Understanding KM Understanding Knowledge Management requires an understanding of knowledge and the knowing process and how that differs from information and information management.
Classic Data to Knowledge Hierarchy Wisdom Knowledge Information Data
From Facts to Wisdom
Data, Information & Knowledge "We are drowning in information but starved for knowledge" Naisbitt, J. (1984) Megatrends: Ten new directions transforming our lives. Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto.
Knowledge Management Models Document Technology Learning & Communication
History of Knowledge Knowledge management is a new business strategy, but its techniques can be traced to the work of documentalists in the early part of the twentieth century.
Documentalists as Knowledge Managers In Europe and America in the first part of the twentieth century, documentalists had grand visions of collecting, codifying and organizing the worlds knowledge. KM is seen as in the form of structural linguistics and semiotics..
Caution It would be a mistake, though, to define Knowledge Management as solely the domain of documents.
Contentnets and KM As knowledge repositories for tacit knowledge that has been made explicit For best practices databases For expert yellow pages Online learning and knowledge sharing Knowledge sharing boards
Peoplenets & Processnets Group learning applications Social networks and Web 2.0 to connect individuals with each other for mentoring and knowledge sharing, decision support & decision making and capturing ideas and turn them into action… etc.
The Challenges of Collaboration & Knowledge Sharing Focusing exclusively on the technical issues of knowledge sharing is a vey good way to a very expensive failure. A focus on the people issues dramatically increases the potential for success. David Coleman, IBM Manager, San Francisco in Knowledge Management, a Real Business Guide, London:IBM, nd.
KM advantages Flexibility and the ability to act quickly is necessary in a changing environment New projects can benefit from alliances and learning from in-house experts and creative thinkers. Innovation as a way of life
KM: Learning and Communication Process In simple language KM is an effort to capture not only explicit factual information about the system and the organization but also the tacit information and knowledge that exists in a system or organization, usually based on the experience and learning of individuals, in order to enhance systems implication in organization's mission achievement. The eventual goals are: Extract, represent and keep the knowledge capital. Share knowledge about the organization and the system among the different actors of the organization, its partners and customers.
How to represent the knowledge Links and structures Notation Ontology.
What is an Ontology? An ontology is a specification of a conceptualization that is designed for reuse across multiple applications and implementations. …a specification of a conceptualization is a written, formal description of a set of concepts and relationships in a domain of interest. (Peter Karp (2000) Bioinformatics). It is a formal explicit description of concepts in a domain, properties of each concept describing various features and attributes of the concept (slots (sometimes called roles or properties)), and restrictions on slots (facets (sometimes called role restrictions)). An ontology together with a set of individual instances of classes constitutes a knowledge base. In reality, there is a fine line where the ontology ends and the knowledge base begins.
Ontology as a system of concepts Used as conceptual building blocks of knowledge-intensive systems Something deeper than metadata It provides foundation on which a KB or an application system is built Ontology Knowledge Base (Model) An explicit specification of a hidden conceptualization of the target domain
Why? To share common understanding of the structure of information among people or software. Enabling reuse of domain knowledge. For example, models for many different domains need to represent the notion of time including notions of time intervals, points in time, and so on. If one develops such an ontology in detail, others can simply reuse it for their domains. Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming- language code makes these assumptions hard to change. Separating the domain knowledge from the operational knowledge is another common use of ontologies. We can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves. Analyzing domain knowledge is possible once a declarative specification of the terms is available.
From Knowledge Eng. To Ontological Eng. KE is the research on: Domain-specific heuristics for a stand-alone problem solver OE is the research on: General/reusable/sharable/long-lasting concepts for building a KB/model for helping people solve problems.
Dichotomy of ontology Light-weight Ontology One like Yahoo ontology Vocabulary rather than concepts Annotation-oriented ontology Used for Information representation and search Heavy-weight Ontology Concepts rather than vocabulary for unified understanding the target system for building ontology-aware system Keep knowledge separated from system changes.
The fundamental role of an ontology An ontology is not directly used for problem solving It gives a specification of knowledge and information models in a system The role of an ontology to a knowledge base is to give definitions of concepts used in the knowledge representation and constraints among concepts to make the knowledge base consistent and transparent which are the necessary properties of sharable and reusable knowledge Knowledge Amplifier systems.
Know that Ontologies Design principles
Why Ontologies? (review) To share common understanding of the structure of information among people or software agents To enable reuse of domain knowledge To make domain assumptions explicit To separate domain knowledge from the operational knowledge To analyze domain knowledge
Building Ontologies(NN & DLM) In practical terms, developing an ontology includes: defining classes in the ontology, arranging the classes in a taxonomic (subclass–superclass) hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances.
Fundamental thumb rules There is no one correct way to model a domain there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.
Fundamental thumb rules Ontology development is necessarily an iterative process. Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.
Step 1. Determine the domain and scope of the ontology What is the domain that the ontology will cover? For what we are going to use the ontology? For what types of questions the information in the ontology should provide answers? Who will use and maintain the ontology?
Example! Consider an ontology which helps representing the best combination (wine/ food). Representation of food and wines is the domain of the ontology. We plan to use this ontology for the applications that suggest good combinations of wines and food. Naturally, the concepts describing different types of wines, main food types, the notion of a good combination of wine and food and a bad combination will figure into our ontology. It is unlikely that the ontology will include concepts for managing inventory in a winery or employees in a restaurant. If it will be used to help restaurant customers decide which wine to order, we need to include retail-pricing information.
Step 1 Example Competency question Which wine characteristics should I consider when choosing a wine? Is Bordeaux a red or white wine? Does Cabernet Sauvignon go well with seafood? What is the best choice of wine for grilled meat? Which characteristics of a wine affect its appropriateness for a dish? Does a bouquet or body of a specific wine change with vintage year?
Step 2. Consider reusing existing ontologies Sure, if they exist!!!
Step 3. Enumerate important terms in the ontology What are the terms we would like to talk about? What properties do those terms have? What would we like to say about those terms? Example - wine, grape, winery, location, a wines color, body, flavor and sugar content; different types of food, such as fish and red meat; subtypes of wine such as white wine, and so. It is important to get a comprehensive list of terms without worrying about overlap between concepts they represent, relations among the terms, or any properties that the concepts may have, or whether the concepts are classes or slots.
Step 4. Define the classes and the class hierarchy Methods Top-down: development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. For example, we can start with creating classes for the general concepts of Wine and Food. Then we specialize the Wine class by creating some of its subclasses: White wine, Red wine, Rosé wine. We can further categorize the Red wine class and so on.
Step 4. Define the classes and the class hierarchy Methods Bottom-up: starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. For example, we start by defining classes for Pauillac and Margaux wines. We then create a common superclass for these two classesMedocwhich in turn is a subclass of Bordeaux.
Step 4. Define the classes and the class hierarchy Methods -Combination: it is a combination of the top- down and bottom-up approaches: We define the more salient concepts first and then generalize and specialize them appropriately. We might start with a few top-level concepts such as Wine, and a few specific concepts, such as Margaux. We can then relate them to a middle-level concept, such as Medoc.
Step 4. Define the classes and the class hierarchy Whichever approach we choose, we usually start by defining classes. From the list created in step3, we select the terms that describe objects having independent existence rather than terms that describe these objects. These terms will be classes in the ontology. We organize the classes into a hierarchical taxonomy by asking if by being an instance of one class, the object will necessarily (i.e., by definition) be an instance of some other class. hierarchical arrangements of concepts: If a class A is a superclass of class B, then every instance of B is also an instance of A. This implies In other words, the class B represents a concept that is a kind of A. For example, every Pinot Noir wine is necessarily a red wine. Therefore the Pinot Noir class is a subclass of the Red Wine class.
Step 4. Define the classes and the class hierarchy Top-down Food and Wine -- followed by White, Blush and Red Bottom-up define specific wine class first and the work your way up Combination
Step 5. Define the properties of classes slots Types of properties intrinsic properties such as the flavor of a wine; extrinsic properties such as a wines name, and area it comes from; parts, if the object is structured; these can be both physical and abstract parts (e.g., the courses of a meal) relationships to other individuals; these are the relationships between individual members of the class and other items (e.g., the maker of a wine, representing a relationship between a wine and a winery, and the grape the wine is made from.)
Step 5. Define the properties of classes slots We have already selected classes from the list of terms we created in step3. Most of the remaining terms are likely to be properties of these classes. For each property in the list, we must determine which class it describes. Describe the internal structure of concepts. Examples a wines color, body, flavor sugar content location of a winery.
Completing slots In addition to the properties we have identified earlier, we need to add the following slots to the Wine class: name, area, maker, grape.
Inheritance All subclasses of a class inherit the slot of that class. For example, all the slots of the class Wine will be inherited to all subclasses of Wine, including Red Wine and White Wine. We will add an additional slot, tannin level (low, moderate, or high), to the Red Wine class. The tannin level slot will be inherited by all the classes representing red wines (such as Bordeaux and Beaujolais). Example: Red wine inherits name, area, maker, grape slots from wine. add an additional slot, tannin level (low, moderate, or high), to the Red Wine class.
Step 6. Define the facets of the slots Slot cardinality defines how many values a slot can have. Sometimes it may be useful to set the maximum cardinality to 0. Slot-value type what types of values can fill in the slot. allowed values other features of the values the slot can take.
Step 6. Define the facets of the slots common value types: String Number Boolean Enumerated Instance-type slots allow definition of relationships between individuals. Slots with value type Instance must also define a list of allowed classes from which the instances can come. For example, a slot produces for the class Winery may have instances of the class Wine as its values.
Step 6 - rules slot Domain and Ranges When defining a domain or a range for a slot, find the most general classes or class that can be respectively the domain or the range for the slots. On the other hand, do not define a domain and range that is overly general: all the classes in the domain of a slot should be described by the slot and instances of all the classes in the range of a slot should be potential fillers for the slot. Do not choose an overly general class for range (i.e., one would not want to make the range THING) but one would want to choose a class that will cover all fillers. We can attach the tannin level slot to each of the classes representing red wines (e.g., Bordeaux, Merlot, Beaujolais, etc.). However, since all red wines have the tannin-level property, we should instead attach the slot to this more general class of Red Wines. Generalizing the domain of the tannin level slot further (by attaching it to the Wine class instead) would not be correct since we do not use tannin level to describe white wines for example.
Step 6 - rules slot Domain and Ranges If a list of classes defining a range or a domain of a slot includes a class and its subclass, remove the subclass. If a list of classes defining a range or a domain of a slot contains all subclasses of a class A, but not the class A itself, the range should contain only the class A and not the subclasses. If a list of classes defining a range or a domain of a slot contains all but a few subclasses of a class A, consider if the class A would make a more appropriate range definition.
Step 7 - Creating Instances Body: Light Color: Red Flavor: Delicate Tannin level: Low Grape: Gamay (instance of the Wine grape class) Maker: Chateau-Morgon (instance of the Winery class) Region: Beaujolais (instance of the Wine-Region class) Sugar: Dry
DONE?? Consistency/validity/sanity checks???
Step 8 - Defining classes and a class hierarchy Ensuring that the class hierarchy is correct An is-a relation A subclass of a class represents a concept that is a kind of the concept that the superclass represents. A single wine is not a subclass of all wines Transitivity of the hierarchical relations
Step 8 - Defining classes and a class hierarchy Evolution of a class hierarchy distinction between classes and their names hence synonyms of concept name do not represent different classes Avoid class hierarchy cycles All the siblings in the hierarchy (except for the ones at the root) must be at the same level of generality.
Step 8 - Defining classes and a class hierarchy How many is too many and how few are too few? If a class has only one direct subclass there may be a modeling problem or the ontology is not complete. If there are more than a dozen subclasses for a given class then additional intermediate categories may be necessary. (may not always be possible)
Step 8 - Defining classes and a class hierarchy Multiple Inheritance When do you introduce a new class Subclasses of a class usually (1) have additional properties that the superclass does not have, or (2) restrictions different from those of the superclass, or (3) participate in different relationships than the superclasses
Step 8 - Defining classes and a class hierarchy Counter example to thumb rule in previous slide Classes in terminological hierarchies do not have to introduce new properties MeSH at NLM National Institute of Health purpose is just to organize for ease of searching/indexing
Step 8 - Defining classes and a class hierarchy A new class or a property value? Class White Wine or simply property of class Wine that takes value White Depends on how important a concept White Wine is in the domain An instance or a class? starts with deciding what is the lowest level of granularity in the representation. Individual instances are the most specific concepts represented in a knowledge base.
Step 8 - Limiting the scope The ontology should not contain all the possible information about the domain: you do not need to specialize (or generalize) more than you need for your application (at most one extra level each way). The ontology should not contain all the possible properties of and distinctions among classes in the hierarchy.
Next Choose domain IN WHICH YOU ARE EXPERT. Requirements Identify intended use Show all steps mentioned so far…
References The elements of this presentatiion are obtained from: Cartic Ramakrishnan, LSDIS Lab, University of Georgia. ASIS KM Website Brint.com Knowledge Portal Knowledge Management Research Center Karl-Erik Sveiby and Knowledge Associates University of Arizona Riichiro MizoguchiSIR, Osaka University Canadian Institutional Research and Planning Association Cartic Ramakrishnan, LSDIS Lab, University of Georgia Ontology Working Group
Pattern oriented software architecture
Definitions Is an original object used to make copies, or a set of repeating objects in a decorative design and in other disciplines. A pattern is a general reusable solution to a commonly occurring problem. A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. An organized collection of design patterns that relate to a particular field is called a pattern language.
Definitions The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. A design pattern for must be broad enough to be applied to differnet situations, but not so vague that it doesn't help the designer make decisions. The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution.
Pattern documentation It contains the following sections: Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern. Also Known As: Other names for the pattern (including aliases). Abstract: a short description. Intent: A description of the goal behind the pattern and the reason for using it. Solution: description of the solution. Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used. Applicability: Situations in which this pattern is usable; the context for the pattern. Structure: A graphical representation of the pattern. Issues: points to be considered during the implimentation. Trade-Offs: positive and negative side effects on the other aspects.
Pattern documentation Participants: A listing of the classes and objects used in the pattern and their roles in the design. Collaboration: A description of how classes and objects used in the pattern interact with each other. Consequences: A description of the results, side effects, and trade offs caused by using the pattern. Implementation: A description of an implementation of the pattern; the solution part of the pattern. Sample Code: An illustration of how the pattern can be used in a programming language. Known Uses: Examples of real usages of the pattern. Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.
Software design patterns Design Patterns - Elements of Reusable Object- Oriented Software was written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Grouped into three categories: creational patterns, structural patterns, and behavioral patterns.
Patterns categories In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns.
Abstract factory Provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme.
Abstract factory Sheet metal stamping equipment is an example of an Abstract Factory for creating auto body parts. Using rollers to change the dies, the concrete class can be changed. The possible concrete classes are hoods, trunks, roofs, left and right front fenders,etc. The master parts list ensures that classes will be compatible. Note that an Abstract Factory is a collection of Factory Methods.
Factory Methods The factory method design pattern centralize creation of an object of a specific type choosing one of several implementations.
Builder pattern The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.
Prototype pattern The Prototype pattern specifies the kind of objects to instantiate using a prototypical instance.
Singleton pattern The Singleton pattern ensures that a class has only one instance, and provides a global point of reference to that instance (At any time, at most one unique instance of the class exists).
Structural patterns Structural patterns ease the design by identifying a simple way to realize relationships between entities. The Bridge pattern decouples an abstraction from its implementation, so that the two can vary independently (Switch). The Adapter pattern allows otherwise incompatible classes to work together by converting the interface of one class to an interface expected by the clients.
Composite pattern The Composite composes objects into tree structures, and lets clients treat individual objects and compositions uniformly.
Composite pattern The composite pattern defines class hierarchies consisting of leaf objects and composite objects. Composite objects are treated the same way as leaf objects (their value is added, subtracted, etc. from another value). With composites, it is easy to add new kinds of components. Composite objects are treated the same way as leaf objects (their value is added, subtracted, etc. from another value).
Decorator pattern The Decorator attaches additional responsibilities to an object dynamically. Adding or removing frames and mattes provide more flexibility than requiring all paintings to have the same frame. Paintings can be customized with the addition of mattes and frames. The cost of customization is determined by the framing and matting options chosen. The decorator and component remain separate.
Facade pattern The Facade defines a unified, higher level interface to a subsystem, that makes it easier to use. When ordering from a catalog, consumers do not have direct contact with the Order Fulfillment, Billing, and Shipping departments. The Customer Service Representative acts as a Facade, or unified interface, to each of the departments involved in the transaction.
Flyweight pattern and proxy pattern The Flyweight uses sharing to support large numbers of objects efficiently. The proxy introduces a level of indirection when accessing an object. The indirection can be used for security, or disguising the fact that an object is located in a different address space.
Behavioral design patterns Behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication. This type of design pattern includes:
The Chain of Responsibility pattern The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver. A mechanical sorting bank uses a single slot:for all coins. As each coin is dropped, a Chain of Responsibility determines which tube accommodates each coin. If a tube cannot accommodate the coin, the coin is passed on until a tube can accept the coin.
Command pattern The Command pattern allows requests to be encapsulated as objects, thereby allowing clients to be parameterized with different requests. The check at a restaurant is used to encapsulate the customer s order. The written order corresponds to the command. It creates a binding between the cook and the action. The object that invokes the command and the one that performs it are decoupled. Commands can be assembled into composite commands. When several people at a table order on the same check, the command is a composite.
Interpreter and Iterator patterns The Interpreter pattern defines a grammatical representation for a language, and an interpreter to interpret the grammar. The Iterator provides ways to access elements of an aggregate object sequentially without exposing the underlying structure of the object.
Iterator patterns The channel selector on modern day television sets is an example of an Iterator. Rather than a dial containing all possible channels, or one button per tuned channel, today s television sets have a Next and Previous button for tuning channels. The Channel Surfer doesn t need to know if Channel 3 or Channel 4 comes after Channel 2.
Mediator pattern The Mediator defines an object that controls how a set of objects interact. Loose coupling between colleague objects is achieved by having colleagues communicate with the Mediator, rather than one another. Constraints are localized within the Mediator. Changes to constraints need only be dealt with in the tower. Interactions are decoupled. The many to many interactions are replaced with a one to many interaction.. Control is centralized. Complexity of interaction is traded for complexity in the mediator.
Memento pattern The Memento captures and externalizes an object s internal state, so the object can be restored to that state later. It eliminates the need for everyone needs to know an object state ettings to store them inside. Stores the managed information outside of the manging object (i.e. not in his memory).
Observer pattern The Observer defines a one to many relationship, so that when one object changes state, the others are notified and updated automatically. When a bidder at an auction accepts a bid, he or she raises a numbered paddle which identifies the bidder. The bid price then changes and all Observers must be notified of the change. The auctioneer then broadcasts the new bid to the bidders.
State pattern The State pattern allows an object to change its behavior when its internal state changes. Coffee machine!
Strategy A Strategy defines a set of algorithms that can be used interchangeably. Strategies combine families of related algorithms and allow the algorithm to vary independently of the context; The context alone does not dictate which method of willl be used. Strategies offer a choice of implementations.
Template Method The Template Method defines a skeleton of an algorithm in an operation, and defers some steps to subclasses. Templates factor out what is common, so that it can be reused. Multiple elevations can be built from a basic floor plan. The specific elevation does not need to be chosen until later in the process.
Visitor pattern The Visitor pattern represents an operation to be performed on the elements of an object structure, without changing the classes on which is operates. An outside consultant coming into a department, to meet with everyone in the department on a one-onone basis is an example of Visitor. While the visitor is escorted to each room, she does nothing. Once she arrives at an office, she springs into action interviewing the employee (sending messages and obtaining results).
References The elements of this presentation are obtained from: AG Communication Systems – 1999 Examples to Accompany:Design Patterns Elements of Reusable Object-Oriented Software. Wikipedia.