Ontologies Reasoning Components Agents Simulations Software Components and the KobrA Model-Driven...

OntologiesReasoningComponentsAgentsSimulations

Software Components Software Components and the KobrA Model-and the KobrA Model-

Driven Component-Based Driven Component-Based Software Engineering Software Engineering

MethodoloyMethodoloyJacques Robin

What are Software Components?

No standard, universally accepted definition In essence, any software unit that:

Is “independently” deployable (albeit) reuses/requires a set of typed and constrained operations

(typically provided by other components that its uses at servers) To provide a set of typed and constrained operations Executable by either:

Humans through a user interface (stand-alone deployment) Other software through an calling interface (for which it then acts as a

server)

Encapsulates: Meta-data allowing the deployment platform or development

environment to automatically assemble it with other components to provide complex services

Several related classes, routines, or functions

Component Diversity

AbstractionLevel

ExecutabilityLevel

<<Component>>Class

PIMSpecification

<<Component>>Class PSM

Specification

ComponentCommunication

ProtocolBytecode

<<Component>>Class

PIMRealization

<<Component>>Class PSM

Realization

ComponentService

ImplementationBytecode

: ComponentInstance

PIMRealization

: ComponentInstance

PSMRealization

ComponentAssemblyBytecode

ComponentObjectBinaryCode

ComponentSource Code

Interfaces

ComponentSource Code

Implementation

ComponentObject

ConstructorMethod

Source Code

Components vs. objects

Component: Independently deployable Possesses user-interface for

stand-alone deployment Not necessarily object-oriented Mid-size grained unit

intermediate between objects and systems

At run time subject to service invocation

At deployment time subject to composition/assembly

Object: But be wrapped inside a

program to be executed Only subject to method

invocation

Component Class vs. Module, Library, Package and API

API: Ambiguous term, can mean only an interface specification or an interface

specification and its implementation A component class always means the latter

Modules, libraries, packages and APIs: Not independently deployable Single unit of compilation Source code language dependent Only encapsulates behavior not data No user interface nor testing interface No meta-data

Libraries and APIs: No conceptual generalization relationships No encapsulating containment relationships

Modules and Packages: Merely a source code structuring namespaces No instantiation as run-time entity

KobrA

KobrA GoalsKobrA Goals

Pre-KobrA Obstacles Current technologies (.NET,

J2EE) exclusively at the code-level

Little understanding of how to scope components

Obstacles Larges upfront investment Poor connection with regular

“single-system” technology

Pre-KobrA Obstacles Lack of systematic methods

for creating PIMs Fixed and Ad-hoc mapping

techniques

Vision Assemble applications from

prefabricated parts COTS component market Web Services

Component-Based Engineering (CBE)

Vision Capture core software assets as

platform-independent models (PIMs) Automatically map PIMS to PSMs to

codethrough model transformation

Model-DrivenEngineering (MDE)

Vision Development activities

oriented around product families

Manage commonalities and variabilities

1

2

3Product-LineEngineering (PLE)

KobrA CharacteristicsKobrA Characteristics

Integrates: Model-Driven Engineering Component-Based Engineering Product-Line Engineering Object-Oriented Engineering Recursive Top-down Decomposition/Refinement Design Patterns Quality Assurance

Scope focus: In essence PIM construction, even tough historically conceived before

OMG’s distinction of CIM, PIM, PSM and source code executability levels Engineering for reuse and then with reuse (weak on reuse of software

artifacts not developed for reuse) Highest level part of CMMI technical solution process area

Artifact specification separate from process specification (idea reused in SPEM2.0 standard)

Why? Provide precise guidance on which UML diagrams to use for each part of a

KobrA component model Without sacrificing process flexibility to be adaptable to a wide range of

circumstantial process needs

KobrA PrinciplesKobrA Principles

Uniformity to achieve simplicity and scalability through recursive artifact nesting: Uniform recursive software unit: KobrA component

Only behaviored classifier are KobrA components Only operation-less Classes used only for data modeling

Uniform modeling language: precisely prescribed restricted subset of UML1.4 diagrams completed with tables with predefined fields filled by unrestricted natural language

Component engineering/assembly driven process: Thus driven by architecture, neither by entities and relationships (like BD and OO engineering), nor by functionalities (like use-case driven engineering); Avoids RUP inherent conflict between being entities (object) driven

and functionality (use-case) driven

KobrA Principles: EncapsulationKobrA Principles: Encapsulation

KobrA component clearly separates: the externally exposed structure and behavior of a component needed from its internally hidden structure and behavior that realize the

exposed ones as assembly of nested component

+ =+ =

thus component engineering (for reuse) = component assembly (with reuse)

Externalview point

Internalview point

Component

Realization

Specification

KobrA Principles: Creation TreeKobrA Principles: Creation TreeDriven ProcessDriven Process

In general, the client/server model leads to arbitrary graph of interconnected components

