Orthographic Software Modeling – A Practical ...

4 downloads 444 Views 937KB Size Report
Oct 7, 2009 - Modern Software Engineering Paradigms. Ë Model-driven Software Development (MDSD). H Levels of abstraction. Ë Component (service) ...
Orthographic Software Modeling – A Practical Approach to View Based Development Colin Atkinson University of Mannheim Germany

MSI 2009 7th October 2009 Oldenburg

Outline Ë

Modern software engineering paradigms

Ë

Review of KobrA

Ë

Orthographic Software Modeling H

View-based software engineering

H

Dynamic view generation

H

Dimension Based Navigation

Ë

Case study

Ë

Conclusion

Modern Software Engineering Paradigms Ë

Model-driven Software Development (MDSD) H

Ë

Component (service) - based Development (CBD) H

Ë

Product families

Other Paradigms H

Ë

Composition hierarchy

Product-line Engineering (PLE) H

Ë

Levels of abstraction

Aspect-oriented

Using those Paradigms H

lots of different views

H

different notations

Observations Ë

New software engineering paradigms dramatically increase number of views H

traditional source code is also “just a view”

Ë

“Enterprise Architecture” adds more information and more views

Ë

Executability is only one property of a system. Others include –

Ë

H

Checkability

H

Predictablity

H

Testability

To support these effectively we need … H

Inherently View-oriented Methods

H

Dynamic View Generation

H

Dimension Based Navigation

Orthographic Software System Service Modeling

Basic Philosophy of the Proposed IDE Ë

Support for multi-views H

Ë

Views as Projections H

Ë

Multiple inter-related diagrams and representations

Should be as “orthogonal” as possible

Multi-Dimensional Navigation Space H

Every view exists at a particular set of coordinates

Ë

Flexible infrastructure that can be extended with new tools and views

Ë

Single underlying representation of the software system

Component Views in KobrA Specification

Behavioral View (UML statechart diagram)

Operational View (operation specifications)

Behavioural View (UML activity diagrams)

Business Component

Operational View (UML collaboration communication diagrams)

Structural View (UML class/object diagrams)

Structural View (UML class/object diagrams)

Realization

Modeling Principles Uniformity Ë all behavior rich elements should be viewed as components, including (sub)systems Ë component assembly = component development Parsimony Ë minimal set of concepts (no redundancy) Locality Ë all models should be local to a component Encapsulation Ë component specifications (what) must be separated from component realizations (how)

Component Nesting in KobrA UML-based modeling of nested components attempts to reconcile MDD, CBD and PLE key ideas Ë

Three fundamental development dimensions

Ë

three fundamental viewpoints

Ë

strict separation of black box and white box views

key benefits Ë

full power of UML available to model components

Ë

OCL available for formality and precision

Separation of Development Dimensions Abstraction (MDA)

Genericity (PLE)

Application Composition (CBD)

Framework instantiation decomposition refinement

9

View-Based Modeling Frameworks – Current Status CD XMI OpSpec

test cases code

RegEx software component

Java source

UML classes

Behavior

Goal – On-Demand View Generation

Java source

UML classes

Behavior

A Simple View-Based "Modeling" Metaphor Ë

other engineering disciplines have a long and successful tradition of technical drawing H

Ë

orthographic projection

so why don't we do this in software engineering?

Views as Projections

Structural projection system object Functional projection

Behavioral projection

Separation of Specification and Realizations

Structural projection

Functional

system object

projection Behavioral projection

Hierarchical (De)Composition

Single Underlying Model - Package Structure

Ë

Component model derived from KobrA (KobrA 2.0)

Ë

fully integrated into UML

Ë

formalized definition through OCL constraints

Ë

views generated on demand via ATL transformations

Single Underlying Model – Core Metamodel

The Navigation Jungle

Java source

UML classes

Behavior

Navigation Ë

In every dimension, exactly one dimension element can be selected

Ë

Once an element is selected in every dimension, an appropriate view is generated (i.e. a transformation is launched and an editor is started)

Ë

Unified navigation

Cell

(Component-based) Software System

Dimension Explorer

dimensions

dimension elements

editor

Navigation Ë

Dimension configuration example H

Component (Composition)

H

Abstraction Level

H

Information Hiding / Encapsulation

H

Projection

H

Variant

H

Language

H

Notation

Software Modeling Environment Roles Ë

Methodologist H

Ë

creates rules for dimensions and its contents I

predefined elements

I

source of dimension elements (e.g. dynamically generated from the single underlying model)

I

changeability rights by developer

Developer H

uses dimension based navigation

H

manipulates software system through “views”

Case Study: Mobile Tourist Guide

Mobile Tourist Guide

Name

searchTouristAttractions

Description

Searches for tourist attractions depending on the user’s preferences and the current context (e.g. location, time, weather)

Receives

-

Returns

TouristAttractionList

Sends

TouristGuideService.getTouristAttraction()

Reads

ContextSet, Preferences

Changes

TouristAttractionList

Body

-

Precondition

Preferences have been set up, Context Sources are available

Postcondition

TouristAttractionList contains suitable attractions

Mobile Tourist Guide

Mobile Tourist Guide

Description

Component Encapsulation Projection Constraints ResolutionSet Effects

1 Is the mobile client device capable of playing videos?

2 What visibility should be assignable to context item the mobile client? (Public context items are transm to the server, private context items not) MobileTouristGuide MobileTouristGuide Private Private Structural Structural --Boolean ValueSet {Public, Private, PublicAndPrivate} ResolutionValue: True ResolutionValue: Public (1) remove stereotype at Class Video (1) remove PrivateContex (2) remove association PrivateContextMatcher (2) remove stereotype on operation MobileTouristGuide.getVideo() TouristGuide ResolutionValue: False (1) remove Class Video (2) remove operation MobileTouristGuide.getVideo()

ResolutionValue: Private (1) remove stereotype at Komponen PrivateContextMatcher

ResolutionValue: PublicAndPrivate (1) remove stereotype at Komponen PrivateContextMatcher Stakeholder

Application Engineer

Application Engineer

Mobile Tourist Guide

Context Manager

Context Manager

ID Description Component Abstraction Projection Constraints ResolutionSet Effects

Stakeholder

3 Is the mobile client device capable of playing videos? ContextManager Specification Structural -Boolean ResolutionValue == True (1) remove stereotype at Komponent 3rdPartyContextServices ResolutionValue == False (1) remove Komponent 3rdPartyContextServices (2) remove association 3rdPartyContextServicesMobileTouristGuide Application Engineer

Conclusion Ë

Orthographic modeling offers a simple but powerful paradigm for supporting the multi-view development of software systems Orthographic System Modeling = view generation mechanism + navigation paradigm + View-based method

Ë

Ongoing work H

Consolidation of architecture

H

Addition of more views

H

Adaptation to other frameworks

On-demand generation from single underlying model Orthographic (dimension-based) KobrA 2.0

Thank you for your attention! Questions?

Suggest Documents