Transcript SW Eng in Forestry

NEFIS Working Package 3
UML for Forest Information Systems
Development
Identifying the Architectural Framework
Alex Fedorec,
Moh Ibrahim, Keith Rennolls, Tim Richards
Introduction
• Brief review of issues of UML and
information systems engineering
• Identification of generic use cases and
implications to system requirements
• Technical options, architectural framework
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.2
The Use of UML in Forest Information
Systems Development
• UML – The Unified Modelling Language
• Extensible graphical language for modelling structure and
behaviour of many types of systems; e.g. business systems,
information systems architecture, etc.
• syntax & semantics; vocabulary & grammar
• necessary but insufficient by itself; (Shakespeare, DaVinci)
• Real value to NEFIS is analysis of requirements and
identification of architectural framework to support the
pan-European and global levels.
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.3
Software Quality Issues
Usability:
Understandability, learnability, operability
Functionality: Suitability, accuracy, interoperability,
compliance and security
Efficiency:
Time, resources
Reliability:
Maturity, fault tolerance, recoverability
Maintainability: Analysability, changeability, stability,
testability
Portability:
A.M.Fedorec 7/7/2015 1:50 PM
Adaptability, replaceability, conformance,
installability
JRC ISPRA 0605.4
Some Architectural Issues
Range of forest information is vast, complex,
heterogeneous and constantly changing.
• How and where is the information held?
• Where is it processed and how?
• How are the resources shared and distributed?
The real issue:
Why would someone want to use this system?
• Resource user?
• Information provider?
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.5
Design Premises
Must support not constrain users
• “Minimum impact on current business practices”
• Improve efficiency, reduce duplication of effort
• Reduce redundancy and duplication of data
• Single-source each information element,
ownership of information
• Add value and confidence to information
• Support version control
• Address problems of semantic interoperability
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.6
Use Case Analysis
Contemporary software engineering is driven by
identifying the users of a system (“actors”) and
meeting their needs, expectations and requirements.
i.e. providing positive benefit to them (“Use Cases”).
vocabulary
functionality
system assembly
configuration mgt
Implementation
View
Design View
Use Case
View
behaviour
Deployment
View
Process View
performance
scalability
throughput
logical
physical
system topology
distribution
delivery
installation
Kruchten, P.B., The 4+1 View Model of Architecture, IEEE Software, Nov 1995, pp. 42-50
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.7
User Needs
Conventions/Legal reporting requirements
• Facilitate decisions taken at national and regional levels
concerning the forestry sector
• Analyse in detail the statistical sources of forest resources
• “Objective comparable data based on pan-European criteria”
• e.g. Inventories, pollution & fire monitoring, carbon…
Other
• Silviculture, timber industry
• Sustainable management
• Environmental aspects, biodiversity
• Educational and research interests
Future-proofing for data archaeologists
• Unanticipatable
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.8
Therefore Actors Potentially Include
• EU pan-European/national governmental agencies
• NGOs trans-national environments and
conservationists
• National/regional/local land use planners
• Regional/local forest managers, silviculturalists
• Commercial forest/timber industry
• Forest and environmental researchers and modellers
• Educational users: schools, colleges & universities
• Individual personal users: business or recreation
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.9
Actor Identification
NEFIS: Huge range of actual and potential users and applications
Unrealistic to map them all therefore actors grouped into four classes
Use
content
Collective
Individual
Expression
Level
Systems
perspective
Dialogue
Partner
Contents level
Media
perspective
Tool
perspective
Source of design
principle
Kammersgaard, J., Perspectives on Human-Computer Interaction,
In Human-Computer Interaction, J. Preece & L. Keller (eds.), Prentice-Hall, 1990
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.10
Four Classes of NEFIS Actor
System Perspective
• User is little more than cog in the machine
(e.g. raw forest information data entry & form filling - TP)
Media Perspective
• System is media for communication, (e.g. publication of press releases,
educational resources, computer based conferencing…, - MM)
Tool Perspective
• System provides set of tools and facilities for expert use (e.g. raw datasets,
model archives, analysis tools to support forest researcher, - EDA)
Dialogue Partner
• System and user are regarded as partners in a dialogue communicating to get
some task performed
• Initially the quickest significant benefits may be gained by addressing the
needs of this group of user.
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.11
NEFIS Dialogue Partner Use Cases
Sample use cases elicited (see D9 report appendix)
• UN-ECE/FAO Global Forest Resource Assessment
& TBFRA 2000 (Regional FRA)
• MCPFE Criteria & Indicators for Sustainable Forest
Management
• Forest Products Production and Trade Flows
• Land Use & Land Cover Change for UNFCCC
Commonalities factored to identify generic use cases
and form extensible system kernel
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.12
Example Use Case 1
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.13
Example Use Case 2
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.14
Example TBFRA Use Case After Discussion
Identifying System Boundaries
NEFIS
Harmonise
Provide Country
Data
«uses»
Aggragate Country
Data
«uses»
«uses»
Get inventory
information
«uses»
«uses»
«extends»
Standardise
Corespondant
Locate Resource
Includes
validation
Timber Specialist
Committee Meeting
convene
Publish TBRA Report
Provide Attrribute
Definitions
«uses»
FAO Coordinator: KP
Timber Committee Chair : MK
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.15
Generic Dialogue Partner Process
Depending on role/task:
• Work to set of guidelines, conventions, standards, directives
• Identify required information (e.g. MCPFE criteria and indicators)
• For each information element (cf. datamining ELT - extract, transform, load)
• Locate source, request and retrieve dataset
• Validate dataset
• Apply transform (e.g. change format, standardise..)
• Collate and Aggregate datasets
• Apply transform to aggregate (e.g. change model, statistical analysis)
• Format for publication (e.g. tabularise, graphic representation, etc.)
• Publish result
• Make available to others (e.g. write to document, web, database, etc.)
• Iterate steps as required
• Often tens of iterations – needs automation support
Note published result of one task becomes input dataset for another.
e.g. National Inventory → JQ report → Eurostat DB → FRA → MCPFE Report
“One person’s output is another person’s input”
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.16
NEFIS Generic Use Case
NEFIS System
Support Kernel
«uses»
Resource,
Document &
Content
Management
Check guidelines
«uses»
«uses»
«extends»
Validation is done off-line
System simply provides
contact and comms support
Validate Dataset
«uses»
«extends»
publish source
information
locate and
retrieve dataset
Get agregate
dataset
«uses»
«uses»
«extends»
Transform dataset
«uses»
MetaData Registry
and Repository
Mgt System
Top Package::client
Analyse, visualise,
transform aggregate
«uses»
Top Package::Provider
Application
Tool
Repository
«extends»
Metadata Mgt
Subscriber
Regististration
«uses»
«extends»
Browse Forest
Information
A.M.Fedorec 7/7/2015 1:50 PM
Subscriber
workflow,
task & role
management
«extends»
Task & Role
Management
«uses»
Top Package::NEFIS admin
Portal Management
JRC ISPRA 0605.17
Core Subsystems
• Resource and content management
• Metadata management
• Tool & component repository
• Task and Role support
Elements integrated by service management
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.18
Resource and Content Management
• Asset management
• Change and version control
• Configuration management
• Control content assets used to dynamically
create and deliver web presence
• Resource description, discovery and integration
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.19
Task & Role Support
• Enables subscriber access & authorisation control
• Supports data rights management
• Identification of datasets of interest
• Standardisation of document / form templates
• Potentiates workflow management
• Choreograph and automate repeated processes
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.20
Tool Repository
Domain specific tools for users:
• Resource publication
• Standardisation and harmonisation
• Data analysis and modelling
• Visualisation
• Task support
Standard components for developers
• EFIS API (e.g. FML parsers, metadata selectors)
• Architecture adaptors (e.g. XML to CSV…)
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.21
Metadata as the Glue
Exploitation of highly cohesive, lowly coupled
components on distributed heterogeneous system
requires common interchange language and
middleware with agreed terms, e.g. wrapping
data and messages in XML/SOAP envelopes.
This can only be done with an extensible
controlled vocabulary.
Requires
• vocabulary/namespace management
• metadata database
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.22
NEFIS Metadata Software Issues
• Metadata is not just needed for resource discovery or informed decision
support but to ensure semantic interoperability (agent dialogue)
• Leverage existing Dublin Core, DCMI & EEA reference tools and facilities
• NEFIS extensions: quality, terms (keywords) grouped by themes
• Control of NEFIS extensions:
• management of nominated terms
• promotion of nominated term to controlled vocabulary
• Terms can have synonyms, homonyms, natural language translations etc.
implying need for thesaurus as well as dictionary
• Terms and themes have many-to-many and recursive relations implying need
for an ontology database (n.b. thesaurus drops out of ontology)
• Nature of relations and management of complexity implies need for
negotiated contextual tuning of semantic distance
• Granularity: tagging files or fields?
“One person’s data is another person’s metadata”
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.23
NEFIS Forest Metadata Management Use Cases
Nominate Term
Manage Controlled
Vocabulary
«extends»
«extends»
NEFIS Editorial
Advisory Group
Produce Authority
Lists
co-ordinate with
Maintain Forest
Term Ontology
NEFIS User
«includes»
«includes»
Multilingual Forestry
Ontology Project
Search Terms
Select Term
«includes»
Locate or publish
a resource
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.24
Forest Metadata Overview
Metadata Management
Standard Core
Dublin Core
DCMI
EEA Ref set
Controlled Vocabulary
NEFIS Theme
theme
definition
*
*
Vocabulary
Manager
Nominated
Vocabulary
Database
Term
Nomination
Term Dictionary
Collect
Validate
Organise
Modify
Delete
language
*
Term
subject
term
object
relation
Term Description
Plural forms and Variants*
Classification
Abbreviations
Notes
Standard
Reference
List
A.M.Fedorec 7/7/2015 1:50 PM
Ontology DB
External Ref
URI
Official
Classification
Scheme
JRC ISPRA 0605.25
Identifying the Architecture
• Logical Architecture
• Addressing separation of concerns
• e.g. layered 3-tier:
• Data management layer
• Application processing layer
• Presentation Layer
• Physical Architecture
• Where do components reside?
• What is the deployment?
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.26
Architectural Premises
Because of potential range of applications, growth etc.:
Must support incremental development
• Facilitate reuse
• Extensibility
• Scalability
• Futureproofing
Must support pluggable components
Use of existing frameworks, components etc
• Open systems, open source…
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.27
Example Logical Architecture
The ECMA Reference Architecture
Data repository services
Data integration services
Tool
slots
Task management services
User interface services
Message
services
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.28
Architectural Layers & Protocols
Node 1
Node 2
Node 1 & Node 2 heterogeneous
Each layer has a protocol
4 layers in this case
= 4 levels of interoperability
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.29
Centralised Warehousing of Data or Not?
• Huge volumes of un-normalised data but
standardisation or harmonisation on each query will
result in much degraded performance
• Should ‘cleaned’ data be held centrally?
• Major principle – ownership of information:
the producer / publisher of the data should maintain
control and ownership.
• Web-service technology now supports federated
(distributed) warehousing whilst maintaining local
ownership of data.
“Ownership of information carries with it certain responsibilities”
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.30
Potential Physical Architectures
• Repository Model
• Shared data held in central database
• Subsystems maintain own information
• Client-Server Model
• Set of servers offer services to other sub-systems
• Set of clients call on services offered by servers
• Thin clients – application processing carried out on server,
client responsible for presentation layer
• Fat client – server only responsible for data management
• Network to support client access to services
• Distributed Object Architectures
• System components are objects that provide an interface to set of
services they provide
• Removes distinction between client (receiver of services) and server
(provider of services)
• Objects distributed on a network and communicate through middleware
(request broker)
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.31
Use Case Simplification
Simplification of generic use-case implies “Publish-Subscribe” pattern
Use
Service
«includes»
Locate
Service
«extends»
Client
notify
Publish
Service
Service
Provider
Pattern ideally addressed with ‘Service Oriented Architecture’
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.32
Service-Oriented Architecture
Directory
Publish
Locate
Service
Client
Bind and Communicate
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.33
Service Oriented Architectures
•
•
•
•
Were novel at beginning of NEFIS project
Identified and discussed in WP3 technical review
Since become key enabler of large-scale enterprise systems
Addresses issues of
•
•
•
•
application integration and interoperability (inc. legacy systems)
business process integration and workflow
system transparency (access, location, scalability…)
openness, extensibility…
• Potentiates
• federated warehousing
• grid services
• n.b. W3 consortium initiative to converge WS and grids
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.34
Web Service Architecture
Includes core design components of the Web:
• Identification of resources,
• Representation of resource state, and
• Protocols that support the interaction between
agents and resources in the space [protocol-based
interoperability]
NEFIS architecture should reuse these at all levels
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.35
Service Directory Class Diagram
Application
Publisher
Directory
+publish:void
+delete:void
+locate:ServiceInformation
+register:void
+update:void
ServiceInformation
Refers To…
ServiceImplementation
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.36
Collaborations between Directory Components
aPublisher:
Publisher
anApp:
Application
theDirectory:
Directory
1: «constructor»
service:
ServiceImplementationPublisher
info:
ServiceInformation
2: publish(info):void
3: locate():ServiceInformation
3.1: getInformation(info):void
4: createArchitectureAdapter(info):void
5: operation(): void
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.37
The Publish/Subscribe Pattern Cont’d
aPublisher:
PublisherImpl
Client
1: «constructor»
anEventService:
EventServiceImpl
aSubscriber:
SubscriberImpl
2: addSubscriber(String, String): void
3: publish(String, String): void
3.1: *[foreach(registeredSubscriber)] update(String, String):void
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.38
Publish/Subscribe Deployment Using Web Services
UDDI
Directory
EventService Subscriber
Web
Application
Subscribing Web
Application
EventServiceImpl
SubscriberImpl
Publishing
Application Node
PublisherImpl
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.39
NEFIS Deployment Principles
• Distributed model
• Publisher maintains ownership and control
of published information on own node.
• Visualisation, analysis and other processing
of information done on client node.
• Server provides service discovery, tool
repository, gateway services etc.
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.40
NEFIS Deployment Cont’d
«WWW»
CLIENT
*
«internet»
Analysis &
Reporting Toolkit
Visualisation
Toolkit
*
Metadata DB
«intranet»
Tool repository
PROVIDER SERVER
*
Resource Locator &
Vortal Services
Access & Authorisation Mgt
Resource Browser
NEFIS SERVER
Task & Role
Management.
Content
Management
Metadata
Management
«internet»
Publication Tools
Harmonisation
Tools
Published Services
«intranet»
Provider Systems
Raw databases
and Information
Central
resource DB
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.41
Summary
Problem: vast and expanding volumes of information, heterogeneous, highly
changeable, huge range of potential user types and applications.
• Single monolithic system and ‘Big-bang’ development will fail
• Must be an evolving collaboration of communicating systems
Recommend focus on key elements:
• Metadata management: Not just resource discovery - Normalisation and
control of metadata database required to ensure semantic interoperability
• Content management central to dynamic control and delivery
• Task and role support will enormously facilitate and enhance usability
• Maintenance of tool and standard component repository essential
• Success will be predicated on high quality publish & subscribe tools
Also recommend employ iterative development
• Based on well partitioned scalable architecture
• employing component oriented implementation
• in an extensible service-oriented framework
• exploit current extensive portable web & open-systems technologies
Finally note web-service and grid technologies converging to address future concerns
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.42
Questions?
A.M.Fedorec 7/7/2015 1:50 PM
JRC ISPRA 0605.43