2 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.
3 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.
4 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 STDIs 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.
5 Architecture Design 2/3It 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.
6 Architecture Design 3/3Besides 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.
7 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]
8 Enterprise engineering Resources management, enterprise organization, production management.
9 Business ManagementEconomiy, cognitive, trust management… etc.
10 Computer scienceInformation system, decision making systems…etc.
12 Enterprise competitive edge An enterprise’s 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.
13 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.
15 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.
16 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).
17 Important rules of Urbanisation The autonomy of functional system’s 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 enterprise’s 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.
18 Urbanization, the what and why? City planning metaphor: How to re-organize or evolve a city while keeping a normal life for city’s 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.
19 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).
25 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.
26 Ishikawa diagramThe 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.
32 Urbanization rulesIS 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.
33 Urbanisation Business Functions Tiré des cours: C.COSTAZ
34 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.
35 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.
36 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.
38 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.
44 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.
46 SOA « typical » standards UDDI: Universal Description, Discovery and Integration.WSDL: Web Services Description Language.SOAP: Simple Object Access Protocol.
47 Services Client Services directory (UDDI) 2 - HTTP Get Seache a serviceServices directory (UDDI)3 – WSDL(encapsulaed in a SOAP)1service Publication4 - request “Soap”service InvocationService Provider5 - response “Soap”
48 ? Composite service Services geographic Info. touristy Info. I want to pass tow weeks in a cold, dry, not very far, and cheap country with a lot of touristy viewsServicesgeographic Info.touristy Info.Weather Info.Plane ticketsTravel AgencyHotelsCar rental
49 What is UDDIStands 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:
50 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.
51 UDDI structureA 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 interfacesThe URL locationsDiscovery information and similar data required to find and run the Web service.
52 UDDI data structureUDDI includes an XML Schema that describes four core data structures:businessEntitybusinessServicebindingTemplate
53 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:<businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40" operator=" authorizedName="John Doe"><name>Acme Company</name><description> We create cool Web services </description><contacts> <contact useType="general info"><description>General Information</description><personName>John Doe</personName><phone>(123) </phone></contact> </contacts><businessServices> ... </businessServices></businessEntity>
54 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:<businessService serviceKey="uuid:D6F1B765-BDB D E5A2A" businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"><name>Hello World Web Service</name><description>A friendly Web service</description><bindingTemplates> ... </bindingTemplates> </businessService>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.
55 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:<bindingTemplate serviceKey="uuid:D6F1B765-BDB D E5A2A" bindingKey="uuid:C0E6D5A8-C446-4f01-99DA- 70E212685A40"><description>Hello World SOAP Binding</description><accessPoint URLType="http"> </accessPoint> </bindingTemplate>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.
56 Web Services Description Language. Written in XML. WSDLWeb Services Description Language.Written in XML.Used to describe and to locate Web services.For more information see:
57 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:<portType>The operations performed by the web service.<message>The messages used by the web service.<types>The data types used by the web service.<binding>The communication protocols used by the web service.
58 WSDL PortTypeThe <portType> 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.
59 WSDL MessagesThe <message> element defines the data elements of an operation.Each message can consist of one or more <part>. Parts can be compared to the parameters of a function call in a traditional programming language.
60 WSDL TypesThe <types> 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.
62 In this example<portType> 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 <message> 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.
63 Operation TypesOne-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
64 One-Way Operation An example: <message name="newVoyageValues"> <part name=“Date" type="xs:string"/><part name=“Destination" type="xs:string"/><part name=“Price" type="xs:string"/></message><portType name=" VoyageDirectory "><operation name="setVoyage"><input name="newVoyage" message="newVoyageValues"/></operation></portType >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.
65 WSDL bindings (1)Defines the message format and protocol details for a service, example binding to SOAP a request-response operation :<binding type=" VoyageDirectory " name="bi"><soap:binding style="document“transport=" /><operation><input> <soap:body use="literal"/> </input><output> <soap:body use="literal"/> </output></operation></binding>
66 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".
67 SOAPSOAP is transport neutral; SOAP can be used across HTTP, FTP, SMTP …etc.SOAP includes a whole stack of “composable” WS- * specifications; WS-Security for inserting security tokens into SOAP headers, WS-ReliableMessaging, WS-Transactions, ….etc.For details see:
68 SOAP Used for both Messaging and RPC Simple structure Envelope Header (optional)Body
69 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.
70 The Actor AttributeA 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.
71 The SOAP Body ElementsThe 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.
72 SOAP over HTTPAn 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/plainContent-Length: 200The 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 OKContent-Length:Or:400 Bad Request Content-Length: 0
73 SOAP/HTTP BindingA SOAP request could be an HTTP POST or an HTTP GET requestSOAP=HTTP + XML, example:POST /login.ispatu-ryukyus, HTTP/1.1 Host:Content-Type: application/soap+xml; charset=utf-8 Content-Length:1000<soap:Envelope xmlns:soap="<soap:Header><user:credentials soap:mustUnderstand="1"> ><username>Layth</username><password>Okinawa</password></user:credentials>……………..</soap:Envelope>
74 Web Services Standards for SOA The Web Services Platform Architecture MessagingQuality of ServiceTransportDescriptionComponentsInterface + BindingsCompositeXMLNon-XMLSecurityPolicyDiscovery, Negotiation, AgreementAtomicOrchestrationProtocolsStateReliable MessagingTransactionsComponent Model74
75 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.
76 Other SOA standards UDDI, WS-Addr, Metadata Exch.,… WS-BPEL WS-C WS-N* MessagingQuality of ServiceTransportDescriptionComponentsInterface + BindingsCompositeXMLNon-XMLSecurityPolicyDiscovery, Negotiation, AgreementAtomicOrchestrationProtocolsStateReliable MessagingTransactionsComponent ModelUDDI, WS-Addr, Metadata Exch.,…WS-BPELWS-CWS-N*SCAWS-RFWS-RMWS-Security*WS-AT WS-BAWS-C: Alle Arten von Koordinaten und Agreement, Auktionen, ...WS-N* = WS-Notification (WS-BaseNotification, WS-Topics, WS-BrokeredNotifcation)SCA = Service Component ArchitectureWS-RF = Resource FrameworkSOAP: W3C, readyWSDL: W3C, readyXML: W3C, readyWS-Security: OASIS, ongoing (IBM, MS, ... Published spec)WS-SecureConversation, WS-Federation, WS-Trust: IBM, MS, ... Published specsWS-Authorization, WS-Privacy: Specification requiredWS-ReliableMessaging: OASIS, ongoing (IBM, MS, ... Published spec) [WS-Reliability: competing spec from Sun and Oracle, but: authors now join OASIS WS-ReliableMessaging TC]WS-TX: WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement: OASIS, ongoing (IBM, MS, ... Published spec) [WS-CAF (Composed Application Fw): competing spec from Oracle, IONA, Arjuna ... but: IONA, Arjuna now co-author WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement]WS-Policy: IBM, MS, ... Published specUDDI: OASIS, readyWS-MetaDataExchange (WS-MEX): IBM, MS, ... Published specWS-Addressing: W3C, ongoing (IBM, MS, ... Published spec)WS-BPEL: OASIS, ongoing (IBM, MS, ... Published spec)WS-DistributedManagement (WS-DM): IBM, CA, HP [competing spec from MS: WS-Management, but unlikely to win because IBM, CA, HP are dominant in Sys Mgmt market]Security in a Web Services World: A Proposed Architecture and RoadmapWSDL*WS-Policy*SOAP, WS-Addr*JMS, RMI/IIOP, ...HTTP, TCP/IP, SMTP, FTP, …76
77 Web Services Standards for SOA The Web Services Platform Architecture MessagingQuality of ServiceTransportDescriptionComponentsInterface + BindingsCompositeXMLNon-XMLSecurityPolicyDiscovery, Negotiation, AgreementAtomicOrchestrationProtocolsStateReliable MessagingTransactionsComponent ModelUDDI, WS-Addr, Metadata Exch.,…WS-BPELWS-CWS-N*SCAWS-RFWS-RMWS-Security*WS-AT WS-BASCA: Open Service Oriented Architecture = “informal alliance of industry leaders”WS-C: Alle Arten von Koordinaten und Agreement, Auktionen, ...WS-N* = WS-Notification (WS-BaseNotification, WS-Topics, WS-BrokeredNotifcation)SCA = Service Component ArchitectureWS-RF = Resource FrameworkSOAP: W3C, readyWSDL: W3C, readyXML: W3C, readyWS-Security: OASIS, ongoing (IBM, MS, ... Published spec)WS-SecureConversation, WS-Federation, WS-Trust: IBM, MS, ... Published specsWS-Authorization, WS-Privacy: Specification requiredWS-ReliableMessaging: OASIS, ongoing (IBM, MS, ... Published spec) [WS-Reliability: competing spec from Sun and Oracle, but: authors now join OASIS WS-ReliableMessaging TC]WS-TX: WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement: OASIS, ongoing (IBM, MS, ... Published spec) [WS-CAF (Composed Application Fw): competing spec from Oracle, IONA, Arjuna ... but: IONA, Arjuna now co-author WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement]WS-Policy: IBM, MS, ... Published specUDDI: OASIS, readyWS-MetaDataExchange (WS-MEX): IBM, MS, ... Published specWS-Addressing: W3C, ongoing (IBM, MS, ... Published spec)WS-BPEL: OASIS, ongoing (IBM, MS, ... Published spec)WS-DistributedManagement (WS-DM): IBM, CA, HP [competing spec from MS: WS-Management, but unlikely to win because IBM, CA, HP are dominant in Sys Mgmt market]Security in a Web Services World: A Proposed Architecture and RoadmapWSDL*WS-Policy*SOAP, WS-Addr*JMS, RMI/IIOP, ...HTTP, TCP/IP, SMTP, FTP, …77
78 SOA and BPMSOA is about constructing software components that can be reused in context unknown at design timeComposition.BPM is about being able to precisely model and possibly change the context in which enterprise components are usedBut how the two meet?
80 Elements of BPM Initiates Activity Event changes State Entity performs ContentActorgeneratesServicesRepresented by
81 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.
83 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 orderUpdate the order entry systemUpdate the billing system…
88 Business Process Execution Language (BPEL) Web Services Business Process Execution Language (WS-BPEL) is a language for describing business processes based on Web ServicesProcesses described using WS-BPEL execute functionality by using Web Service interfaces exclusivelyWS-BPEL Specification is administered by OASISWS-BPEL is an orchestration language, not a choreography languageOrchestration 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 interoperabilityA choreography is not directly executableA choreography can be implemented through an orchestration (i.e. a BPEL process)88
89 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 processAn 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 processAn 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.
90 WS-BPEL Design GoalsBusiness processes defined using an XML-based languageWeb 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.90
92 BPEL key elements 1/2The 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.
93 BPEL key elements 2/2 Sequence A sequence is used to perform a set of activities in a series.FlowA flow is used to perform a set of activities in parallel.LinkA link is used to create a synchronization point between parallel activities.SwitchA switch is used to select a branch based on the evaluation of an expression.WhileA while loop is used to iterate under the control of a boolean expression.InvokeAn invoke is used to call a Web service.WaitA wait is used to delay for a period of time.EmptyAn 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:
94 WS-BPEL Language Constructs WS-BPEL process definitionRecursive composition and partner linksVariablesCorrelation setsBasic and structured activitiesScopesCompensation handlingOverview of WS-BPEL 2.0 language elements94
95 WS-BPEL Process Definition importsDeclare dependencies on external XML Schema or WSDL definitionsextensionsDeclare namespaces of WS-BPEL extension attributes and elementspartnerlinksRelationships that a WS-BPEL process will employ in its behaviormessageexchangesRelationship between inbound and outbound message activitiesvariablesData holding state of a business process or exchanged with partnerscorrelationsetsApplication data fields that together identify a conversationeventhandlersConcurrently process inbound messages or timer alarmsfaulthandlersDeal with exceptional situations in a processElements of a process definitionprimaryactivityPerform the process logic – any number of activities may be recursively nestedXMLschemasWSDLdefinitions95
96 Recursive Composition Model WS-BPEL processes areexposed as Web servicesto business partnersWS-BPEL processes interactwith Web services exposedby business partnersWebServiceWSDLLoan ApprovalPortTypeWebServiceFinancial institution‘sWeb service implementation(Loan Approver)Loan Approval Processinvokereceivereply96
97 Reference to WDSL portType element Partner Links ElementWDSL describes functionality of services provided by a partnerPartner Link describes the shape of the relationship with a partner by describing the Port Types used in a peer to peer relationshipExample:<partnerLinks><partnerLink name=“Invoice”partnerLinkType=“inv:InvoiceType”partnerRole=“InvoiceServiceProvider”/><partnerLink name=“Employee”partnerLinkType=“emp:EmployeeType”partnerRole=“EmployeeServiceProvider”/></partnerLinks>Reference to WDSL portType element97
98 Partner Links process partner link receive Inbound request – service provided by the processinvokeOutbound request – service required by the processpartner link typePeer-to-peer conversational partner relationshipPartner links are channels along which peer-to-peer conversations with partners take placeWSDLport typemyRoleProvided port typeWSDLport typepartnerRoleRequired port type98
99 Message Name from Partner Process Definition Variable ElementVariable construct is used to state information related to workflow logicVariables can contain entire messages and data sets formatted as XML schema typesExample:<variables><variable name=“EmployeeHoursRequest”messageType=“emp:getWeeklyHoursRequestMessage”/></variables>Message Name from Partner Process Definition99
100 Variables xsl:transform 42 42 process WSDL message messages Variables defined using WSDL messagesreceiverequestinvokerequestresponsereplyresponse42xsl:transformVariables are typed using WSDL messages or XML Schema elements or simple/complex typesActivities’ input and output kept in scoped variablesAssignment activities move data aroundassign42XMLschemasXML Schemaelements / typesVariables defined using XML schema elements or types100
101 Properties and Correlation Sets How to identify stateful instances via stateless WS interfaces?A process instance is assigned one or more keysBusiness data is used as key, e.g., customerIDA 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 instancecustomerIDorderNumberProcess 4 (0123,15)Process 3 (0815,42)Process 2 (4711,37)471137Message 1Process 1 (0815,12)081542Message 2101
102 Basic Activities process receive reply invoke Invoke a one-way or request-response operationDo a blocking wait for amatching message to arrive / send a message in replyexitImmediately terminate execution of a business process instancecompensatecompensateScopeInvoke compensation on all completed child scopes in default orderInvoke compensation on one completed child scopevalidateassignUpdate the values of variables or partner links with new dataValidate XML data stored in variableswaitWait for a given time period or until a certain time has passedthrowrethrowGenerate a fault from inside the business processForward a fault from inside a fault handleremptyNo-op instruction for a business processextensionActivityWrapper for language extensions102
103 Structured Activities processflowContained activities are executed in parallel, partially ordered through control linkspickBlock and wait for a suitable message to arrive (or time out)BCAM1M2…AsequenceContained activities are performed sequentially in lexical orderforEachContained activity is performed sequentially or in parallel, controlled by a specified counter variable2.N.1.…2.N.1.…whileContained activity is repeated while a predicate holdsrepeatUntilContained activity is repeated until a predicate holdsif-elseif-elseSelect exactly one branch of activity from a set of choicesc1c2c…scopeAssociate contained activity with its own local variables, partner links, etc.,and handlersc103
105 BPEL Syntax Example Variable Definition <variables><!-- input for BPEL process --><variable name="InsuranceRequest"messageType="ins:InsuranceRequestMessage"/><!-- output from insurance A --><variable name="InsuranceAResposne"messageType="ins:InsuranceResponseMessage"/><!-- output from insurance B --><variable name="InsuranceBResposne"<!-- output from BPEL process --><variable name="InsuranceSelectionResponse"</variables>...105
106 BPEL Syntax Example Process Steps <sequence> <!-- Receive the initial request from client --> <receive partnerLink="client" portType="com:InsuranceSelectionPT" operation="SelectInsurance" variable="InsuranceRequest" createInstance="yes" /> <!-- Make concurrent invocations to Insurance A and B --> <flow> <!-- Invoke Insurance A web service --> <invoke partnerLink="insuranceA" portType="ins:ComputeInsurancePremiumPT" operation="ComputeInsurancePremium" inputVariable="InsuranceRequest" outputVariable="InsuranceAResposne" /> <!-- Invoke Insurance B web service --> <invoke partnerLink="insuranceB" outputVariable="InsuranceBResposne" /> </flow> …106
107 BPEL Syntax Example Process Steps (Cont’) <!-- Select the best offer and construct the response --><switch><case condition="bpws:getVariableData('InsuranceAResposn e','confirmationData','/confirmationData/Amount')<= bpws:getVariableData('InsuranceBResposne','confirmationData','/confirmationData/Amount')"><!-- Select Insurance A --><assign><copy><from variable="InsuranceAResposne" /><to variable="InsuranceSelectionResponse" /></copy></assign></case><otherwise><!-- Select Insurance B --><assign><copy><from variable="InsuranceBResposne" /><to variable="InsuranceSelectionResponse" /></copy></assign></otherwise></switch><!-- Send a response to the client --><reply partnerLink="client"portType="com:InsuranceSelectionPT"operation="SelectInsurance"variable="InsuranceSelectionResponse"/></sequence></process>107
108 DoDAF An Integrated Architecture with Three Views Information FlowOperationalElementsActivities/TasksIdentifies What Needs To Be Done And Who Does ItViewSystemsData FlowCommunicationsXYZRelates Systems and Characteristics to Operational NeedsViewPrescribes Standards andConventionsStandardsRulesTechnicalStandards View
109 DODAF ProductsThe DODAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architectureThe 26 DODAF views are designed to document the entire architecture, from requirements to implementation
110 DODAF Products - ViewsThe list of products is refined into four views:All Views (AV): is the overarching information describing the architecture plans, scope, and definitionsOperational View (OV): focuses on the behaviours and functions describing the enterprise mission aspectsSystem View (SV): describes the system and applications supporting the mission functionsTechnical Standards View (TV): describes the policies, standards and constraints
115 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 InformationAV-2: Integrated DictionaryOV-2: Operational Node Connectivity DescriptionOV-3: Operational Information Exchange MatrixOV-5: Operational Activity ModelSV-1: System Interface DescriptionTV-1: Technical Standards Profile
118 OV-3 – Operational Information Exchange Matrix Table Headers Specified in Framework:Name of Operational Needline Supported (from OV-2)Name of Information ExchangeNature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?)Purpose or Triggering EventInformation 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)
122 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_tableLa première réponse historique à la rationalisation du SI est la démarche dite l’urbanisation .L’urbanisation des SI travaille sur :Processus métiersCommunications inter applicativeSur la mise en place d’un référentiel transversesResulat : Le système d’information d’une entreprise est représenté selon quatre niveaux d’architecture:L’architecture métier : processus métier de l’entrepriseL’architecture fonctionnelle : blocs fonctionnels et flux d’information supports à la réalisation des processus métier, indépendamment des technologies mises en œuvre,L’architecture applicative : blocs applicatifs et échanges, supports à la réalisation des blocs fonctionnels et des flux.L’architecture technique : infrastructure sur laquelle sont implémentées et exécutés les blocs fonctionnels .Objectif est d’avoir une vue d’ensemble du SI122122
124 Objectives for this session History & theory of Knowledge Management (KM)KM modelsOntology and its design methodology
125 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.
126 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)
127 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. O’Dell C. & Grayson Jr., C.J. (1998). If only we knew what we know.
128 Two types of knowledge Explicit knowledge Implicit (Tacit) knowledge Know-how & learning embedded within the minds people.Documented information that can facilitate action.Explicit knowledgeFormal or codifiedDocuments: reports, policy manuals, white papers, standard proceduresDatabasesBooks, magazines, journals (library)Implicit (Tacit) knowledgeInformal and uncodifiedValues, perspectives & cultureKnowledge in headsMemories of staff, suppliers and vendorsKnowledge 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.
129 Layers of knowledge Explicit Implicit (Tacit) Individual Personal documentson my C:\Formalized process for developing curriculum.Corporate polices andprocedures.In people’s heads.Undocumented ways of working in teams, teaching.Cultural conventionsknown and followedbut not formalized.OrganizationalSource: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto.
130 One Perspective of KM“KM [Knowledge Management] involves blending a company’s 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.
131 Understanding KMUnderstanding Knowledge Management requires an understanding of knowledge and the knowing process and how that differs from information and information management.
132 Classic Data to Knowledge Hierarchy WisdomKnowledgeInformationData
134 Data, Information & Knowledge Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto."We are drowning in information but starved for knowledge" Naisbitt , J. (1984) Megatrends: Ten new directions transforming our lives.
135 Knowledge Management Models DocumentTechnologyLearning & Communication
136 History of KnowledgeKnowledge 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.
137 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 world’s knowledge. KM is seen as in the form of structural linguistics and semiotics.”.
138 CautionIt would be a mistake, though, to define Knowledge Management as solely the domain of documents.
139 Contentnets and KMAs knowledge repositories for tacit knowledge that has been made explicitFor best practices databasesFor expert “yellow pages”Online learning and knowledge sharingKnowledge sharing “boards”
140 Peoplenets & Processnets Group learning applicationsSocial 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.
141 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.
142 KM advantagesFlexibility and the ability to act quickly is necessary in a changing environmentNew projects can benefit from alliances and learning from in-house experts and creative thinkers.Innovation as a way of life
143 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 system’s 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.
144 How to represent the knowledge Links and structuresNotationOntology.
145 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.
146 Ontology as a system of concepts Used as conceptual building blocks of knowledge-intensive systemsSomething deeper than metadataIt provides foundation on which a KB or an application system is builtOntologyKnowledgeBase(Model)An explicit specification ofa hidden conceptualizationof the target domain
147 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.
148 From Knowledge Eng. To Ontological Eng. KE is the research on:Domain-specific heuristics for a stand-alone problem solverOE is the research on:General/reusable/sharable/long-lasting concepts for building a KB/model for helping people solve problems.
149 Dichotomy of ontology Light-weight Ontology Heavy-weight Ontology One like Yahoo ontologyVocabulary rather than conceptsAnnotation-oriented ontologyUsed for Information representation and searchHeavy-weight OntologyConcepts rather than vocabularyfor unified understanding the target systemfor building ontology-aware systemKeep knowledge separated from system changes.
150 The fundamental role of an ontology An ontology is not directly used for problem solvingIt gives a specification of knowledge and information models in a systemThe role of an ontology to a knowledge base is to give definitions of concepts used in the knowledge representation and constraints among conceptsto make the knowledge base consistent and transparent which are the necessary properties of sharable and reusable knowledgeKnowledge Amplifier systems.
152 Why Ontologies? (review) To share common understanding of the structure of information among people or software agentsTo enable reuse of domain knowledgeTo make domain assumptions explicitTo separate domain knowledge from the operational knowledgeTo analyze domain knowledge
153 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.
155 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.
156 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.
157 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?
158 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.
159 Step 1 ExampleCompetency questionWhich 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?
160 Step 2. Consider reusing existing ontologies Sure, if they exist!!!
161 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 wine’s 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.
162 Step 4. Define the classes and the class hierarchy MethodsTop-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.
163 Step 4. Define the classes and the class hierarchy MethodsBottom-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 classes—Medoc—which in turn is a subclass of Bordeaux.
164 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.
166 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.
167 Step 4. Define the classes and the class hierarchy Top-downFood and Wine -- followed by White, Blush and RedBottom-updefine specific wine class first and the work your way upCombination
168 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 wine’s 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.)
169 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.Examplesa wine’scolor,body,flavorsugar contentlocation of a winery.
170 Completing slotsIn addition to the properties we have identified earlier, we need to add the following slots to the Wine class: name, area, maker, grape.
171 InheritanceAll 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.
172 Step 6. Define the facets of the slots Slot cardinalitydefines how many values a slot can have.Sometimes it may be useful to set the maximum cardinality to 0.Slot-value typewhat types of values can fill in the slot.allowed valuesother features of the values the slot can take.
173 Step 6. Define the facets of the slots common value types:StringNumberBooleanEnumeratedInstance-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.
175 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.
176 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.
177 Step 7 - Creating Instances Body: LightColor: RedFlavor: DelicateTannin level: LowGrape: 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
180 Step 8 - Defining classes and a class hierarchy Ensuring that the class hierarchy is correctAn “is-a” relationA 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 winesTransitivity of the hierarchical relations
181 Step 8 - Defining classes and a class hierarchy Evolution of a class hierarchydistinction between classes and their nameshence synonyms of concept name do not represent different classesAvoid class hierarchy cyclesAll the siblings in the hierarchy (except for the ones at the root) must be at the same level of generality.
182 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)
183 Step 8 - Defining classes and a class hierarchy Multiple InheritanceWhen do you introduce a new classSubclasses 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
184 Step 8 - Defining classes and a class hierarchy Counter example to thumb rule in previous slideClasses in terminological hierarchies do not have to introduce new propertiesMeSH at NLM National Institute of Healthpurpose is just to organize for ease of searching/indexing
185 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 WhiteDepends on how important a concept White Wine is in the domainAn 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.
186 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.
188 Next Choose domain IN WHICH YOU ARE EXPERT. Requirements Identify intended useShow all steps mentioned so far…
189 References The elements of this presentatiion are obtained from: Cartic Ramakrishnan, LSDIS Lab, University of Georgia.ASIS KM WebsiteBrint.com Knowledge PortalKnowledge Management Research CenterKarl-Erik Sveiby and Knowledge AssociatesUniversity of ArizonaRiichiro MizoguchiSIR, Osaka UniversityCanadian Institutional Research and Planning AssociationCartic Ramakrishnan, LSDIS Lab, University of GeorgiaOntology Working Group
191 DefinitionsIs 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.
192 DefinitionsThe 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.
193 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.
194 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.
196 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.
197 Patterns categoriesIn 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.
198 Abstract factoryProvides 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.
199 Abstract factorySheet 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.
200 Factory MethodsThe factory method design pattern centralize creation of an object of a specific type choosing one of several implementations .
201 Builder patternThe intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.
202 Prototype patternThe Prototype pattern specifies the kind of objects to instantiate using a prototypical instance.
203 Singleton patternThe 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).
204 Structural patternsStructural 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.
205 Composite patternThe Composite composes objects into tree structures, and lets clients treat individual objects and compositions uniformly.
206 Composite patternThe 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).
207 Decorator patternThe 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.
208 Facade patternThe 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.
209 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.
210 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:
211 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.
212 Command patternThe 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.
213 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.
214 Iterator patternsThe 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.
215 Mediator patternThe 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 needonly be dealt with in the tower.Interactions are decoupled. The many to many interactions arereplaced with a one to many interaction..Control is centralized. Complexity of interaction is traded for complexity in the mediator.
216 Memento patternThe 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).
217 Observer patternThe 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.
218 State patternThe State pattern allows an object to change its behavior when its internal state changes.Coffee machine!
219 StrategyA 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.
220 Template MethodThe 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.
221 Visitor patternThe 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).
222 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.