Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Why HERM Modelling?Co-Design of Structure, Functionality,
Distribution, and Interaction
23rd Jyvaskyla Summer School http://www.jyu.fi/summerschool/
Jyvaskylan yliopisto
University of Jyvaskyla
19.8.2013
Bernhard ThalheimTechnologie der Informationssysteme
Institut fur Informatik, Christian-Albrechts-Universitat zu Kiel, BRDKolmogorow-Professor e.h. der Lomonossow-Universitat Moskau
1
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Overview
• Co-Design - why ?
• Structuring (the classical and the non-classical case)
• Functionality [behavior] (the hidden programmer’s cave)
• Advanced views and media types (the long waited link)
• Interactivity (playout of scenarios, actors and interfacing)
• Making co-design working (handling complexity well-educated)
• References, conferences, open problems
Maximal exploitation of database theory and technology
for intelligent information systems design support
2
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Modeling is outSAP Chief Manager 1999: Modeling is out !but: > 20,000 + > 42,000 + > 87,000 + > 3,500,000
but relational schema redundancy in the SAP data schema: >
4.5
but large runtime and performance problems
but huge integration problems
but hyper-huge development problems: instead of integration
development once more
but until 1999: no documentation on R/3
but: heavy maintenance, installation and extension problems
hyper-redundancy in SAP R/3, e.g., more than 75 address relations
simple update (“change the zip for one street”) may take 2-3 days or
weeks
SAP database system is initialized within a two weeks time frame and
not less
3
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Stone-age Computer EngineeringNo Engineering Yet
handicraft programming
except computer game industry
everybody programs from scratch
Are there other approaches?
why pupils are programming websites?
Solution A: Script languages
Modeling of small programs
Meta-modeling
No Engineering Science Yet
4
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are Task-Oriented
• task: specification of goal-oriented actions;
subtasks: workflow with activities, restricted by conditions, data and
context (organization, policy, environment, channel, ...)
• participatory design (task analysis, user-oriented)
mapped to essential design (data and function analysis)
three spaces: task world, system space, interaction space
• website as services (scenario of activities which can be called by the
user with supporting protocols and delegation facilities)
request, indication, response, confirmation
(a)synchronous, layering, resource-sharing, error-robustness, com-
munication support, (temporary) workspace
• generic user model and profile
5
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Example: Ophthalmology
Application: develop a sy-
stem that supports simi-
larity matching between
patient’s eye image and
images available in a re-
pository
Main Issue: representation
of an ophthalmologist’s
way of information pro-
cessing during matching
images to identify the
disease
Research issue:
integration of com-
putational, cognitive, and
sociotechnical aspects
6
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Example: Intensive BreathCare by Evita 4
IPPV (Intermittent Positive Pressure Ventilation);
SIMV (Synchronized Intermittent
Mandatory Ventilation);
MMV (Mandatory Minute Volume Ventilation);
SB (Spontaneous Breathing);
CPAP (Continuous Positive Airway Pressure);
ASB (Assisted Spontaneous Breathing);
BIPAP (Biphasic Positive Airway Pressure);
BIPAPAssist (Biphasic Positive Airway Pressure Assisted);
APRV (Airway Pressure Release Ventilation);
PPS – Proportional Pressure Support;
ILV (Independent Lung Ventilation);
Automatic Tube Compensation ATC;
Apnoea Ventilation;
NIV mask ventilation; ... ... ...
7
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Cross-Disciplinary Approach toDevelopment
(1) Task- and usage-driven development of supporting means for real-
life applications
computer engineers neglect user requirements
(2) Systems must follow rules, culture, understanding of users, e.g.,
privacy, security, dependability
computer engineers are not educated to take this into account
(3) Systems become far more complex, handle huge data, must be
integrated, used with skills
holistic understanding of applications with flexible integration
(4) Strengthes, weaknesses, opportunities, and threat of systems must
be understood by users before used with full benefit
users must not be adapted to the systems but should continueto live
(5) Systems are going to be used by many different people with many
different background
cultures matter, cross-disciplinary, cross-cultural
8
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Handling Large Schemata ThroughLayered Architectures
�� ��Layered Solution
9
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Why Do We Need Co-Design
Support of work is the killer requirement
Ease of work is the bargain requirement
Efficiency of work trigger company’s choices
High utility is the shopping argument
Data are not the kernel
Functions, procedures, triggers should support work
Users need to interact in changing exchanges
Users are different (configuration, exception, adaptation support)
Context of work is changing (high flexibility, adaptation to environ-
ment)
Large variety of very different users due to computers omnipresence
10
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Knowledge Gap on Database DesignDecisions
Modality
“Partial reality”
Exactness Confidence
6
?
Usage oftheory
Foundation ofdecisions
Modeler
6
?
actswithin
Context
6
Modelingdecision
� URevisionduring the
development process
6 6
Things ofreality Predicator
Partof reality
“Topic”�
6
-Observedproperty
�
?
underusage
Referencemodel
“Schema” as resultand partial point of view
of a databasedevelopment process
11
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Problems of IS Systems ModellingTechniques
(1) Limited scope: mainly specification of data structuring;
(2) Poor separation of concerns: (a) intended properties, (b) assump-
tions about the environment, (c) properties of the application do-
main;
(3) Low-level schematology: structured and formalised by modelling in
the small ;
(4) Isolation: context, companion products, people;
(5) Poor guidance: constructive methods for building correct models;
(6) Cost of holistic development: white-box use of tools;
(7) Poor tool feedback: root of problems, proposing better modelling
solutions
12
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Requirements to Co-Design
• Oneness
• Full fledged theory underneath
• Consistency, interpretability
• Scoping to various aspects
• Reasoning facilities
• Translatability
• Extensibility, scalability, integrability, performance
• Team work support, tools
• Methodology
13
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Choices for Development AlternativesObject-expanded or class-separated depending on the modelling language
• Venetian blind (component-oriented, central or kernel types for association of com-
ponents)
• Russian doll (DTD style, XML fully-fledged)
• Salami slice (similar to ER, UML, XML schema) with rigid class separation
Development strategy as 3-dimensional decision chart
6
-
Controlleddevelopment
(U,I)
Development direction (B,J,T)
Modularisation (C,V,M)
IMT
IVT
ICT
UCB
UVT
UCT
UMT
IMJ
IVJ
ICJUCJ
ICB
UVBUVB
IMBUMB
UMJ
UVJ
B: bottom-up
T: top-down
J: jojo
M: modular
V: view-based
C: central
U: uncontrolled
I: inside-out
Dividing ridge for object (entity) types
Limiting expressiveness e.g., binarisation
14
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Choices for Specification: Perspectives andStyles
Structure-oriented perspective: structural description of the IS
+ semantic perspective
Behaviour-oriented perspective: behaviour of the IS during its
lifetime
event approaches, Petri-net approaches, predicate transition sy-
stems
Process-oriented perspective operation of the system�� ��Advantages
development methodology and scheduling, results in development stra-
tegies (top-down, inside-out, ...), analysability�� ��Disadvantages
depends on whether a system will have this perspective
15
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
State Of The Art So FarUsed in practice Theoretical back-
ground
Earliest layer of
specification
Structures well done well developed strategic
Static semantics partially used well developed conceptual
Processes somehow done parts and pieces requirements
Dynamic seman-
tics
some parts parts and
glimpses
implementation
Services implementations ad-hoc implementation
Exchange frames intentionally done nothing implementation
Interfaces intuitive nothing implementation
Stories intuitive nothing implementation
Late Specification, Inflexibility, and Unmaintainability
extension, change management and integration become a nightmare
16
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Languages: Extended ER + DistrLang +SiteLang
Structuring on the basis of an extended ER model
that is based on hierarchical predicate logic
Functionality on the basis of HERM/LC
with HERM-algebra, HERM/QBE, query forms and transactions
with some kinds of dynamic integrity constraints, behavior
GCS integrity enforcement instead of rule triggering pitfalls
Interactivity in integrated form based on SiteLang
description of dialogue scenes, stories, story space
( actors, scenario, dialogue steps)
Distribution through service specification and exchange frames
Translation and transformation methods for compilation of design into other mo-
dels (logical, physical) or XML
see B. Thalheim, Entity-Relationship Modeling. Springer, Berlin, 2000
Development and engineering methods for pragmatism (see my homepage)
17
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Constructs of the Co-Design Languages
Structuring as pair
Structuring := ( Structure, Static Constraints)
Structure as (marked) expression on constructors
Functionality as pair (Operations, Dynamic constraints)
Functionality := ((StateChange∪Retrieval)Operations ,DynamicConstraints)
Operations on the basis of the HERM algebra (for modification and
retrieval)
providing a language for generalized views (media types)
... .
18
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
An Example of a Database Schema
Course Semester -Professor Person
Room�
6
proposedCourse
Kind �
6
Courseheld
[]
�
6
plannedCourse
[]
[]
Program{}
Time(Proposal,
SideCondition)
TimeFrame
Request
Proposal
Teacher
inserted
Responsible4Course
�
*1k
-
*
+
For more information: http://www.is.informatik.uni-kiel.de/∼thalheim/slides.htm
19
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Functionality Modelling: AttachedOperations
• on operation on a views M consists of
• an operation signature: name, input-parameters, output-
parameters
• a selection type which is a supertype of cont(M)
• and a body which is defined via operations accessing the under-
lying database
• several standard operations are of particular interest:
• ...
20
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Functionality Modelling: AttachedOperations
• ...
• several standard operations are of particular interest:
• Generalization: generation of aggregated data, especially in the case of
insufficient space, i.e., roll-up, slicing, grouping
• Specialization: used for querying the database in order to obtain more details
for aggregated data, e.g., drill-down
• Reordering : used for the rearrangement of data, e.g., pivoting, dimension
destroying, pull, push, rotate
• Browsing : useful in the case that information cannot be presented comple-
tely
• Linking : useful whenever the user is required to imagine the context or link
structure
• Surveying : used for the graphical visualization of the content
• Searching : attached to enable the computation of ad-hoc aggregates
• Join: used for the construction of more complex raw media objects
21
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Intensional Functionality Specification
Business Case: Enter information on lectures after being requested
Caller Organizational unit Help and auxiliary in-
formation
Request to responsi-
ble person
Chair Courses, programs,
rooms
Actions for:
1. Entry Responsible person of chair
Main information entry ;
(Classification || categorize || input of other data || input of side conditions );
2. Confirmation step Responsible person and members of chair
Proofreading, correction, extension for requests, main and other data
3. Submission step Responsible person of the chair
Archive in chair folder ; send data to caller; publish at chairs internal page
22
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Functionality and Views: SupportedFunctions for New Course Proposals
Course
retrieve, select, input
Chair
retrieve
retrieve
Semester
6
-Professor
retrieve, select
?
required
Course
retrieve
Person
retrieve
Room
retrieve, select
�
6
proposed
Course
input
Kind
retrieve, select
Program
retrieve, select
{}
Time(Proposal,
SideConditions)
Description = “SS01/02”
ShortDescr = “DBIS”
default = Profβ
Wish
Proposal
Teacher
insertedBy= “SecrKK”
Responsible4Course = “β”
�* 1
k
k
-
s
-
+
K
(1,1)
+
23
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Media Types and Media Object Suites
• Raw media types = (cont(M), sup(M), view(M), op(M))
content type cont(M), set of supertypes sup(M),
view(M) = Q (Sinp,Soutp) HERM view
generic functions op(M) for changing the database
• Attached operations: (signature, selection type, body)
selection type - supertype of cont(M)
e.g. generalization/specialization, reordering, browsing, linking, surveying,
searching, join
• Media type: raw media type + unit extension
+ order extension + cohesion/adhesion + hierarchical versions
• Usage modeling: usage dimensions, scales, user profiles, user kind
• Container = (cont(C), layout(C), kind(C))
for shipping and representation
24
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Constructs of the Co-Design Languages...
Distributivity as pair (Services, Exchange Frames)
Distribution := ( Service (Informational process, Service Manager,
Competence),
ExchangeFrame (Architecture Collaboration Style,
CollaborationPattern))
Services on the basis of generalized views (media types)
Interactivity as 4-tuple
Interaction := (StorySpace, Actors,MediaObjects, Presentation)
StorySpace as graph of scenes and activities
Actors are abstractions of user groups
MediaObjects are used by actors and are based on generalized views
(media types)
25
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Interactivity Specification ThroughSiteLang
Story space - space of all specified stories
Story - labeled graph of different integrated scenarios
Scenario - run through a system by a cooperating set of actors
Scene of scenario - consistent set of dialogue steps
Dialogue step - conditional actions of an enabled actor on page based
on provided media objects
rui: on event if precond do actions accept on postcond
if precondruiand event then actions and CommitStaterui
= toCommit
if CommitStaterui= toCommit and postcondrui
then Commitrui
if CommitStaterui= toCommit and ¬ postcondrui
then Undorui
Interaction space - space of all possible interaction stories
System space - glass box of system (all runs integrated)
26
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Interaction ModelingStory as labeled di-graph S = (V,E, λ, κ)
V - scenes, E ⊆ V × V - transitions
media object assignment λ : V → {MediaObj}representation through media objects
with permitted rights, permitted roles, obligations of actors
MediaObject (Container, ManipulatRequests, SuppliedFunctions)
activity assignment κ : E → {Activity}activity = ( actor(profile) , task,
context (equipment, channel, rights, roles, particular),
representation (style, default, emphasis, ...))
Scenario - run through the system
with cumulative history (and adaptation)
consists of scenes
visited sequentially or in parallel by actors
story space - composition of sequences
27
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Interactivity Design via StoryboardsCourse Data Entry Scene Extended With Internal Negotiations
K
Y
Loginby chairsresponsible
z
:
Collectseminarproposals
j
j
Generatenew courseproposal
j Settledata forproposal
j Entryof necessary
data
Acceptcoursedemand
U
Settledata forseminar
:
K
Confirmation
:
Submissionchairdata
UAssignmentof coursesto members
j
UNegotiation ofassignmentsby members
UFormulation
of sideconditions
K
UAuxiliary& historic
data
y
Chairs Lecture Proposal Scene
28
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Modern Information Systems
Database systems as the kernelDBS = DBMS + { DB }
• Structuring of databases (structure + static integrity)
• Functionality based on programming by generic functions
Information systems based on database systems andcoping with the user perspective:
• Users stories, scenarios within the story space
• Users views on content based on media types
• Context (users, content, functionality, environment, provider, history)
Collaborating information systems coping with component sy-stems
• Components providing services over networks
• Collaboration for task solution
Nowadays: Co-Design of Four Dimensions
29
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Systems as ContentManagement Systems
Layer 0: Data and documents of underlying databases as micro-data
Layer 1: Content of content bases as macro-data or aggregations
Layer 2: Concepts of concept bases for foundation/explanation
Layer 3: Topics of topic landscapes for annotation/representation
Layer 3-4: Privacy protection layer
Layer 4: Memes of the users
• The user understands chunks of concepts.
• The user expresses data needs through utterances based on
association to topics.
• The user queries for content or data through views.
30
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Architecture of User-Oriented ContentManagement Systems�� ��Towards this century CMS
ContentManagement System
(Pragmatics)
Static IC
Structure
(Pragmatics)
Dynamic IC
Processes
FunctionalityStructure
Container
Structuring Functionality
Content typesService
Web Playout System
Story Space
Scenarios
ActorsStories
Context
Concept Managem. System
Topic Management System
User Management System
Profilemanager
Portfoliomanager
Association generator /Natural language engine
Privacy Protection System
TopicmanagerAsset manager /Infon representer
Communitymanager
Conceptmanager
Unit manager /Infon representer
Derivationengine
Contentbase
-�
6?
Data-base
-� Conceptbase
-�
Topiclandscape
-�
Privatedata-base
-�
6
? 6?
31
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Domain Description
(1) modelling business processing facets of an application domain,
(2) modelling intrinsic facets of an application domain,
(3) modelling possible support technology facets of an application do-
main,
(4) modelling possible management and organisation facets of an app-
lication domain,
(5) modelling possible rules and regulations of an application domain,
(6) modelling possible script (story) facets of an application domain,
(7) modelling possible human behavior facets of an application domain
32
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Janus Head for Socio-TechnicalSystems
The social viewpoint: the environment of the user
• life cases and application cases that are important for the user
• tasks that must be solved by the user in order to overcome problems of their
daily life
• context of the user, e.g., cultural, language
• users within their collaboration with other users; community of practice or
society; organisational structure; user information; user features
The technical viewpoint: database system and/or application logic system
(that supports the user)
• database system with the database and the database management system
• logical procedures that might be of use for the system deployment
• supporting facilities such as analysis machines or data warehouses
The mediating connector: media objects based on views and with functions
that allow a user to act with the system
33
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Demand based on UserProfiles and Portfolio
A user has an information demand that might be satisfied by the data-
base system. Information is - of course - data. It is however data that
the user notices, understands, and integrates into his knowledge space.
Information demand support depending on specifics
• Workplace and workspace support
• Consumed and produced data
• Context demand
• Formulation, language
based on characterisation of the user, user stories
Task/work portfolio support for the user
• Tasks: characteristics, execution, result, control
• Involvement: role, part
• Collaboration: communication, coordination, cooperation
• Restrictions: subtasks, environment
Personal profile support for the user
• Work profile
• Education profile
• Group profile34
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Demand versus InformationNeed�� ��not anything what can be delivered should be delivered but ...
objectively availableinformation offering
subjectively availableinformation offering
information need
articulatedrequest
objectivelynecessary demand
informationstock
�� ��request abilities, incomplete knowledge about yourself, reasoning handicaps�� ��incomplete data, non-cooperative behaviour, policy, accessibility, ...
35
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are User-Oriented:The User Viewpoint
Task User
Life CaseContext
Society Knowledge
36
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are User-Oriented:The Information System Viewpoint
Content Database
ProcedureFunction
AlgebraAnalysis
37
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Specification of User Profiles
User profile: ⟨user profile name⟩Education profile: ⟨general description⟩
Education: ⟨list of degrees⟩Capabilities: ⟨list of skills⟩Knowledge: ⟨description of knowledge in the application⟩
Work profile: ⟨general description⟩Task expertise: ⟨description of knowledge⟩Task experience: ⟨positive and negative experience⟩System experience: ⟨experience with infrastructure planned⟩Information profile: ⟨information need⟩Interaction profile: ⟨interaction properties⟩
Personality profile: ⟨general description⟩General properties: ⟨list of user properties⟩Preferences: ⟨list of input/output/dialogue preferences⟩Polarity profile: ⟨list of of polarity properties⟩
Derivable profiles: ⟨profile description and enforcement⟩Security profile: ⟨access control and privacy⟩Safety profile: ⟨safety requirements⟩
Based On: ⟨user goals⟩Based On: ⟨user types⟩
38
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Specification of Portfolio�� ��Explicit scoping of information
Party portfolio: ⟨party portfolio name⟩Task: ⟨general description⟩
Characterisation: ⟨general description⟩Initial state: ⟨characterisation of the initial state⟩Target state: ⟨characterisation of the target state⟩Profile: ⟨profile presupposed for solution⟩Instruments: ⟨list of instruments for solution⟩Collaboration: ⟨specification of collaboration required⟩Auxiliary: ⟨list of auxiliary conditions⟩
Execution: ⟨list of activities, control, data⟩Result: ⟨final state, satisfied target conditions⟩
Party involvement: ⟨general description⟩Role: ⟨description of role⟩Part: ⟨behavioural categories and stereotypes⟩
Collaboration: ⟨general description⟩Restrictions: ⟨general description⟩
Party restrictions: ⟨general description⟩Environment: ⟨general description⟩
Based On: ⟨life cases⟩
39
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Modelling must CaptureProfile and Portfolio of Users�� ��Know the purpose of information
Construction purpose for construction of a solution to application
domain problems (either as business system or as embedded system)
Communication purpose among stakeholders
Analysis purpose for validation, verification, tests
Examination ad check purpose for application domain or con-
structed system
Documentation purpose for logging development decisions,alternatives, neglected parts, variants, reference models
Master complexity, improvement, evolution, and realisation�� ��Each purpose requires its constructions and approaches!�� ��We must know the information demand!!!! -
40
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Portfolio��
��The missing ‘silver bullet’ for WIS description/prespription
Information production and consumption: information provided by the
system to its users and information entered by a user into the system
context-sensitive: user, data, story, functions, provide, system, user history,
runtime
views with different playout functions, containers for delivery
Information demand and need as two sides of the user space:
(1) need: perceived lack of something desirable or useful
(2) demand: act of demanding or asking
Persona: information is data for the user based on received / requested data,
which has to be organized, interpreted, understood, and integrated into his/her
knowledge
therefore: user model, specific requests of the user, ability of the user to un-
derstand the data, and skills of the user to integrate
simpler approach: characterise the user by prototypesContent chunks: which content is necessary for which actors or users with which
understanding, annotation, shortcuts, with which functionality
41
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are User-Oriented:The User and the System Viewpoints
Task User
Life Case Context
Society Knowledge
Information demand
Data & functions
requested &
consumed &
produced
Content Database
ProcedureFunction
AlgebraAnalysis
Antropomorphic notion of the concept of information:
Information as processed by humans, is data perceived or noticed,
selected and organised by its receiver, because of his subjective human
interests, originating from his instincts, feelings, experience, intuition,
common sense, values, beliefs, personal knowledge, or wisdom simulta-
neously processed by his cognitive and mental processes, and seamlessly
integrated in his recallable knowledge.
42
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Media Type as the Mediator
Content Database
ProcedureFunction
• information demand and work of
the user is supported by a service
• service is a composition of views
and functions
• services must be adaptable to the
specific demand of a user, to the
specific life case, to the specific
features requested by the user
• services combine information and
features for the support of the
user
Media type specifies media objects delivered to
the user
Containers are media objects adapted to the
user, the context, the environment and the way
of working
Procedures of a system support the functions
provided by the system and use the schema of
the views
View schemata are HERM schemata; sometimes
we might use schemata consisting of one type;
in most cases we need however schemata with
many associated types
Views allow to use the Salami slice modelling ap-
proach without suffering from the local-as-view
approach
43
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are User-Oriented:
Services Provided by a Systemthat Satisfy the Information Demand
Task User
Life Case Context
Society Knowledge
Service Information
Feature
�-
�-
�-
Serviceinterface
Content Database
ProcedureFunction
AlgebraAnalysis
Services deliver and accept the data based on content to the user
Information as requested by the user
Features of the information system for the support of the user
44
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Systems are User-Oriented:Media Objects
for Information-Intensive Systems
Task User
Life Case Context
Society Knowledge
�-
Informationservice
Content Database
ProcedureFunction
Media Object
AlgebraAnalysis
Containers deliver and accept the data based on content to the user
Container are media types, i.e., provide data with functions for their
utilisation
Information as requested by the user through media objects
Media objects for holistic information logistics
45
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Domain Description (1)
Users - Intentions - Context�
Brand of WIS(scope)
Life Cases
9Portfolio
�Profiles
R
Word fields
?Associators
z� -
Storyboard
?
9
Substantiveword fields
9Verb
word fields
?
Application Domain Description
?Containers
z?9?Media types � - Presentation� -
46
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Domain Description (1′)
Users - Intentions - Context�Life Cases
9
Brand of WIS(scope)
Portfolio
�Profiles
R
Word fields
?Associators
z� -
Storyboard
?
9
Content chunks
9Function chunks
?
RequirementsPrescription
?Containers
z?9?Media types � - Presentation� -
47
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Domain Description (2)
• D. Bjorner: High-level, informal application domain description
• L. Heinrich: Strategic information analysis
• Volere: Business use cases (simple word fields) combined to
business scenarios and business tasks
Product scope
9 ?
Business use case
(Product)use case
9 zFunctional, nonfunctional,
or technological requirements
?
?
Business events
Constraints
z 9?UML diagrams
48
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Modelling Life Cases by Stories�� ��Digicult: Representing successful behavioural pattern
K
Surveyon opportunities
j
K
Deletingoptions
U
j Nofurtheroptions
jGaining info
on problems
zSamplecasesY
U z
j
Successfulcases
K
Approachesfor use
y :
SimilarcasesY
Backgroundinfo
9
Analogous search
Mapping behaviour of users with full option space
Intelligent representation of information and knowledge spaces
Adaptation to the user, curent situation, context, ...
Logistics for content
49
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
User Intentions
Intention space: ⟨intention name⟩Purpose: ⟨outcome description⟩
Aims: ⟨list of aims⟩Objectives: ⟨list of objectives⟩
Intents: ⟨outcome description⟩Targets: ⟨list of weighted targets⟩Objects: ⟨list of weighted objects⟩Themes: ⟨class of intents⟩
Time: ⟨outcome description⟩Design: ⟨general flow⟩End: ⟨effects, termination conditions⟩Occasion: ⟨list of objectives⟩
Representation: ⟨general style guide⟩Atmosphere: ⟨general description of atmosphere⟩Metaphors: ⟨list of metaphors⟩
Based On: ⟨tasks, audience, mission, goal⟩
50
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Input for the Application DomainDescription
• User: General description of the users
• User intentions: General description gathering the reasons to visit
the WIS
• User profiles: General specification of the userstogether with personas
• Context of the WIS in general
51
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Application Domain Description
• Brand of the WIS
• Life cases with relative importance for the WIS
• Word fields as basis business activities (business use cases and
events)
• Associators representing the general life case chart
• Portfolio supported by the WIS
• Context of the WIS depending on technology
• Actor profiles and portfolio
52
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Life Cases
Life case: ⟨life case name⟩Characterisation: ⟨outcome description⟩
Tasks: ⟨list of user tasks⟩Problems: ⟨list of problems⟩Background: ⟨general characterisation⟩Objectives: ⟨list of objectives⟩
Life case flow: ⟨general graphical description⟩Milestones: ⟨graph of milestones⟩Content consumed: ⟨consumed content items⟩Content produced: ⟨produced content items⟩Themes: ⟨class of intents⟩
Figures: ⟨actors list⟩Expected profile: ⟨general profile description⟩Collaboration: ⟨general collaboration description⟩
Context: ⟨general context description⟩Time: ⟨temporality limitations⟩Place: ⟨assignment of places⟩Legacy: ⟨names of documents⟩WIS: ⟨general WIS context⟩
Representation: ⟨general behavior⟩Approaches: ⟨general description of approaches⟩
53
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Refinement of Life Cases
Life case: ⟨life case name⟩Tasks: ⟨list of tasks associated with the life case⟩Actors involvement: ⟨description of actors involvement⟩Profile restrictions: ⟨list of restrictions due to actors profile⟩Context specialisation: ⟨context embedding⟩
relocation
parties
housing benefit
house owner benefit
insurance agencies
health insurance
associated life cases
associated parties
vehicle documents
parking card
specialownership
special/exceptional
foreign resident
foreign temporary
second home additional taxation rent level
employment office
employer
employment
phone
water,sewage
supply energy,gas
pets registration
pet taxpets
children
partners
proofs
certificaterscertificate of authority for authorizing others
pension approval certificate
employment documents
marriage certificate
driving licence
child identification card
degrees
birth certificateidentification
passport
necessary documents
special names
income tax card
passport
pseudonyms
fratemity
associated documents
addressto
from proof of moving out
proof of moving in
special documents
citizenship
potential changes
potential changes
address
address
school
housing
special contracts
documents from handicaped car
tv/radio
housing allowance
housing programme
housing eligibility
special parking permission
forwarding period
forwarding address
insurance
bank
collect charges
house registrationhouse number
private people
parties, organisation registration
directory
obligation of secrecy
disclosure
provided reasonsaccepted restrictionsoverruled restrictions
social support
move life case
contracting
restrictions
application for registration
forwarding mail
tax
religious organizations
actors
basic changes
issuer
agencies
special support
recipients
schools
directory companies
automated contracting
aliens department
police
statistics agenca
tax office
ministery
official bodies
companies
support of organization
data protection official
documentation agency
contracters
civil servant
public authorities
citzen office
town clerk`s office
factory inspectorate
TV/radio
54
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Life Case Elicitation
• Abstraction by making useful generalisations
• Business events investigation observing business reality
• Brainstorming for generating good ideas and to solve problems
• community therapy by bounding stakeholders together like a familysteps: intake for scoping, meaning elicitation,
significance, response
• Interviewing for gathering
• Mind mapping by taking extensive and meaningful notes
• Neurolinguistic programming based on models, skills and techniques for thin-
king and acting effectively
• ...
55
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Life Case Elicitation
• ...
• Reusing designs, requirements, and ideas
• Simulation model scenarios and prototyping based on life stories
• Soft systems observation and modelling for understanding and tackling real-
world problems
• Systems archeology for extracting ideas, requirements and design from existing
systems
• Use case workshops by reviewing and questioning based on business use cases
• Video recording of uses reactions to software products
• Viewpoints focusing
56
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Interaction ModellingStory as labeled di-graph S = (V,E, λ, κ)
V - scenes, E ⊆ V × V - transitions
media object assignment λ : V → {MediaObj}representation through media objects
with permitted rights, permitted roles, obligations of actors
MediaObject (Container, ManipulatRequests, SuppliedFunctions)
activity assignment κ : E → {Activity}activity = ( actor(profile) , task,
context (equipment, channel, rights, roles, particular),
representation (style, default, emphasis, ...))
Scenario - run through the system
with cumulative history (and adaptation)
consists of scenes
visited sequentially or in parallel by actors
story space - composition of sequences
57
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Memes of the Referent or User Dimensionfor CMS
• names,
• a number of properties,
• a variety of associations with different adhesions to other memes,
• and a variety of groupings for different purposes.
Semantics Pragmatics
Syntax
Content
Concepts Topics
User
Memes
Domain understanding
Enrich
Utterance
58
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Result of user-oriented CMS�� ��Not trapped in the SQL trap; better enhanced VisualSQL!!!
Tina Musterfrau,casualuser
?
6
-userin the
DBMS trap
help !!help !!
??
?
6
?
topicwelt
concepts
searchconcept
?resultconcept
- answerform
?
answerfor search
- queryform
SQLquery
-
relationaldatabaseschema
?
parametricHERM
expressions
?
SQL queryset
)
DBMS queryrepresentation
q
?
queryinterface
�-
Searchrequest
:
� database
DBS
59
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Languages (syntax√, semantics ??,
pragmatics ????)
• Languages for specification
• Structures (object-relational)√
• Functions DML-based ?????
• Distribution system-based
• Interaction interface, XML ???
• Languages of tools may be also UML
• Language and wording conventions of developers and teams
• Educational gap
• Binarization, weak types, pointers and other non-sense
Payoff: Babylonian Language Utilization
• Mismatches: structure / function, structure / static constraints,
static constraints / maintenance, dynamic constraints in implemen-
tations
• Interfaces are going to be developed later
• Distribution in the Las Vegas approach
60
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Conceptualisation: Oneness of Schema(ta)�� ��Depending on the viewpoint
Leading, governing schemata in UML (13 of 142)
Class diagram with associated object, package, composite structure, de-
ployment, and distribution diagrams
State machine diagram with associated use case, activity diagrams
Interaction diagram with associated communication, sequence, timing
diagrams
or consider the ER-backed layered conceptual modelling
(1) (Extended) Entity-Relationship schema with H(igher-order)ER alge-
bra, HERM logics as the governing or kernel schema
(2) Business process model ,e.g., BPMN
(3) Distribution styles, profiles, pattern with communication + coopera-
tion + coordination
(4) Storyboards and stories as the often neglected dimensions
61
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Separation of Concern
(a) Properties essential for things of consideration in the application
domain
(b) Log as a volatile but essential piece of data
(b1) docket / superimposed schemata
(b2) source
(b3) time
... ...
resulting in
• binding schemata for references
• implicit exclusion via explicit exclusion
• special viewpoints (with importance in the development and de-
ployment processes)
62
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Three-Model-Conceptualisation
Natural model: representing reality as it is
m-schema as an object-centred representation:
my car # my car product # my car model #my car brand # my car manufacturer #my product # my product registration
thing of reality with scope, role, cohesion/adhesion, context, func-
tion, ‘personality’, competing viewpoints, with ‘natural’ semantics
Universal model: ER-architecture with inner (abstract) structure
and scoping profiles, explicit shuffling among schema dimensions,
folders and mappers, with full semantics and enforcement styles
Implementation model: class-separation schema with central -
view tower architecture, performance information as an class-
centred representation, with rigid implementation semantics�� ��Information (iso-)morphism among the three schemata�� ��Mapping theory with the universal model as governor.��
��Refinement of ER schemata (see Qing/β @ ER’2011)
63
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Conceptualisation: Solution�� ��Assumption nowadays: Oneness of conceptual schema
instead however
Application-oriented conceptual schema: typically compacti-
fied;
with different viewpoints for roles of stakeholders;
zooming out, scaling, scoping
Universal (real) conceptual schema: represents the conceptua-
lisation;
based on many-dimensional separation of concern
Realisation-oriented conceptual schema: depending on imple-
mentation policy, style and implementation platform;
also object-wise realisation
64
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Software Engineering Quadruple
Software specification
Requirementsprescription
Architectureblueprint
Application domain description
The ‘holy’ triade so far extended by context
• Application domain description
• Requirements prescription
• Software specification
65
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Classical dichotomy: Human-computersystems and information systems
ImplementationTransformation
Informationsystem
Presentationsystem
Web information system
Implementationlayer
Information systemspecification
Presentation systemspecification
WIS specification
Conceptuallayer
DesignRefinement
Applicationarea
description
Requirementsprescriptions
WIS descriptionand prescription
Description/prescription
layer
66
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Dichotomy of human-computer systemsand modern software systems
ImplementationTransformation
Presentationsystem
Informationsystem
Web information system
Implementationlayer
Presentation systemspecification
Information systemsspecification
WIS specification
Conceptuallayer
DesignRefinement
Applicationarea
description
Requirementsprescriptions
WIS descriptionand prescription
Description/prescription
layer
67
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Logical Tuning
• Tuning the disk cache
• Tuning the logical schema
• Query optimisation support
• Denormalisation of logical schemata for performance improvement
• Materialisation and layered architectures
• Query ‘gardening’
• Transaction processing tuning
• Load control techniques
68
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Conceptual Tuning
• Optimising the conceptual schema
• Performance-oriented translation to logical and physical schemata
• Adaptation to the optimisation strategy of the DBMS
• Technical tuning at the conceptual level
• Revision and optimisation of the logical schema
• Explicit performance-oriented control strategies for integrity main-
tenance
• Explicit introduction of parameters for performance collapses
• Optimisation of functions and queries depending on translation
choices, with explicit introduction of alternatives
69
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The General Approach to PerformanceModelling
70
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Modelling the Application DemandPortfolio
the characterisation of the kind of computation based on
the description of the operations involved, the operation support,
and the data volumina transferred for support of computation,
the visibility description of processes for the business user
that includes frequency of operations and their relation to business
processes,
the description of the modes of computation such as onli-
ne, batch and interactive mode of computation or deferrable and
immediate application of computation,
the performance properties and quality based on the expec-
ted execution time for online etc. modes, based on the throughput
expectation for queries, modifications and transactions, based on
restrictions such as suitability or response time, and based on prio-
rity claims issued by the business user,
the criticality level of the processes.
71
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Modelling the Database SystemPerformance Parameter Space
72
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Different Scope - Need - Demand
• Business user , application-oriented scopes, local processes, repre-
sentation in an adequate form
• Scope-oriented representation for reasoning of a singleton user
(object-centred model style (XML style)
• Data representation at different abstraction and granularity levels
(raw, cleansed/settled, stored, aggregated, analysis data)
• All necessary information for implementation, e.g., usage profile
and portfolio, set cardinalities, performance demands with perfor-
mance tolerances, denormalisation and normalisation opportunities,
semantics enforcement profiles�� ��Salami-slice-oriented conceptual models as the main style.��
��Delay all other information to implementation (logical/physical) levels! /�� ��Conceptual modelling is the programming of the future!!!! ,
73
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Abstraction Layer Models�� ��Separation by Level of Detail
Application domain layer concerned with description of the app-
lication
Requirements acquisition layer concerned with prescription of
system requirements
Business user layer concerned with behaviour or users, their de-
mands to the system
Conceptual layer concerned with specifications (schemata) that de-
scribe the system
Implementation layer concerned with logical and physical (speci-
fications and) programs
Deployment layer concerned with introduction, usage, mainte-
nance, evolution of the system
74
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Abstraction Layer
Functionalityspecification
Structuringspecification
Distributionspecification
Dialoguespecification
Implementationlayer
Conceptuallayer
Business userlayer
Requirementsacquisition
layer
Application domainlayer
Imple-menting
De-signing
Vari-ating
Scoping
?
?
?
?
75
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Abstraction Layer Models�� ��Separation by Level of Detail
Application domain layer concerned with description of the app-
lication
Requirements acquisition layer concerned with prescription of
system requirements
Business user layer concerned with behaviour or users, their de-
mands to the system
Conceptual layer concerned with specifications (schemata) that de-
scribe the system
Implementation layer concerned with logical and physical (speci-
fications and) programs
Deployment layer concerned with introduction, usage, mainte-
nance, evolution of the system
76
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design Working: AbstractionDesign Layers
Functionalityspecification
Structuring
specification
Distributionspecification
Dialogue
specification
Implementationlayer
Conceptuallayer
Business userlayer
Requirementsacquisition
layer
Application domainlayer
Imple-
menting
De-signing
Vari-ating
Scoping
?
?
?
?
77
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design Working: GeneralDescription
Application domain or strategic layer:
HERM (concept map (concept)),
HERM (functionality (feature)),
DistrLang (contract sketch (contract, quality criteria))
SiteLang (application story (application step))
(1) Developing visions, aims and goals
(2) Analysis of challenges and competitors
Stakeholder contract (“Lastenheft”)nowadays: Product feature catalog
78
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design WorkingRequirements Specification
Requirements acquisition layer:
HERM (sketch (rough type)),
HERM (business process (business step)),
DistrLang (contract opportunities),
SiteLang (story (event))
(3) Separation into system components
(4) Sketching the story space
(5) Sketching the view suite
(6) Specifying business processes
IS development and system documentation (“Pflichtenheft”)
79
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design WorkingUsage, Usability and Application Stories
Business user layer:
HERM (skeleton (application type)),
HERM (activity (action)),
DistrLang (media types, contract),
SiteLang (plot (theme), actors, media types)
(7) Development of scenarios of the story space
(8) Elicitation of main data types and their associations
(9) Development of kernel integrity constraints, e.g., identification constraints
(10) Specification of user actions, usability requirements, and sketching media
types
(11) Elicitation of ubiquity and security requirements
Playout system specification
80
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design WorkingConceptual Specification
Conceptual layer:
HERM (schema(types)),
HERM (workflow (process)),
DistrLang (service space, exchange frame),
SiteLang (story space, actors, media types, presentation)
(12) Specification of the story space
(13) Development of data types, integrity constraint, their enforcement
(14) Specification of the view suite, services and exchange frames
(15) Development of workflows
(16) Control of results by sample data, sample processes, and sample scenarios
(17) Specification of the media type suite
(18) Modular refinement of types, views, operations, services, and scenes
(19) Normalization of structures
(20) Integration of components along architecture
Conceptual schemata
81
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Making Co-Design WorkingImplementation Layer
Implementation layer:
o-r DDL (o-r schema (relation)),
PL (module) language (program, trigger, sp, ...),
Distribution specification language (distributed system
(distribution, protocol, call))
Dialog system language (presentation space (working sheet))
(21) Transformation of conceptual schemata into logical schemata, programs,
and interfaces
(22) Development of logical services and exchange frames
(23) Developing solutions for performance improvement, tuning
(24) Transformation of logical schemata into physical schemata
(25) Checking durability, robustness, scalability, and extensibility
Program library
82
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Abstraction Layers and SPICE ModelCategories in WIS Co-Design
83
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Principal Element Types of Co-Designand SPICE
Document*
Step*
Layer
Aspect
*
CO-DESIGN Input Product
Output WorkProduct
Base Practice
*
Process*
*
*
*
Process Group
*
SPICE Process Dimension
Generic Resource
Generic WorkProduct
Generic Practice
*
Process Attribute*
*
*
*
Capability Level
*
SPICE Capability Dimension
-
-
-
84
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
SPICEing Co-Design: Towards OptimizingProcesses�� ��Model Space Restrictions during Co-Design
85
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Evaluated Development by RapidPrototyping and Executable Specifications
executable specifications based on Model Driven Software Develop-
ment
automatic transformation of specifications on higher layers of abstraction to exe-
cutable programs without manual transformation steps
86
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Evolution as the Real Challengealready evolution of one model is a challenge
models change over time
co-evolution becomes a nightmare if not planned in advance
dynamic adaptation is another challenge
87
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Variety of UML-“languages”
ClassDiagram
ObjectDiagram
PackageDiagram
DeploymentDiagram
ComponentDiagram
CompositeStructureDiagram
StructureDiagram
BehavioralDiagrams
Superstructure
MetamodelDiagram
Main UML Diagrams
Use CaseDiagram
InteractionDiagrams
ActivityDiagram
StateMachineDiagram
Behavioral Diagrams
SequenceDiagram
CommunicationDiagram
TimingDiagram
Interaction OverviewDiagram
Interaction Diagrams
88
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Coherence of UML Diagram Clusters
inherent integrity constraints in diagrams
StateChart({IsBorrowed, IsReturned}) ⊆ ClassDiagram(πLendingState(Book))
ECstates(SC,CT )1 : StateChart(States) ⊆ ClassDiagram(πX(RulingClass))
State′ ∈ ClassDiagram(πX(RulingClass)) −→ F modify(StateChart(State, State′))
O cascade(modify(ClassDiagram(RulingClass,X)), modify(StateChart(State)))
do(Agent1, modify(ClassDiagram(RulingClass,X))) ydo(notify(Agent2, modify(ClassDiagram(RulingClass,X))))
89
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Challenges in Multi-Model EnvironmentsExplicit specification of model collaboration: interdependencies
among models
Integrated development of different models: different views of the
same problem or application
Co-evolution of models: exchange between models and change propa-
gation
Combining different (e.g., graphical) representations with ma-
thematical rigor of models
Evolution of different representations: refinements of previous mo-
dels or explicit revisions of models
Management of multi-model IS development: scheduling mecha-
nisms, rollback
Version handling for multi-model IS development: different versi-
ons
Explicit refinement and abstraction treatment: systems develop-
ment abstraction layers
90
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suites: Collaboration of Models�� ��Handling abstraction
Explicit collaboration of models based on
• constructors
• mappings
• contracts among models
Dimensions of models based on the minimalisation of models and
constructors
Abstractions of models among mappings
Constructors for construction of new models
shuffle product, reduct , scope , integration
Theory extension for model context representation and context in-
tegration
91
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Layers of Models for IS�� ��Managing model suites by stratification
Collaboration speci-
fication layers
Infrastructure Collaboration
Application domain
layer
Application environment Collaboration policy, prin-
ciples, acts
Requirements layer System sketches, require-
ments, system decisions
Collaboration tasks, con-
tracts, style, pattern
Business user layer System view, parties, port-
folio
Collaboration stories
Conceptual layer Information system specifi-
cation, context support
3C-C schemata,
informational processes,
exchange frames
Logical layer Information system - logical
view
Collaboration supporting
system
Physical layer IS programs Collaboration programs
Deployment layer ... ...
92
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suites�� ��as a part of ISE@CAU model integration theory
Model structure based on model constructors starting from model
kernels and model orchestration and model choreographies
• constraints and structural soundness
• constraint enforcement
Model repository for coexistence of models based on the collabo-
ration pattern and style
• model communication generalising model protocols
• model coordination generalising model contracts
• model cooperation generalising model evolution
Model metadata as the basis for model quality management
Model evolution
93
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: Constituents
• set of models {M1, ....,Mn} ,
• association or collaboration schema among the models,
• controllers that maintain consistency or coherence of the model
suite,
• application schemata for explicit maintenance and evolution of the
model suite, and
• tracers for the establishment of the coherence.
Coherence describes a fixed relationship between the models in a model
suite. �� ��only inductive languages with compositionality principle�� ��concentration on discrete domains
94
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: LanguagesModel language L: signature S and a set of constructors C
ΣS,C well-formedness conditions
Model type TLS = (LS,ΣLS)language of the model andconstraints ΣLS ∈ L(ΣWellFormed
S )
Partial mappings Ri,j : LSi → LSj among LS1 , ...LSn
ModelM: structM in LSthat obeys ΣLS ,
and set of constraints ΣM defined in the logics of this language.
95
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: Model Association andContracting
Collaboration contract among models
Collaboration
• Communication is used in a variety of facets as an act or instance
of transmitting or a process by which information is exchanged
between models through a common system.
• Coordination expresses the act or action of coordinating the har-
monious functioning of models for effective results.
• Cooperation expresses the action of cooperating.
Collaboration style: supporting programs, data access pattern, style
of collaboration, coordination workflows
Collaboration pattern: supporting access and configuration, event
processing, synchronization, and parallel execution
96
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model SuiteModel suite type ST = (TLS1
, ..., TLSn,ΣLS1 ,...,LSn
)
model types TLS1... TLSn
defined on a set ΣS1,...,Sn ofLS1 , ...,LSn constraints
Model suite Son a model suite type ST
models (M1, ...,Mn) of type TLS1... TLSn
that obey ΣLS1 ,...,LSn
Contract on C:
• constraints ΣLS1∪ ... ∪ ΣLSn
∪ ΣLS1 ,...,LSn,
• description of the enforcement mechanisms for any operation that
can be used for modification of one model, and
• set of consistent evolution transformations.
97
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: Synchronisation andCoherence
Mi Mi,j,outp Mj,i,inp Mj
extract ei,j transform ti,j load li,j- - -
Commuting diagrams and co-evolution
M ′i M ′
j
Mi Mj
put∗i,j
put∗j,i
-
�?
changej
M ′i M ′
j
Mi Mj
put∗i,j
put∗j,i
-
�?
changej?changei �
98
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: Synchronisation andCoherence
Explicit mapping among models
Mi Mi,to(j) Mj,from(i) Mj
extract ei,j transform ti,j load li,j- - -
Mi Mi,from(j) Mj,to(i) Mj
load lj,i transform tj,i extract ej,i� � �
modeli modelj
ei,j
ej,ilj,i(tj,i(ej,i))
li,j(ti,j(ei,j))-ei,j
� tj,i(ej,i) �
ti,j(ei,j)
ej,i
ModelTransformer
-
Coordinationprofile
evolution-prone
completed to a model suite architecture
99
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Model Suite: Co-evolution
Databaseschema
Staticintegrity
constraints
Database structuremodelMstruct
Databasefunctionality
model
Dynamicintegrity
constraints
Database functionmodelMfunc
Contentmodel
Mcontent
Interactionmodel
Minteract
... model
Database support models
Information system modelMIS
M′struct M′
content
Mstruct Mcontent
put∗struct,content
put∗content,struct
-
�?
changecontent
M′funct M′′
struct
Mfunct
put∗struct,funct
put∗funct,struct
�
-
changefunct
?M′′
content
put∗struct,content- M′′interact
put∗content,interact-
M′interact
put∗content,interact-
Minteract
put∗content,interact-
100
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Hierarchical Layered Model SuitesTypical example for models at the same abstraction level
microDBS
mesoDBS
analysisDBS
presentationDBS
DBS(Sp,ΣSp ,
Op,ΣOp )
inject
insert--modifiable
injected
auxiliarydatabase
?injectedDBS
(Sc,ΣSc
Oc,ΣOc )
inject
insert--modifiable
injected
auxiliarydatabase
?injectedDBS
(Sr,ΣSr ,
Or,ΣOr )
inject
insert--modifiable
injected
auxiliarydatabase
?injectedDBS
(Sm,ΣSm ,
Om,ΣOm )
auxiliarydatabase
?injected
sensors,observations,
transaction data
storage, capturing,
historical integra-
tion, leverage, ar-
chiving
analysis, mining,
exploration, hypo-
theses generation
business sheets,
appendix for pu-
blication, web
presentation
explicit inheritance of underlying data
ownership principle
explicit explanation based on underlying data
agreed stratification of data and schemata
101
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Layers as a Building Block ofMulti-Layered Architectures�� ��Generalising architectures
Architecture of a multi-layer model suite
Operators: Oi,1, ...
Data objects: ti,1, ...
Operators: Oi+1,1, ...
Data objects: ti+1,1, ...
Layer i “realises” -
Layer i+1 “uses”
+ Layer language
Oi+1,p(ti+1,q)
Oi,r(ti,1, ..., ti,k), ..., Oi,s(ti,1, ..., ti,m)
?
6 Y
102
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
It’s Not a Bug It’s an ExceptionEncyclopedia Britannia
(1) the act of excepting : exclusion
(2) one that is excepted; especially : a case to which a rule does not
apply
(3) question, objection (witnesses whose authority is beyond exception
— T. B. Macaulay)
(4) an oral or written legal objection
Wordnet
(1) (18) exception, exclusion, elision
(a deliberate act of omission; “with the exception of the children, everyone was told the
news”)
(2) (8) exception
(an instance that does not conform to a rule or generalization; “all her children were brilliant;
the only exception was her last child”; “an exception tests the rule”)
(3) exception
(grounds for adverse criticism; “his authority is beyond exception”)
103
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Exceptions as the Typical Case
• Users have high expectations for the code we produce.
• Users will use our programs in unexpected ways.
• Due to design errors or coding errors, our programs may fail in
unexpected ways during execution.
• It is our responsibility to produce quality code that does not fail
unexpectedly.
• Consequently, we must design error handling into our programs.
• Exceptions act similar to method return flags in that any method
may raise and exception should it encounter an error.
• Exceptions isolate the code that deals with the error condition from
regular program logic.
104
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Classical Information Systems ModellingResults in Exceptions
• Building blocks (Chen’s notions): attribute type, entity type, rela-
tionship type, cluster type, etc.great facility for modelers bad restriction for users
• Strict bottom-up specification
inductive type construction
• Basic standardized (DBMS-influenced) type systemsimplicity of programming nightmare of DBS farm integration
• Mapping (transformation) of structuring and requeststo ortho-normal languages (e.g., SQL, HERM)
• Overloaded values and types requireexception handling (e.g., NULL, default)
105
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Kinds of Exceptions
Exceptions caused by errors: operation errors, design errors, organiza-
tional errors, hardware errors
explicit error treatment
recovery management based on explicit specification of errors
Exceptions caused by randomness or non-determinancy: appear and
vanish at any point of time
cannot be eliminated not described
extensions of recovery management?
Exceptions caused by incompleteness: modelling, specification incom-
plete due to complexity, limitations of languages and abilities
robust system specification?
Exceptions as systems flexibility: exceptions as ‘normal’ states or ‘nor-
mal’ reactions
exception handler: exceptional situations and correct treatment
106
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Shell Model for Exceptions
Rigorous exceptions: hardware exceptions (e.g. invalid instruction
code) or operating systems exceptions (e.g. memory error)
succeeding in most cases some other error (e.g. overwriting code by data)
Language exceptions: defined by the language developers
higher programming languages tolerate errors: semantic errors detected and repaired
by the language-specific runtime system
Library exceptions: variety of exceptional situations
modern programming language consists only on the kernel
all unnecessary components are provided by libraries
definition possibility for programmers and their own exception environment
Application exceptions require systematic treatment
107
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Exceptions in JavaTwo categories:
(1) Checked Exceptions: inherited from the core Java class
Exception frequently considered “non fatal” to program execu-
tion
handled in own code or passed to parent classes for handling
e.g., array index out of bounds, number format conversion, file not
found
handle the exception yourself, or pass the exception ‘up the chain’
(to a parent class)
(2) Unchecked Exceptions: error conditions
considered “fatal” to program execution
nothing to do with unchecked exception., program terminates with
appropriate error message
e.g. null pointer
108
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Exceptions in Java -Insufficiency
Try-catch-block: normal code logic inside a try-block of code
code to handle the exception placed in a catch-block
optional finally-block with ALWAYS executed code (operations
that must happen no matter what (e.g., cleanup)
Throw: any method might throw an exception (avoids handling the
exception yourself)
handled by the Java environment
100eds of exception classes
public void myMethod throws IOException {
109
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Ideas Driving Our Approach
• Conceptualisation of solutions to exceptions: Category-Problem-
Cause frame
• Enhancement of conceptual schemata by exception templates:
schemata and schema elements enhanced by templates that
characterise exception problems
• Development of control and measurement practices: proactive ex-
ception handling
exception monitor
110
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Category-Problem-Cause-SolutionTemplate
Category: description of general properties of concept-based macro-states with boundaries
Problem: macro-state space reachable from the current state with improved states, actions for
moving from one state to another state goal test, problem solution controller
Cause: description of causes and potential observation points,
Solution: definition of the solution, illustration of the solution, examples, pattern used for the
solution;
extended by required behaviour is to be controlled so that it satisfies certain conditions,
commanded behaviour is to be controlled in accordance with commands issued by an ope-
rator, information display states and behaviour information, imple Workpiece (create/edit/...
workpiece by user) and transformation mainly based on I/O transfer.
Reasoning approach:
• abductive reasoning (generation of hypotheses which, if true, would explain the collection of obser-
vations) +
• plausible reasoning (conclusions may have been withdrawn because of additional information) +
• evidential reasoning (relating observed effects and problems to causes)
111
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Generalising Database TechniquesStatic and dynamic integrity constraints e.g. structural cons-
traints, semantic constraints, representation constraints, pre- and
postconditions, operation clustering through TA’s, run restrictions,
features for instantiation, aspects as generic cross concerns
Explicit modelling of exceptions e.g. null values, default values,
placeholders, optional structuring, optionality
Explicit modelling of goodness in specific applications depen-
ding on context, versions
Inherent constraints of the language e.g. set semantics, com-
positionality,
Modelling of dynamism through schema layers on the basis
of base data, production data, archive data, derived data, log data,
data under development
112
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Learning from Constraint MaintenanceSystem
Type specification with constraints, with scoping of constraints
extension of current framework for anticipating and preparing
States of integrity constraints as a state diagram
explicit treatment of constraint context (type environment), their
propagation
explicit invalidation detection query
first: restricted class of constraints
without soft constraints
Operation set for treatment of violations with precondition and
postcondition operations
Integrity manager monitoring static properties (successful operati-
on) and dynamic properties
detection of probably inconsistent parts of the database
ability for diagnosing,resolving exceptions
treatment of exception conformance (consistency) and composition
Truth maintenance system
113
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Exception Facilitation Model
Inquire: Discovering the symptoms.
Investigate Defining the current state.
Vision: Defining the possibilities.
Analyse: Generating a list of potential solutions.
Qualify: Narrowing solutions down to those with the greatest lever-
age.
Plan: Securing ownership, commitment, permission.
Apply: Managing the realisation of the solution(s).
Report: Measuring the final outcome and capturing experience.
114
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Proactive Exception Handling�� ��based on a general conceptual approach
• (a) Conceptualisation of exception handling solutions.
• (b) Enhancement of conceptual schemata by exception handling
templates.
• (c) Development of control and measurement practices.
• (d) Development of parameter set reduction and dependence repre-
sentation techniques.
• (e) Substantiation of data mining and statistics techniques for per-
formance analysis.
• (f) Development of a exception handling framework .
115
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Privacy Enhanced Infrastructures�� ��Various Facets of Privacy Protection
“[P]rivacy will be to the information economy of the next century what
consumer protection and environmental concerns have been to the in-
dustrial society of the 20th century.”
Media privacy: supported by laws, constitutional rights and other
legal frameworks
Territorial privacy: supported by laws, constitutional rights and
other legal frameworks
Communication privacy: supported by laws, constitutional rights
and other legal frameworks
Bodily privacy: supported by laws, constitutional rights and other
legal frameworks
Information privacy: not well supported, tools for the “glass box
customer”
116
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Information Privacy EnhancedInfrastructures�� ��Basic Requirements
Information privacy: not well supported, tools for the “glass box
customer”
Openness and transparency: no secret record keeping
Individual participation: ability of change by the subject of
the record
Data quality: relevant to the purposes and and up-to-date
Collection limitation: collection proportional to its purpose
Use limitation: used for their specific purpose by authorized per-
sonnel
Reasonable security: adequate security safeguard
Accountability: accountable for the compliance with the other
principles
117
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Research Issues on Privacy EnhancingTechnologies
Decentralized architectures and query methodologies for weakly struc-
tured and heavily distributed data
Automatic acquisition and integration of context for information supply
on real demand (context-sensitive information logistics)
Dynamic orchestration of services, conditioning, optimal service granularity,
information asymmetry, payment
Data protection and security preferences of users and automatic ali-
gnment with characteristics of services
Adjustment between inspection of technology and minimization of transaction
costs
Ubiquitous and calm availability of all relevant data with redesign of busi-
ness processes, including logistics
Novel cooperation and coordination models based on policies, contracts,
arbiters
Support for economy of attention of human users with limited time
118
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Information Privacy Model (IPM)�� ��Towards sound theory and feasibility of management
Infons as the basic unit of chunks of data to be considered
Information: true infon(s)
Possession of infons by agents
Proprietorship of infons by individuals
Logical and procedural treatment of possession, proprietorship
and their relations
Constraints limiting the usage of infons
Architectures for information privacy enhanced information systems
Management of possession and proprietorship
119
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Separation of Concern: Proprietor,Possession, Privacy Unit
120
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Special Case: Participatory PrivacyEnhancing Systems�� ��Matured user with informed proprietors within a fully trusted community
Proprietor sovereignty principle: right to sovereigntyover his/her proprietary infons
policy supporting the proprietor sovereignty principle:possessor in the role of ‘content and topic observer’;proprietor in the role of ‘informed owner’ and ‘refresher’
contract: between proprietor and possessor for using content and topicson an ongoing basis in order tomonitor, collect information (about conditions of possession),give a warning, andtake actions such as use, security, welfare, accuracy, correctness,
and maintenance of infons
Faithful collaboration:portfolio and profile of contracting possessor
do not include any forbidden action or ability,all reporting obligations are observed
proprietor is observing his/her obligations
121
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Infon: The Concept�� ��Generalizing Kauppi, Devlin, Seligman, Wille
Infon definition:
• discrete item of information
• parametric: objects, anchors
Action results in changing many infons
Basic infon set I: (temporary, epistemic) subset of the set of all
infons
• all dual infons of the basic infons
• expansion of all anchored infons into the basic infons
all others: secondary infon
e.g., predicates Patient(Bernhard, Thalheim,...,100352422728),
¬ Village(Dresden,Saxony)
122
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Infon LogicsConstraint relation y ⊆ Infons × SecondaryInfons
generalization/specialization order A 4 B, similarity u
Homogeneity of two infons A∃e B := ∃X(A < X ∧B < X)
Inhomogeneity of two infons
A∃e B := ¬∃X(A < X ∧B < X).
Compatibility of two infons A∃d B := ∃X(X < A ∧X < B)
Incompatibility of two infons
A∃d B := ¬∃X(X < A ∧X < B).
Derived predicates :
divergency g :=∃e ∧
∃d
isolation !:=∃e ∧
∃d
potential homogenizability G:=∃e ∧
∃d ∧ < ∧ 4 and
heterogeneity f :=∃d ∧
∃e .
123
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Properties of Infon Logics
• ⊢ A∃e B ↔ ∃x∀y(x < y → (A < y ∧B < y))
• ⊢ A∃d B ↔ ∃x∀y(x 4 y → (A 4 y ∧B 4 y))
• Product: C = A � B := ∀Y (C < Y ↔ (A < Y ∧B < Y )))
may be: Ax� ⊢ A∃e B → ∃x(x = A � B)
• Sum: C = A�B := ∀Y (C 4 Y ↔ (A 4 Y ∧B 4 Y ))
possibly required Ax� ⊢ A∃d B → ∃x(x = A�B)
also: AxDistrib ⊢ ((A � B)� (A � C) < A � (B � C)) ∧(A� (B � C) < (A � B)� (A � C))
• Negation B = A := ∀x(x < B ↔ x∃d A)
be may add the axiom Ax− ⊢ ∃x(x∃d A) → ∃x(x = A)
• Difference C = A�B := ∀x(C < x↔ (A < x↔ B∃d x))
• Quotient C = A⊘B := ∀x(C < x↔ (A < x ∧B∃d X))
⊢ A⊘B = A� B
124
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Operations of the Infon LogicsProduct C = A � B := ∀Y (C < Y ↔ (A < Y ∧B < Y )))
potentially valid axiom Ax� ⊢ A∃e B → ∃x(x = A � B)
Sum C = A�B := ∀Y (C 4 Y ↔ (A 4 Y ∧B 4 Y )))potentially valid axiom Ax� ⊢ A
∃d B → ∃x(x = A�B)
typical properties: ∀x(⊢ A�B < A � x), idempotency, ...
potentially valid axiom
AxDistrib ⊢ ((A � B)� (A � C) < A � (B � C)) ∧(A� (B � C) < (A � B)� (A � C))
Negation B = A := ∀x(x < B ↔ x∃d A)
(Negation of properties; not subtraction of properties)
potentially valid axiom Ax− ⊢ ∃x(x∃d A) → ∃x(x = A)
if there is a most general infon, then it is not negatable
⊢ (A∃d A) ∧ (A
∃d B ∨ A
∃d B) ∧ (A < ¯A)
General symbol and spezial symbols
Quotient C = A⊘B := ∀x(C < x↔ (A < x ∧B∃d X))
⊢ A⊘B = A� B
Difference C = A�B := ∀x(C < x↔ (A < x↔ B∃d x))
largest infon that is not contained in A enthalten and that is incompatible with B
125
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Extended Infon Calculus�� ��Extended with non-infons
Non-infon for contradictions and empty infon
⊢ ∅∃d ∧ (A
∃d A↔ ∅ u A) ∧ (A
∃d A↔W (A))
⊢ (A < B ∧W (B)→W (A)) ∧ (W (A)→ A < A)
⊢ W (A)↔ ∃x∃y(A < x ∧A < y ∧ x∃d y)
Abstractions at the same layer in general not negatable
Abstractions of higher layers for layering of infon worlds
The laws of the general infon algebra must not be valid!
126
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Infon: Decomposition and HierarchicalBuilding
Compositional collections of infons
Zero infon has no referent
Spare part number 54321 is in slot a-2
This dog with collar belongs to John embeds the zero infon
The dog has a collar, and the non-zero assertion John has a
dog.
Atomic infon has a single referent
Compound infon is an infon that has more than one referent
Reduction property: reducible to a set of atomic infons
A(A1,A2, ...,An) reducible to A(A1),..., A(An) and zero infon:
Infon 1 � Infon 2 � ... � Infon n
127
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Possession and Proprietorship of Infons
Information: infon A that is true
# zero information, atomic information, compound information
private information: atomic (compound) information: that refers
to identifiable individual(s).
Possession of single piece of atomic private information
by many possessors and one proprietor
Not know(to the
individual)
Not knownby other
individuals
Shared with othersby contracts
Knownthrough consent
Public toothers
Known by other individuals
Known by individual
Proprietary infons Possession(infons of
others)
Infons of individuals
128
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
State of Possession of Infons
State of possession Legality of possession
Consent of possession
Awareness of possession
-
6
�
Constraints to the state of possession
Awareness of the individual
Consent of the individual
Greedy deletion of information
Restrictions on visibility of information impact
129
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Agents and Infons
Agents A ∈ Z: individuals V·∪ non-individuals N
Individual: natural person non-individual: artificial person
• Possesses ⊆ Z × PrimaryInfons
Possesses(A100352422729,¬ Village(Dresden,Saxony))
• Knows ⊆ Z × PrimaryInfons
compositional
Knows(A100352422728,Possesses(A100352422729,¬ Village(Dresden,Saxony)))
Knows(A180753308154,
Knows(A100352422728,Possesses(A100352422729,¬ Village(Dresden,Saxony)))) .
• Belongs ⊆ Z × PrimaryInfons
Belongs(AJohn, John developed AIDS )
130
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Collaboration Based on Infon TrackingLocal “databases” bound by collaborating views
db1 db2
v1
v2r∗21(v2)
r∗12(v1)-r∗12
� r∗21
languages Li for representing local infon sets
collaboration transfer relation (or function) rijextended to r∗ij infon setstranslating and representing the ability of j to import i
collaboration space (D, r) (local databases, transfer relations)typed formulas on the collaboration space (i ∈ I, α ∈ Li)
CF ::= i : α | CF → CF | CF ∧ CF | CF ∨ CF |∃i : x.CF | ∀i : x.CF
131
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Collaboration Based on Infon TrackingLocal “databases” bound by collaborating views
Communication of infons among agents
based on lifting and bridge rules expressing the result of communi-
cationi1 : αi, ..., in : αi
i : αapplication condition
with rigidity properties, e.g. Dj only knows foreign infons if this is
supported
Cooperation as common exploration of infons tba
Coordination modelled by the coordination space
collaboration formulas as constraints for the collaboration space
mapped to queries that represent validation conditions
e.g. ∃i : x.(i : q1(x) ∧ x ∈ CoDom(rij(Di)) ∧ ȷ : q2(rij(x)))(shared existence of infons)
132
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Extending PES by Reputation�� ��Fischmann Models
Rights for functionality: owners may not change their data, only
in collaboration with trusted partners for this functionality
Distribution strategy: based on a network with rights to distribu-
tion to others with(out) notification
Reputation models: tribes (subseting), threshold, highest reputa-
tion first
various models for hostility
Explicit request handling: infon demanded by party from party
irequest→ j, infon provided to party from party i
request← j, infon not
delivered to party from party on intention irequest
← j
infon supply to other agents, infon demand by parties
133
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Enhancing Infons by Transaction Number
Infon-TANs (I-TAN)
• Issue a set of transaction numbers to infons
encode
• Similar to DRM2 (digital rights management) of OMA
• Public-key encryption schemata
Combining keys and rights for usage through I-TANs
134
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
The Infon Management Schema forPrivacy Support
Kind ofsharing
� -through⊕
Contract
�
Consent
6
?
-Known byothers
Agent =Non-individual·∪ Individual
?
Individual
�
6
possesses
6
Knownpossession
� Signifies
^
Infon
compound: card = (2,n)atomic: card = (1,1)
zero: card = (0,0)
�
6
applies
Privacyclassification
schema
Information
]
true
6
Trivialinformation
derivable
135
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Open Problems: Structuring
(S1) Conceptual modelling in the large: as extension of con-
ceptual modelling in the small
(S2) List semantics for (extended) entity-relationship modelling:
with mapping to list-based languages
(S3) Center-periphery integration into schemata: beyond
overlay techniques
(S4) Level of locality and globality: Structures with the best
globality
(S5) Null marker logics: beyond the existence, non-applicability
and unknown
(S6) Pattern of structures: beyond the small patterns of Blaha
(S7) Redundant schemata: with redundant types, explicit main-
tenance
136
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Open Problems: Functionality
(F1) (e)ER-SQL: beyond VisualSQL with integration of NoSQL
features
(F2) Holistic functionality description: from application do-
main to business processes to conceptual functionality specification
(F3) Dynamic semantics: beyond transition rules that reflect sta-
tic semantics
(F4) Robust workflows: against errors, failures
(F5) Flexible workflows: with controllable deviations from flow
and coherent finalisation
(F6) Information systems functions: beyond retrieval and state
change operations
(F7) Generic views: similar to generic functions
137
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Open Problems: Distribution
(D1) Partial consistency of databases: with specific contracts,
protocols
(D2) Recharging of partner databases: depending on subscrip-
tion mode
(D3) Coordination: beyond contracts, towards controlled coordi-
nation
(D4) General model of services: service as specific software,
with support, with compliance
(D5) Exchange frames: similar to protocol engineering, depending
on chosen architecture
(D6) Component database systems: with specific coupling faci-
lities, collaboration contracts
(D7) Pattern of distributed systems: for specific integration
138
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Open Problems: Interactivity
(I1) Edutainment stories: beyond classical blended learning, to-
wards collaboration and true interaction
(I2) New stories: in the app age, based on mini-stories, arbitrarily
combinable, with data coherence
(I3) Screenography: as generalisation of scenography and drama-
turgy, systematic development of screens, adaptation to the user
(I4) Life case backery: with continuous adaptation
(I5) I∗-generalisation: from (Soft)Goals ∪ Tasks ∪ Actors ∪ Re-
sources to the story space, obligations, life cases
(I6) Privacy of users: privacy profile, controlled opening of shared
data, flexible protection
(I7) Workspace integration of users: users with the wor-
krooms, workspace, libraries
139
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Open Problems: Co-Design
(C1) Coherence of models: Coherence conditions and associati-
ons within a model suite
(C2) Compiler-based transformation of conceptual schemata:
beyond the interpretation or rule-based approach
(C3) Semantics treatment: depending on kind of constraints, sets
of constraints
(C4) Global-as-view schemata: opposite to classical local-as-
view 2/3-layer architectures
(C5) Object-relational design: starting with an OR-schema
(e.g., HERM-schema) and ending with a object-relational schema
of modern DBMS
(C6) Content services: beyond information services
(C7) Faithful mapping from and to UML: beyond brute-force
interpretation
140
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Practicality of the Co-Design Approach
Our Experience
• Internet and cable net information-intensive services
• Cottbusnet and 35 other website projects
Codesign of structuring, functionality, and interactivity
Content-on-interest + Content-on-profile-and-portfolio + Delivery-on-context !!! +
Adaptation-on-context !!!
• Intelligent personalized internet in set-top-box-based TV
Codesign of structuring, functionality, distribution and interactivity
TV/Radio-on-interest + Cinema-on-demand + Internet-on-profile + Internal-
communication-among-users
• Conceptual modeling for story spaces and story boards for services
Experience Gained by Partners
• Co-Design of structuring and functionality by Turkey System Inc.
more than 1.500 applications
• Re-Design of SAP R/3
Co-Design of structuring and functionality
141
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Summarizing
• Component-based development leads to engineering instead of han-
dicraft
• Star and snowflake types are the main building blocks
star = entity or relationship type with associated element types
and their specializations
snowflake = star type extended by variations of strongly
1-n-associated star types in a potentially acyclic structuring
• Main composition methods: parallel and interleaved construction
• Dimensionality inside schemes: facet, views, viewpoints, applicati-
ons,
lifespan of objects
orthogonal parts: specialization, association, usage, lifespace, qua-
lity
• Bottom-up construction is misleading: better use construction by
concepts, things (objects), idioms, building blocks
object-orientation wanted to repair it but forgot about this
142
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Forecasting
• Efficiency of the approach: not as efficient as handicraft,
but less error-prone, less work around, better documentation
pays back during maintenance, migration and integration
• Codesign of structuring and functionality based on the approach of
the higher-order entity-relationship model
• Component ware will be available in a couple of years as plug-and-
play blocks with well-defined structuring, functionality
and interactivity
but before applying it: standardization
• Components beyond object-orientation: interaction among objects
is considered instead of classes
simpler treatment of synchronization policies,
coordination abstraction, wrappers, mixins
143
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Publications on Co-Design• Dusterhoft, A., Thalheim, B.: SiteLang: Conceptual Modelling of Internet Sites. Proc. ER’2001, LNCS 2224,
179 - 192. Application to webservices
• Feyer, Th.; Thalheim, B.: E/R Based Scenario Modelling for Rapid Prototyping of Web Information Services.
Proc. WWWCM’99, 253 - 263. Application to webservices generation
• G. Fiedler, H. Jaakkola, T. Makinen, B. Thalheim, and T. Varkoi. Co-design of web information systems
supported by SPICE. Information Modelling and Knowledge Bases, XX:123–138, 2009.
• Goldin, D., Srinivasa, S., Thalheim, B.: IS=DBS + Interaction: Towards principles of information system
design. Proc. ER 2000, LNCS 1920, 140 - 153. The theoretical foundation
• Klettke, M.: Reuse of database design decisions. Proc. REIS’2000, LNCS 1727, 213-224. Reuse structures
and intelligently acquire integrity constraints
• Lewerenz, J., Schewe, K.-D., Thalheim, B.: Modelling data warehouses and OLAP applications by means of
dialogue objects. Proc. ER’1999, LNCS 1728, 354-368. OLAP in a consistent, powerful and simple way
• K.-D. Schewe and B. Thalheim. The co-design approach to web information systems development. International
Journal of Web Information Systems, 1(1):5–14, March 2005.
• Schewe, K.-D.; Thalheim, B.: Towards a theory of consistency enforcement. Acta Informatica, 36, 1999, 97-141.
Instead of falling into the traps of rule triggering systems
• Steeg, M; Thalheim, B.: Conceptual Database Application Tuning. Proc. SCI’2000, 226-231. Tune instead of
normalize
• Thalheim, B.: Entity-Relationship Modelling - Foundations of Database Technology. Springer, Berlin, 2000.
The HERM “bible”
• Thalheim, B.: Logics and Database Modelling. Proc. ICLP ‘99, MIT Press, 6-21. The relationship to logics
• Thalheim, B.: Codesign of database systems and interaction - Thin and consistent UML. Proc. OTS’2000,
1-17. Codesign - the ultimate basis for best practices UML
144
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Publications on Model Suites, Evolution,Migration
• A. Dahanayake and B. Thalheim. Co-evolution of (information) system models. In EMMSAD
2010, volume 50 of LNBIP, 314–326. Springer, 2010.
• A. Dahanayake and B. Thalheim. Towards a framework for emergent modeling. In ER Work-
shops, volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.
• M. Klettke and B. Thalheim. Evolution and migration of information systems. In The Handbook
of Conceptual Modeling: Its Usage and Its Challenges, chapter 12, 381–420. Springer, Berlin,
2011.
• B. Neumayr and M. Schrefl und B. Thalheim. Modeling techniques for multi-level abstraction.
In The Evolution of Conceptual Modeling, volume 6520 of Lecture Notes in Computer Science,
68–92, Berlin, 2011. Springer.
• B. Thalheim. Model suites. In H. Jaakkola, editor, Selected Topics on Distributed Disaster
Management: Towards Collaborative Knowledge Clusters., 108 – 128. Tampere University Press,
Porin yksikko, 2008.
• B. Thalheim. The conceptual framework to multi-layered database modelling. In Proc. EJC,
118–138, Maribor, Slovenia, 2009.
• B. Thalheim. Model suites for multi-layered database modelling. In Information Modelling
and Knowledge Bases XXI, volume 206 of Frontiers in Artificial Intelligence and Applications,
116–134. IOS Press, 2010.
145
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Publications on Exceptions and Quality
• A. Berztiss and B. Thalheim. Exceptions in information systems. In Digital Libaries: Advanced
Methods and Technologies, RCDL 2007, pages 284–295, 2007.
see also:
A. Berztiss and B. Thalheim. Exceptions in information systems. Technical report, Department
of Computer Science, Kiel University, 2007.
• H. Jaakkola and B. Thalheim. Software quality and life cycles. In ADBIS’05, pages 208– 220,
Tallinn, September 2005. Springer.
• H. Jaakkola and B. Thalheim. A framework for high quality software design and development:
A systematic approach. IET Software, pages 105–118, April 2010.
• H. Jaakkola and B. Thalheim. Exception-aware (information) systems. In Information Modelling
and Knowledge Bases, volume XXIV, pages 300–313. IOS Press, 2013.
146
InformationSystemsCo-Design
19.8.2013
B. Thalheim
Co-Design?Abstraction Layer
Methodology
Model Suite
Exceptions
Privacy
Open Problems
Finally
References
Concept Topic
Content
Information
Publications on Engineering• A. Binemann-Zdanowicz. Towards generative engineering of content-intensive applications. In
Proc. Principles of Software Engineering Conference (PRISE 2004), pages 41–49, 2004.
• A. Dahanayake and B. Thalheim. Continuous database engineering. Int. Journal Business Inf.
Syst. (IJBIS), 13(2):133–150, 2013.
• K.-D. Schewe and B. Thalheim. Component-driven engineering of database applications. In Mar-
kus Stumptner, Sven Hartmann, and Yasushi Kiyoki, editors, Third Asia-Pacific Conference on
Conceptual Modelling (APCCM2006), volume 53 of CRPIT, pages 105–114, Hobart, Australia,
2006. ACS.
• P. Schmidt and B. Thalheim. Towards ASM engineering and modelling. In Proc. ASM07, pages
191–210, 2007.
• B. Thalheim. Towards component engineering for large database applications. In CAiSE ’03,
CEUR Workshop, number 74, pages 217 – 220, 2003.
• B. Thalheim. Conceptual modeling in information systems engineering. In J.Krogstie and
A. Lothe, editors, Challenges to Conceptual Modelling, pages 59–74, Berlin, 2007. Springer.
• B. Thalheim. Engineering database component ware. In TEAA’06 post proceedings, LNCS
4473, pages 1–15, Berlin, 2007. Springer.
147