software recycling in “skilltree” technology introduction

Software RecyclingIn

“Skilltree” Technology

Introduction

Version 3 (preview 1)by Avner Ben

25 August 2011

25-August-10 2Design Abstraction with Skilltree Tech.

Contents:

1. The challenge of Software Recycling2. The “Skill-driven” solution3. The “Skill-driven” process


1. The challenge of Software Recycling


Software Recycling - Product Scope

1. Services2. Deliverables3. Expectations from client4. Means



1. Services:

To extract the design from the code of a software product.

To refactor and improve the code of the current product.

To re-design the next generation product.

2. Deliverables3. Client side4. Means



1. Services

2. Deliverables: A Design database.

o Browse online. o Print design documents.o Improve design.o Generate code starters.

Documentation in code.o Both Human and machine readable.

A Critical Design Review document.3. Client side4. Means



1. Services2. Deliverables

3. Client side: Domain expertise Programming skills.

4. Means



1. Services2. Deliverables3. Expectations from client

4. Means: Proprietary method – “Skill-driven” Design. Formal language – “Skilltree” VHLL. Automated tool – uses the Skilltree compiler engine.


Software recycling opportunities

1. Salvage “legacy” code.

o Mine priceless hidden problem/solution domain knowledge.

2. Understand provided infrastructure.

o (Such as “open source”.)

3. Facilitate design review.

o Evaluate the big picture, then dive into detail.o Find design errors, reducing “bugs”.

4. Promote risk management.

o Mine the necessary data about size and complexity.


Software recycling Benefits

1. Assess the requirements

2. Get an extra pair of eyes



1. Assess the requirements:

Those really implemented vs. those requested. Common reasons for loss of fidelity:

o Problem domain clarified during implementation. o Market demands changed during implementation. o Novel technology evaluated through tangibles.o Improvised in response to urgent demand.

2. Get an extra pair of eyes



1. Assess the requirements:

2. Get an extra pair of eyes……that no Human has! Discover a treasure of knowledge,

which only borders on the professional consensus:o Problems that eventually occur.o Solutions in unexpected ways.

Re-design “from scratch”, and you pay the price of re-learning!


The Competition

1. Documentation generation technology

Print volumes of unsolicited trivial detail for no one to read.

2. “C.A.S.E.” technology (“Computer-Aided Software Engineering”).

Visual language for countless programmatic detail,o Obscuring the requirements.

An evolutionary dead end?o With us since the 1990’s.o So far, has not lived up to expectation.o Rejected by the market at large:

o Purchased but seldom used seriously,o Except for niche applications.


2. The “Skill-driven”Solution


The Skill-driven Premises

The job requires two skills (which are complementary):

1. Automation Alone will not do!

o The code was not written by machines.o The code is subject to Human intuition and idiosyncrasy.

2. Human intelligence Alone will not do!

o Cannot cope with size and complexity of even the smallest commercial product.o The job is dull, detail-plagued – impractical!


The Skill-driven Premises

Programmatic detail – out of design limits!

The challenge of “full-cycle” engineering: Find the golden road to…

Allow machine readability, o Be detail-complete

Yet, o Leaving the code readable, o maintainable!


The Genuine Challenge

Given the dichotomy: automation vs. Human:

What does each of these functions contribute? How do they interact profitably? What not to expect (from each)!


The “Skill-Driven” Approach

This software recycling proposal is…

A service Rather than Do-It-Yourself kit! Responsibility of Third-party team, involving user personnel.

Based upon…1. Robust methodology.

o “Skill-Driven” design.

2. Proprietary product:o “Skilltree” VHLL* compiler and viewer.o Design extraction/insertion tool (Skilltree extension).

* “Very High-Level Language” - roughly, machine-readable object-oriented Pseudocode.


3. The “Skill-driven”Process


The Skill-driven Process

1. Layout the project. Given project scope, source files, coding and documentation convention, produce the reverse-engineering configuration file, preliminary version.

2. Parse source files. Given source files and configuration, fine-tune configuration and produce first-generation documented source files, copying original program structure and adding default skill-driven documentation, using original documentation where available and generated documentation elsewhere.

3. Edit in-code documentation. Iterate on improving original copied/generated in-code doc, counting on programming convention, domain knowledge and common sense. Validate resulting design base. Further edit in-code documentation for concise design.

4. Analyze reconstructed design. Given various graphic and textual views of the design and knowing design architectures, patterns and idioms, criticize the current architecture (as reconstructed).

5. Implement next-generation product. Given concise requirements, elaborate on the reverse-engineered design base, giving design for the next generation product. Then, produce documented code starters , add missing programmatic detail, make implementation decisions , compile, test and deploy next generation product.


Sample Artifact Sequence1. Source code (excerpt)

2. Automatically-documented code

3. Documented code, manually edited

4. Skilltree design base

5. Automatic design view

6. Generated code starter

bool DecisionMaker::findOut(const State& aState) { bool isStable = aState.isStable(); if (isStable) currentDecision.setStability(true);


Sample Artifact Sequence1. Source code






// to find out 5172// - Input: (formal) a State// - Output: (formal) a Boolean// - Use Case: Finding out 5172bool DecisionMaker::findOut(const State& aState) { // Message: “to tell if is stable 3265” bool isStable = aState.isStable(); // Message, Option: “to set stability 3266” if (isStable) currentDecision.setStability(true);








// to find out about State// - Input: (formal) State to find out about// - Output: (formal) decision// - Use Case: Finding out about Statebool DecisionMaker::findOut(const State& aState) { // Message: to tell if State is stable bool isStable = aState.isStable(); // Message, Option: to set stability for Decision if (isStable) currentDecision.setStability(true);





4. Skilltree design base (excerpt)



ENTITY Decision Maker CAPABILITY to find out about State INPUT (FORMAL) State to find out about OUTPUT (FORMAL) decision IMPLEMENTATION Method SIGNATURE findOut(aState:const State&):boolBREAKDOWN OF CAPABILITY to find out about State USE CASE Finding out about State ACTOR Manager NEED to tell if State is stable (BY State) NEED (OPTION): to set stability for Decision (BY Decision)






5. Automatic design view (sample, “Sequence Diagram”)









// to find out about State.// - Input: (FORMAL) State to find out about.// - Output: (FORMAL) Decision.// - Use Case: Finding out about State.bool DecisionMaker::findOut(const State& aState) {

// Message: "to tell if State is stable"aBool = aState.isStable();// Message, OPTION: “to set stability for Decision”if (/* unknown condition */) {aDecision.setStability();}

}


Thank you for your attention!

software recycling in “skilltree” technology introduction

Documents

design abstraction

software product

design database

design errors

software recycling benefits1

print design documents

skilltree compiler engine

generation product