MITK Tutorial Theory Session Modularity.pptx...

5/31/2016

MITK Tutorial

Theory Session

Caspar Goch & Stefan Kislinskiy

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

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

5/31/2016 | MITK Modules

MITK modules are used for

• Filtering, Algorithms

• Data structures

• Visualization

• Simple GUI elements

• Anything without an application context

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

)

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

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


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.


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

5/31/2016 | MITK Use Case

• Hardware devices modeled as services, e.g.

• Range cameras

• Optical trackers

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

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

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

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

5/31/2016 | Command Line Modules View

CTK Plugin Framework

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

5/31/2016 | Plugin Framework

� Dynamic Plugin Framework

(based on OSGi)

� Enables service oriented

architectures

� CTK provides basic plugins

for distributed/large-scale

applications

5/31/2016 | Plugin Structure

Meta information

Third-party

dependencies

Unique name

5/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>)

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

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

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

5/31/2016 | plugin structure

Meta information

Exported code

Internal code

Extension points

Unique name

5/31/2016 | Define extensions

plugin.xml

http://docs.mitk.org/nightly/BlueBerryExtPointsIndex.html

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

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

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

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

5/31/2016 | What to add ?

• List of all modules & brief description?

Additional Slides


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

5/31/2016 | OSGi Specifications

� OSGi Core Specifications

are small

� OSGi Service

Compendium defines

many optional services:


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!

MITK Tutorial Theory Session Modularity.pptx...

Documents

Transcript of MITK Tutorial Theory Session Modularity.pptx...