Information System Architecture Information system The data is the raw material of any I.S. Before...

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 1471-2000

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.

• 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.

• 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]

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…

OrganizationsLocationsFunctions

ApplicationsEntities

Database/fileTechnology Platforms

Graphic Text Dictionary Relationships

CommunicateCapture Analyze

Use products to:

Tabular

SystemsNode Name

SystemName

System Function

SystemComponent

OperationalNode Name

OperationalActivity

LinkName/ID

Needline Name

ComponentInterface

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.

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 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.

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.

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).

Non-Urbanized City

Urbanized city

Non-Urbanized IS

Urbanized IS

Multilayer approach

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!

Middleware capabilities

•Security.•Transformation (Data).•Mediation (functional and semantic).•Routing.•Monitoring.•Tracing.•End to end QoS.•Searching and matching.• Invocation.

Middleware

Middleware!

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.

ServicesServicesServicesServices

Services

directory

(UDDI)

Seache a

service

Invocation

2 - HTTP Get

3 – WSDL(encapsulaed in a SOAP)

service

Publicatio

Client

Service Provider

4 - request “Soap”

5 - response “Soap”

Composite service 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:http://www.tutorialspoint.com/uddi/index.htm

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:

<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) 123-1234</phone> <email>jdoe@acme.com</email> </contact> </contacts> <businessServices> ... </businessServices> </businessEntity>

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:

<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.

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:

<description>Hello World SOAP Binding</description> <accessPoint URLType="http"> http://localhost:8080

</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.

•Web Services Description Language.

•Written in XML.•Used to describe and to locate Web services.

For more information see:http://www.tutorialspoint.com/wsdl/index.htm

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.

WSDL PortType• The <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.

WSDL Messages

• The <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.

WSDL Types

• The <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.

Example<message

name="getVoyageRequest"> <part name="Destination"

type="xs:string"/> <part name="Date" type="xs:string"/></message> ----<message

name="getVoyageResponse"> <part name=" Price" type="xs:string"/> </message>------<portType name="VoyageDirectory"><operation name="getVoyage"><input

message="getVoyageRequest"/><output

message="getVoyageResponse"/></operation></portType>

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.

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 OperationAn 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.

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".

SOAP1. 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:http://www.tutorialspoint.com/soap/index.htm

Used for both Messaging and RPC Simple structure