But, an arbitrary graph has numerous shortcomings as software structure: No model of composition/nesting No obvious development order

Tree based software structure has many advantages: Natural model of composition/nested Obvious development sequences Recursive definitions and activities Systematic All together resulting in improved quality and reusability

How to reconciling arbitrary client server graphs with tree-based process?

Solution: by projecting graph on creation tree Every software entity must be created by exactly one other entity Every object-oriented system running today contains a creation tree An entity normally creates the things to which it has a strong composition

relationship

KobrA Component AssemblyKobrA Component Assembly

creates

imports

A

B C

DE F G

H I1 I2

Client-Server Graph Projected on Creation Tree

KobrA PrinciplesKobrA Principles

Locality: All diagrams show a restricted view of the global PIM limited to

artifacts directly related to a given component Thus global PIM results from assembly of local UML diagrams and

complementary tabular and natural language artifacts

Separation of concern by distinguish 3 orthogonal engineering axis: Specificity axis (product line common framework components vs.

product specific components) Refinement/nesting axis (refinement level through recursive

engineering/assembly of nested components) Executability axis (CIM, PIM, PSM, source code)

KobrA Principles: LocalityKobrA Principles: Locality

Run-time Hierarchy

set of modelsdefines

Traditionalapproaches

Development Time Description

“component of” relationship

KobrA(Principle of Locality)

Separation of ConcernsSeparation of Concerns

Process does not fix whether to move first left, front or down in this cube

Executability

Refinement/Nesting

Specificity

Instantiation

FrameworkEngineering

Implementation

Framework Application

Implementation

KobrA Local Primary ArtifactsKobrA Local Primary Artifacts

Structural Model(UML class/object diagrams)

Functional Model(Operation specifications)


Interaction Model(UML collaboration diagrams)

Activity Model(UML activity diagrams)

Behavior Model(UML statechart diagram)

KobrAComponent

Specification

Realization

KobrA Component Functional KobrA Component Functional SpecificationSpecification

For each operation provided as service by the component: One table with predefined fields filled with unrestricted natural

language descriptions e.g., createAccount Operation Specification

Name createAccount

Informal Description

An account is opened in a particular currency for a customer with a particular name, and the Account ID is returned

Constraints --

Receives name : String currency:String

Returns A String with the ID of the account

Changes bank

Assumes There is an exchange rate for the specified currency

Result A new account with a unique ID in the denomination, currency, has been generated The name of the customer has been stored in account The account ID has been returned

KobrA Local Complementary ArtifactsKobrA Local Complementary Artifacts

Non-functional requirements specification desired quality characteristics

Quality Measures desired quality thresholds and the related quality factors

Dictionary tables of model entities and their role

Test Cases test cases to support functional testing

Decision Model variable features and related user decisions

KobrA Local ArtifactKobrA Local ArtifactConformance RulesConformance Rules

A

B

Consistency relationships

Refinement relationships

Contract relationship

KobrA Local Artifact AssemblyKobrA Local Artifact Assembly

Clientship rules

Clientship +Containment rules



Containment rules

Cliensthiprules

Clientship rules

Specification of server component must match realization of client component

KobrA Top-Level Artifact:KobrA Top-Level Artifact:Context RealizationContext Realization

Corresponds to: CIM in MDE, Domain model in domain engineering Business model in early requirement engineering;

KobrA’s uniformity principle: Whole system = all containing top level server component Server of whom? Of system usage context = non-computational environment! Its specification must conform to some containing client component The non-computational environment is thus represented using a set of

artifacts that specializes the artifacts of a KobrA component realization This context realization is thus a peculiar specification-less KobrA

Component




Realization

KobrA Recursive ProcessKobrA Recursive Process

SpecificationRealization

Cpt A

Cpt B

Cpt D

Cpt C

ComponentReuse

COTS Component

Interleaves component specification with component realization COTS reused by wrapping them in KobrA specification constructed by

black-box reverse engineering

KobrA: Refinement Process KobrA: Refinement Process Orthogonal to Implementation Orthogonal to Implementation

ProcessProcess Refinement: recursive PIM component specification and

realization down the component nesting structure Implementation: translation of PIM to PSM and code

Cpt A PIM

Cpt B PIM

Cpt CPIM

Cpt A PSM

Cpt B PSM

Cpt CPSM

Cpt ASource Code

Cpt CSource Code

Cpt CSource Code

KobrA Process ActivitiesKobrA Process Activities

Data Activities

Specification

Realization/Specifications

Object-oriented

Data Activities

Specification

Realization/Specifications

Object-oriented

Activities Data

Realization

Realization

Context Realization

Specification

Specification

Specification

SingleComponent

Top-DownRecursive

NestedAssembly

KobrA Specification Process ActivitiesKobrA Specification Process Activities

Business process modeling who does what to what and

when actors, activities, data and

rules described at “business” level of

abstraction Data modeling

