mitk tutorial theory session modularity.pptx...
TRANSCRIPT
5/31/2016
MITK Tutorial
Theory Session
Caspar Goch & Stefan Kislinskiy
Page 25/31/2016 | Why Modularity?
Interaction between different system developed by different
people. Especially external users.
Increased Maintainability.
High personel fluctuation requires short training phases.
vs
Page 35/31/2016 | MITK/Blueberry Modularity concepts
• Modules
• Micro Services
• cmdapps
• Plugins
• Views
• Perspectives
• Applications
MITK CoreMITK Core
Diffusion
Imaging
Diffusion
Imaging
Image-Guided
Therapy
Image-Guided
TherapySimulationSimulation QmitkQmitk
OpenCVOpenCV
QtQt CTKCTKITKITK VTKVTK
Custom
Applications
Custom
Applications
MITK PluginsMITK Plugins
MITK WorkbenchMITK Workbench
BoostBoost
MITK Modules
Page 55/31/2016 | MITK Modules
MITK modules are used for
• Filtering, Algorithms
• Data structures
• Visualization
• Simple GUI elements
• Anything without an application context
Page 65/31/2016 | MITK Modules
� Shared libraries
� MITK CMake macros for easy
creation and orchestration
� Automatic dependency
checking and error reporting
MITK_CREATE_MODULE(
DEPENDS MitkImageExtraction MitkPlanarFigure
PACKAGE_DEPENDS
PUBLIC ITK|ITKIOXML
PRIVATE ITK|ITKVTK+ITKConvolution
WARNINGS_AS_ERRORS
)
Page 75/31/2016 | From Modules To Micro Services
Typical problems in large systems:
• Tight coupling
• Many cross-module dependencies
The MITK Micro Services system provides
• Simple module layer – Enumerate, listen and query MITK modules
• Service layer – services (C++ objects) can be published, queried, and retrieved dynamically.
Service-oriented architecture for MITK
Page 85/31/2016 | C++ Micro Services
Services are
• Functional units of work
• A contract between the service provider and its
consumers
A service-oriented approach promotes
• Less coupling between modules
• Higher reuse of components
• More emphasis on interfaces
• Clear description of dependencies
• Support for multiple competing implementations
Page 95/31/2016 | C++ Micro Services
MITK modules can publish services and bind services from
other modules:
Service
description
Service
consumer
Service
provider
Service
registry
Interact
FindPublish
API is very close to the OSGi Service Layer specs.
Page 105/31/2016 | C++ Micro Services
MITK uses micro services to
• simplify its API
• decouple shared libraries
• provide extensibility at runtime
Use cases:
• Singletons and “manager objects” (avoid static
(de)initialization fiascos)
• Hardware devices modeled as service objects
• I/O classes
• Interaction observer
Page 115/31/2016 | MITK Use Case
• Hardware devices modeled as services, e.g.
• Range cameras
• Optical trackers
Page 125/31/2016 | MITK Usage
• Every module has a ModuleContext object
• Conversion of singletons to services
• Increased cohesion by embedding resources
• Decreased coupling
• Auto-loading of libraries providing service implementations
• Provide extensibility at runtime
Command Line Interface
MyProgram --xml
Page 145/31/2016 | MITK Command Line Apps
The MITK command line apps concept is used for
• Providing command line access to algorithms
• Automated uniform processing
• Incorporating 3rd party executables in a workflow via
scripts
Page 155/31/2016 | Command Line Interface
• Integration of (legacy) stand-
alone command line programs
• Executables must provide an
XML file describing the
command line parameters
• Allows (limited) communication
via standard input/output
channels
Examples
• ITK based registration programs
• Compiled Matlab code
• Slicer CLI modules
Page 165/31/2016 | Command Line Interface
• Automatic GUI
generation based on
the XML description
• Command line module
explorer in CTK
• MITK integration via
org.mitk.gui.qt.cmdline
modules
Page 175/31/2016 | Command Line Modules View
CTK Plugin Framework
Page 195/31/2016 | MITK/CTK Plugins
The MITK/CTK plugins provide and bundle
• Complex UI elements for specific tasks (Views)
• Associated resources and documentation
• Application/User – Module communication
Page 205/31/2016 | Plugin Framework
� Dynamic Plugin Framework
(based on OSGi)
� Enables service oriented
architectures
� CTK provides basic plugins
for distributed/large-scale
applications
Page 215/31/2016 | Plugin Structure
Meta information
Third-party
dependencies
Unique name
Page 225/31/2016 | OSGi meta information
manifest_headers.cmake
set(Plugin-Name "A human readable plugin name")
set(Plugin-Version "x.x.x")
set(Plugin-Vendor "A human readable vendor name")
set(Plugin-ContactAddress “Web page, email, etc.")
set(Require-Plugin <list-of-plugin-symbolic-names>)
Page 235/31/2016 | Views
A view:
• Provides a GUI solution for a specific workflow, such as measuring
things within an image or doing statistics on an image
• Should not be too complex, the idea is to support, not confuse the
user
• Usually bundled with similarly themed views in one plugin
• Should only connect the GUI and the underlying algorithms, as little
own logic as possible
Page 245/31/2016 | Perspectives
• Layout of views for specific use cases
• Default can be defined
• Changes by the user are remembered, allowing customization
BlueBerry
Application level modularization
Page 265/31/2016 | CTK and BlueBerry
BlueBerry
• Application framework based on CTK plugins
• Design and extensibility inspired by the Eclipse RCP
Features
• Similar to the Eclipse RCP in C++
• Based on the CTK plugin model
• Lazy loading of plugins for scalability
• Flexible extension mechansims
• General purpose plugins for extensible applications
Page 275/31/2016 | plugin structure
Meta information
Exported code
Internal code
Extension points
Unique name
Page 285/31/2016 | Define extensions
plugin.xml
http://docs.mitk.org/nightly/BlueBerryExtPointsIndex.html
Page 295/31/2016 | Modules, plugins, etc.
Module
• Is a C++ library (shared or
static)
• May depend on other
modules
• Contains re-usable widgets,
algorithms, etc.
• Is loaded due to linker
dependencies
Plugin
• Is a C++ shared library
• Depends on CTK, may depend
on other plugins and modules
• Usually contains UI
contributions to the MITK
Workbench
• Is loaded lazily on demand or
due to linker dependencies
• Needs a running framework
Usage Guidelines
Page 315/31/2016 | Algorithm Development
Algorithmic code should
• Be contained in MITK modules
• Have a public (minimal) API
• Depend on ITK only if it is an ITK filter / process object / etc.
• Make no use of micro services (published or consumed)
• Be parameterized and configured via its public API
Page 325/31/2016 | Application Support Code
Non-algorithmic code like
• IO classes
• Configuration / manager classes
• GUI widgets
• Domain-specific support code (IGT, Diffusion, US, ...)
should be
• Organized into one or more MITK modules
• Consume and / or publish micro services if appropriate
Page 335/31/2016 | Application plugins
Contributions to a MITK Application like
• Views and Editors
• Context menu entries
• Workbench customizations
should
• Be realized as CTK plugins
• Re-use functionality from MITK modules
• Re-use functionality from other plugins
Page 345/31/2016 | What to add ?
• List of all modules & brief description?
Additional Slides
Page 365/31/2016 | Plugin Framework
Relation to MITK micro services (CppMicroServices)
• Similar concepts and API
• Qt based
• Dynamic plugins (modules)
• Persistent plugin cache
Micro services are published as CTK services
Page 375/31/2016 | OSGi Specifications
� OSGi Core Specifications
are small
� OSGi Service
Compendium defines
many optional services:
Page 385/31/2016 | Plugin Framework
Implemented OSGi specifications in CTK
� Log Service Specification
Provides a general purpose message logger.
� Metatype Service Specification
Provides a unified way to describe metadata about services.
� Configuration Admin Service Specification
Allows to set the configuration information of deployed
plugins.
� Event Admin Service Specification
Inter-plugin communication mechanism based on a event
publish and subscribe model.
Further
information
on www.dkfz.de
Thank you for
your attention!