EnvelopeHeader (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: http://www.w3.org/2001/12/soap-envelope

• 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: 189.123.345.239 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

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header>

<user:credentials soap:mustUnderstand="1"> >

<username>Layth</username>

<password>Okinawa</password>

</user:credentials>

……………..

</soap:Envelope>

Messaging

Quality of Service

Transport

Description

Components

Transport

Interface + Bindings

Composite

XML Non-XML

Security

Policy

Atomic

OrchestrationOrchestration ProtocolsProtocols StateState

ReliableMessaging Transactions

ComponentModelComponentModel

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

Composite

XML Non-XML

Security

Policy

Atomic

WSDL* WS-Policy*

HTTP, TCP/IP, SMTP, FTP, …

ddr, M

WS-CWS-N* WS-RFWS-BPEL

WS-Security*WS-AT WS-BA

SOAP, WS-Addr* JMS, RMI/IIOP, ...

Other SOA standards

Messaging

Quality of Service

Transport

Description

Components

Transport

Composite

XML Non-XML

Security

Policy

Atomic

WSDL* WS-Policy*

HTTP, TCP/IP, SMTP, FTP, …

ddr, M

WS-CWS-N* WS-RFWS-BPEL

WS-Security*WS-AT WS-BA

SOAP, WS-Addr* JMS, RMI/IIOP, ...

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?

Services Composition

Entity

Elements of BPM

Activity

Contentperforms

Initiates

changes

generatesServices

Represented by

• “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.

ManufacturingCapacity Analysis

Manufacturing Execution (MES)

Manufacturing/Production

Planning

Sync DispatchList

Get DispatchList

Show DispatchList

Sync ItemMaster

Sync ProductionOrder

Sync Routing

Sync BillOfMaterial

Sync ItemMaster

Sync ProductionOrder

Sync Routing

Sync BillOfMaterial

c Item

Invento

ryIssue

Invento

ryIssue

OAGIS 8.1 Scenario 50

A business process does not have a “center”…it is de facto “peer-to-peer”

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• …

Orchestration languages

• They allow us to implement complex services which involve:

• Long running (from a few hours to a few months), • And event driven business logic

• They are not about modeling Business Processes by themselves

• Different orchestration (i.e. different services) can run within the same business process

• And vice versa

A Business Process can be Viewed as a Multi-Party Choreography of Peer Services. A Choreography Provides a Model of the Event Flow Between Activities.

User ActivityUser

Activity

Buyer Supplier SFA Salesperson

MappingRouting Quot

eRFQ RFQ RFQ

Order Order

Invoice

Accounts

Account

SalesTax.comSalesTax.com CreditCheck.comCreditCheck.com

Orders

Billing

Invoice

SalesOrder

Events

Activity

Services in a SOA are orchestrated (BPEL) !

Quote ServiceOrchestration Definition

SalesTax

<<send>>quoteupdateDB

Transition

Message flow

QuoteOk?

NosendNack

<<invoke>>calculateSalesTax

<<invoke>>GetQuote

EntityState

Entity

<<receive>>RFQ

Orchestration vs. Choreography

Orchestration « … is a concept that gives programmers a way to formally

describe processes underlying business applications so that they can be exposed and linked to processes in other applications »

Choreography Is a concept that specifies how these processes are linked

together across the enterprise or between enterprises. They are both a form of Coordination

• 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/2The language includes the following key elements:

Partner link typeA 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.VariableA variable is used to store a local copy of a message or data in a process instance.

Correlation setA 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.

ReceiveA receive is used to wait for a request message sent to a Web service implemented by the process. ReplyA reply is used to send a response message to the sender of the request message that initiated the

process instance.PickA 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/2SequenceA 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:

• 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

partnerlinks

Relationships that a WS-BPEL process will employ in its behavior

correlationsets

Application data fields that together identify

a conversation

messageexchanges

Relationship between inbound and outbound

message activities

eventhandlers

Concurrently process inbound messages or timer alarms

faulthandlers

Deal with exceptional situations in a process

primaryactivity

Perform the process logic – any number of activities may be recursively nested

XMLschemas

WSDLdefinitions

WebService

Financial institution‘sWeb service implementation(Loan Approver)

WebService

WSDLLoan ApprovalPortType

Loan Approval Process

invoke

receive

WS-BPEL processes are exposed as Web servicesto business partners

WS-BPEL processes interact with Web services exposedby 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:<partnerLinks>

</partnerLinks>

Reference to WDSL portType element

process

partnerlink

partner link type

Peer-to-peer conversational partner relationship

WSDLport type

myRole

Provided port type

WSDLport type

partnerRole

Required port type

receiveInbound request – service provided by the process

invokeOutbound 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:<variables>

<variable name=“EmployeeHoursRequest”

messageType=“emp:getWeeklyHoursRequestMessage”/>

</variables>

Message Name from

Partner Process

Definition

process

assign

xsl:transform

receive

request

response

invoke

request

response

WSDLmessage

WSDLmessages

Variables defined using WSDL messages

42XMLschemas

XML Schemaelements / 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)

0815 42

Message 2

customerID

orderNumber

4711 37

Message 1

process

receive reply

invokeInvoke a one-way or request-response operation

Do a blocking wait for a matching message to arrive / send a message in reply

validate

assignUpdate the values of variables or partner links with new data

Validate XML data stored in variables

rethrow

Generate a fault from inside the business process

Forward a fault from inside a fault handler

exitImmediately 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

waitWait for a given time

period or until a certain time has passed

empty No-op instruction fora business process

extensionActivityWrapper for language

extensions

process

flowContained activities are executed in parallel, partially ordered through control links

sequenceContained activities are performed sequentially in lexical order

whileContained activity is repeated while a predicate holds

repeatUntilContained 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. …

c1 c2…

2. N.1. …

… AM2M1

<?xml version="1.0" encoding="utf-8"?>

<process name="insuranceSelectionProcess"

targetNamespace="http://packtpub.com/bpel/example/"

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:ins="http://packtpub.com/bpel/insurance/"

xmlns:com="http://packtpub.com/bpel/company/" >

<partnerLink name="client"

partnerLinkType="com:selectionLT"