identify organizational and technological data

identify information and material data

Usage modeling activity modeling

decompose activities thatinvolve the “system”

interface design screen templates, dialogues etc.

Interaction modeling integrate actors, activities,

data and rules

DataActivities

DataModeling

Business ProcessModeling

Realization

InteractionModeling

UsageModeling

DataActivities

DataModeling


Realization

InteractionModeling

UsageModeling

Role of Use Cases in KobrARole of Use Cases in KobrA

Traditional use-case modelling roughly covers the concerns addressed by usage and interaction modelling use case modelling = usage

modelling + interaction modelling

A use case corresponds to an activity asociated with the software system use case = activity

associated with the software system

a use case diagram can be used to document such activities

The system is one of the actors or data items identified in the “to be“ business process models

DataActivities

DataModeling


Use CaseModeling

DataActivities

DataModeling


Use CaseModeling

KobrA Process Realization ActivitiesKobrA Process Realization Activities

Structural model describes the data and

components needed by the component in order to fulfill its contract one or more class diagrams zero or more object diagrams

Activity model describes the algorithms used

to realize the operations of the component zero or more activity diagrams

Interaction model describes how operations of

the component are realized in terms of interactions zero or more interaction

diagrams (per operation)

Data Activities

StructuralModeling

InteractionModeling

ActivityModeling

Data Activities

StructuralModeling

InteractionModeling

ActivityModeling

KobrA: Product Line ArtifactsKobrA: Product Line Artifacts

Generic framework component contains all the functionalities of all their possible product specific instantiations

<<variant>> stereotype in framework component model elements not general to all products

Decision model: Maps characteristics of product to <<variant>> stereotyped model

elements to include in corresponding product Table with predefined fields filled with natural language

KobrA PLE:KobrA PLE:Example of Example of FrameworkFramework

Class Class DiagramDiagram

with with <<variant><<variant>

>>stereotypestereotype

KobrA PLE Framework ArtifactsKobrA PLE Framework Artifacts


Functional Model(operation schemata)




Behavior Model(UML statechart diagram)

Decision Model(textual)

KobrAFrameworkComponent

Decision Model(textual)

Specification

Realization

KobrA Built-In Contract Testing (BICT)KobrA Built-In Contract Testing (BICT)

KobrA’s principle of uniformity and locality applied to testing Built testing capability locally in each component The component assembly not only results in application by

functionality composition But it also results in testing infrastructure composition that

saves work of constructing a global application specific testing infrastructure

Key idea: Add to each client component a nested tester component to test

each server to which it may be connected through assembly Add to each server component a testing interface distinct from the

functional interface that can be used by the nested tester component of the clients to which it may be connected through assembly

The testing interface expose state information not needed for the application execution but needed for its testing

KobrA Built-In Contract Testing (BICT)KobrA Built-In Contract Testing (BICT)

<<Component>>Server A

<<Component>>Client B

<<Interface>>Server A

<<uses>>

<<Component>>Client B w/ BICT

<<Tester Component>>Tester(A)

<<uses>><<Component>>Server A w/ BICT

<<Testing Interface>>Server A

Limitations of KobrALimitations of KobrA

Based on UML1.4 which did not support neither for MDE nor CBE: Monolithic meta-model, unpractical for partial reuse in profiles for

building PSM No OCL, thus no fully refined PIM in an unambiguous

computational language free of natural language, thus no possibility for automated code generation through model transformation

No full-life cycle components (only in deployment diagram), thus no design by contract PIM

Narrow scope not covering: Implementation Model transformation

Focuses on design for reuse: Provides little guidance for design with reuse from legacy software,

refactoring, reverse engineering, etc. Simplistic, not scalable PLE variation modeling scheme Does not deal with component repository management

KobrA2 Improvement GoalsKobrA2 Improvement Goals

Support more advanced forms of MDE and CBE By leveraging the latest OMG standards:

UML2.1 modular meta-model and better founded profiles UML2.1 full life cycle components OCL2.0 to model PIM, PSM, meta-models and UML2.0 profiles that are:

Fully refined, yet free of natural language ambiguities, thus viable input to fully automatic model transformation

MOF2.0 and Ecore to define meta-model of KobrA2 SPEM2.0 to support full KobrA2 method and process modeling

By leveraging latest Eclipse integrated MDE CASE tools: Eclipse Modeling Framework (EMF, based on Ecore) Eclipse Process Framework (EPF, based on SPEM2.0) Borland Together (based on EMF) Atlas Transformation Language Development Tool (ATL-DT, based on EMF)

Leverage model transformation to: Weave product-specific elements onto framework components instead of or

in addition to instantiating them Add on and take off BICT artifacts

Ontologies Reasoning Components Agents Simulations Software Components and the KobrA Model-Driven...

Documents

Transcript of Ontologies Reasoning Components Agents Simulations Software Components and the KobrA Model-Driven...