reference modeling and lifecycle management for e-government services
Post on 30-Dec-2015
17 Views
Preview:
DESCRIPTION
TRANSCRIPT
Reference Modeling and Lifecycle Management for e-Government Services
Knut Hinkelmann, Barbara Thönssen, Fabian Probst
Knowledge and Business EngineeringKnowledge and Business Engineering
Prof. Dr. Knut Hinkelmann 2
The Goal
bridging the gap between decision making and technical realisation of e-Gov services Supporting all back-office phases (design, configure,
deploy, run)
considering the lifecycle of e-Gov services Simplified implementation of uniform process Supporting the management of changes in e-Gov services
(preserve consistency, detect inconsistencies, propagate changes, implement changes)
making knowledge explicit capturing knowledge about e-Gov services tracing design decisions leading to e-Gov service models
Improve the (back-office) management of e-Gov services
Prof. Dr. Knut Hinkelmann 3
X
Programmers write code
Start Process 1 Process 2 Process 3 EndStart Process 1 Process 2 Process 3 End
Managers decide how to implementthe law
Politicians define the law
Citizens deal with eGov services
law is revised
activities have to be changed
software is to be modified
eGov-services are updated
The Problem
X
Prof. Dr. Knut Hinkelmann 4
E-Government Today – One Solution per Municipality
Prof. Dr. Knut Hinkelmann 5
Example: ‘Announcement of Move’
DeregistrationRegistration
Deregistration Registration
Municipality A(Olten)
Municipality B(Allschwil)
Citizen
E-Government Today
Citizen
Prof. Dr. Knut Hinkelmann 6
Situation
All municipalities provide nearly identical services, but … Implementation takes place individually and is
continuously repeated
Changes (e.g. in law) must be put into action for each implementation
…
Prof. Dr. Knut Hinkelmann 7
Web services interfaces to existing legacy systems
Ontology ManagementModeling EnvironmentLifecycle Management
Business Modeling Component
Configuration Component
Run-time Component
I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2
I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2
I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2
I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2
I1I2
O1O2O3
WS2I1I2
O1O2O3
WS2
OntoGov Framework: Service Modelling
• Create service ontologies• Modifiy ontologies• Store ontologies• Query ontologies• Trigger changes
Prof. Dr. Knut Hinkelmann 8
Levels of Reference Models
R1PM_IA
R2PM_IAa R2PM_IAb
Abstraction / Specialisation
General(e.g. state)
Specific(municipality)
R3PM_IAa
Abstraction / Specialisation Abstraction / Specialisation
R3PM_IAbR3PM_IAaR3PM_IAb
Prof. Dr. Knut Hinkelmann 9
Ontological Process Modelling in OntoGov
Commit
CheckApplication
R1PM_FAFM (File an Application for Move)
eGov Form:ApplicationForMove
[ContentNOK]
[noExtension]
Key:
eGov-WS
eGov Form:Upload Documents
CheckApplicationExtension
eGov Form:ExtensionApplicationForMove PA-2-deregister
[ContentOK;]
Fill in Applicationfor Move
eGov Form:ExtensionApplicationFor
Move PA-2-register <<pre-condition>>{additional infomationis needed}
<<pre-condition>>{additional infomationis needed}
<<pre-condition>>{already filled in information isprovided }
<<pre-condition>>{already filled in information isprovided }
Notification
[Extension]
CheckApplication_AFM
eGov Form:ApplicationForMove
ProvideInformation Of
Application
Application Data /Process-ID
Sub Process
<<note>>{PAs responsible for(de)registration}
<<note>>{PAs responsible for(de)registration}
ProvideInformation Of
Application
<<note>>{citizens‘ notification}<<note>>{citizens‘ notification}
Standard UML model
Semantic Model Interface Ontological Representation
Prof. Dr. Knut Hinkelmann 10
Service Ontology: Concepts and Instances
Prof. Dr. Knut Hinkelmann 11
• What changed?• By whom was it
changed?• When did it change?• What was the reason
for?
Tracking Changes
Prof. Dr. Knut Hinkelmann 12
Idea: Explicit Documentation of Process Model Adaptations
LegalReasonhasReferenceisReasonFor
FillInApplicationForMove
CheckApplication
Extension?
R1PM_FAFM (Service Ontology)
FillInApplicationForMoveOLTEN
CheckApplication
Extension?
R2PM_FAFM (Service Ontology)
DesignDecisionReplaceService
Lifecycle OntologyLegalOntology
Prof. Dr. Knut Hinkelmann 13
Dependencies between reference process models
Reference
ReferenceProcessModel
Add Service (B)
Replace Service ( with A)
Delete Service ()
DesignDecisions
A
Derivation
states the relations betweenreference process models
B
ReferenceProcessModel‘
Prof. Dr. Knut Hinkelmann 14
Specialization of process model for municipality
(1)
(2)
(3)
Fill in Applicationfor Move
CheckApplication
Extension?
R1PM_FAFM (Application for Move)
Check ApplicationExtension
Content OK?
Commit
Provide Informationof Application
Provide Informationof Application
Inform Applicant
Fill in Applicationfor Move for Olten
CheckApplication
R1PM_FAFM (Application for Move Olten)
Upload Docs
Content OK?
Commit
Provide Informationof Application
Provide Informationof Application
Inform Applicant(1) Replace by municipality-
specific activity(2) Delete an activity(3) Insert additional acitivity
Prof. Dr. Knut Hinkelmann 15
Lifecycle Management of (Reference) Models
R1PM_V1
R2PM_V2a
Specialisation‘
automatically derived copy of R2PM_V1a as draftDesign decision give hints for adaptation
R2PM_V1a
Specialisation
Documentingchangesas designdecision
R1PM_V2
New version
(manually copied)
Documenting changes as design decision
Prof. Dr. Knut Hinkelmann 16
DD1
DD2
DD3
Design Decisions (DD):
• every service must have at least one Design Decision
• every Design Decision must have at least one Reason
• every Reason must have at least one reference
• a Design Decision may become a reason for another Design Decision
Design Decisions: Making Process Knowledge explicit
Prof. Dr. Knut Hinkelmann 17
Decision
Reason
Design Decision
Excerpt: Lifecycle Meta Ontology
Prof. Dr. Knut Hinkelmann 18
Decision Reason Chains
Decision
DecisionDecision
Decision
Decision
Decision Decision
Reason
isReasonFor
isReasonFor
isReasonForisReasonFor
isReasonFor
isReasonFor
isReasonFor
isReasonFor
isReasonFor
Any entity in a- legal Ontology- domain Ontology- organisational Ontology
Reason
Reason
Reason
isAffectedBy
isAffectedBy
isReasonFor
Decision reason chains are represented in the lifecycle ontology
Decision
Reason
Design Decision
Prof. Dr. Knut Hinkelmann 19
R_I
DD_1
R_II
DD_2
R_III
DD_3
R_IV
DD_4
R_V
Legal Ontology
Organ.Ontology
Documentation of Lifecycle Aspects
LifecycleOntology
Prof. Dr. Knut Hinkelmann 20
• What services are affected?• What activities are affectet?X
Example: Change of a Law
Prof. Dr. Knut Hinkelmann 21
R_I
_toBeChecked
R_II
DD_2
R_III
DD_3
R_IV
DD_4
R_V
Legal Ontology
Organ.Ontology
Lifecycle Management: Service Consistency
LifecycleOntology
_toBeChecked
DD_1 _toBeChecked
_toBeChecked
_toBeChecked
Prof. Dr. Knut Hinkelmann 22
R_I
_toBeChecked
R_II
DD_2
R_III
DD_3
R_IV
DD_4
R_V
Legal Ontology
Organ.Ontology
Lifecycle Management: Service Consistency
_toBeChecked
DD_1 _toBeChecked
_toBeChecked
_toBeChecked
LifecycleOntology
Prof. Dr. Knut Hinkelmann 24
Summary: Reference Model Specialisation
R2PM_IAa
R2PM_IAb
Deregistration
Registration
R3PM_IAa
RegistrationDeregistration
Municipality A(Olten)
R3PM_IAb
R3PM_IAb
Deregistration
Registration
Municipality B(Allschwil)
R3PM_IAa
Prof. Dr. Knut Hinkelmann 25
DeregistrationRegistration
Announcement
Deregistration Registration
Municipality A(Olten)
Municipality B(Allschwil)
Citizen
Outlook: One-stop E-Government
R3PM_IAaR3PM_IAb
R3PM_IAb
R3PM_IAa
R2PM_IAa
R2PM_IAb
User interacts with general reference modelAutomatic delegation to specific implementation
top related