myRole="insuranceSelectionService"/>

<partnerLink name="insuranceA"

partnerLinkType="ins:insuranceLT"

myRole="insuranceRequester"

partnerRole="insuranceService"/>

<partnerLink name="insuranceB"

partnerLinkType="ins:insuranceLT"

myRole="insuranceRequester"

partnerRole="insuranceService"/>

</partnerLinks>

<variables>  <variable name="InsuranceRequest" messageType="ins:InsuranceRequestMessage"/>  <variable name="InsuranceAResposne" messageType="ins:InsuranceResponseMessage"/>  <variable name="InsuranceBResposne" messageType="ins:InsuranceResponseMessage"/>  <variable name="InsuranceSelectionResponse" messageType="ins:InsuranceResponseMessage"/> </variables>...

<receive partnerLink="client"

portType="com:InsuranceSelectionPT"

operation="SelectInsurance"

variable="InsuranceRequest"

createInstance="yes" />

<flow>

<invoke partnerLink="insuranceA"

portType="ins:ComputeInsurancePremiumPT"

operation="ComputeInsurancePremium"

inputVariable="InsuranceRequest"

outputVariable="InsuranceAResposne" />

<invoke partnerLink="insuranceB"

portType="ins:ComputeInsurancePremiumPT"

operation="ComputeInsurancePremium"

inputVariable="InsuranceRequest"

outputVariable="InsuranceBResposne" />

</flow>

<switch> <case

condition="bpws:getVariableData('InsuranceAResposne',

'confirmationData','/confirmationData/Amount')

<= bpws:getVariableData('InsuranceBResposne',

'confirmationData','/confirmationData/Amount')">  <assign> <copy> <from variable="InsuranceAResposne" /> <to variable="InsuranceSelectionResponse" /> </copy> </assign> </case> <otherwise>

<reply partnerLink="client" portType="com:InsuranceSelectionPT" operation="SelectInsurance" variable="InsuranceSelectionResponse"/> </sequence></process>

Prescribes Standards andConventions

Standards Rules

Conventions

TechnicalStandards View

DoDAF An Integrated Architecture with Three Views

Information Flow

OperationalElements

Activities/Tasks

Identifies What Needs To Be Done And Who Does It

Operational View

Systems Data Flow

Communications

Relates Systems and Characteristics to Operational Needs

SystemsView

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

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

AV-1 & AV-2

OV-2 – Operational Node Connectivity Description

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, 2004.

• http://www.tutorialspoint.com/

• http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#SA00005_table

An Introduction to Knowledge Management

2010-2011

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.

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. O’Dell 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 people’s heads.

• Undocumented ways of working in teams, teaching.• Cultural conventionsknown 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 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.

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

From Facts to Wisdom

Data, Information & Knowledge

DATA INFORMATION KNOWLEDGE

Definition Raw facts, figures and records

contained in a system.

Data placed into a form that is

accessible, timely and accurate.

Information in context to make it insightful and

relevant for human action.

Reason Processing Storing / Accessing.

Insight, innovation,

improvement.

"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 world’s 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 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.

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

KnowledgeBase

(Model)An explicit specification of a hidden conceptualization of the target domain

• 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 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.

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

hierarchyMethodsBottom-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.

Step 4. Define the classes and the class

hierarchyMethods-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.

• 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.

• 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 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.)

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 wine’s • 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

• 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.

• 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)

• 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

• 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

• 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.

Details

• Inverse slots• Naming conventions• Synonyms• Defaults• Disjoint subclasses

• 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

http://www.asis.org/SIG/sigkm/index.html

• Brint.com Knowledge Portal

http://www.brint.com/ym.html

• Knowledge Management Research Center

http://www.cio.com/research/knowledge/

• Karl-Erik Sveiby and Knowledge Associates

http://www.sveiby.com.au/

• University of Arizona

http://www.cmi.arizona.edu/research/kno_mgmt/

• Riichiro MizoguchiSIR, Osaka Universityhttp://www.ei.sanken.osaka-u.ac.jp

• Canadian Institutional Research and Planning Association

• Cartic Ramakrishnan, LSDIS Lab, University of Georgia

• Ontology Working Group

Pattern oriented software architecture

2010-2011

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.

Account Lockout

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.