1 S216/MAPLD 2004 Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc

1 S216/MAPLD 2004Hamilton

Copyright © 1986 - 2004 Hamilton Technologies, Inc.



What if You Could Design Systems and Build Software with:

• Seamless integration, including systems to software

• Defects reduced by a factor of 10 • Correctness by built-in language properties

• Unambiguous requirements, specifications, designs…removing complexity, chaos and confusion

• Guarantee of function integrity after implementation

• Complete traceability and evolvability (application, architecture, technology) • Significant increase in inherent reuse

• Automatic generation of complete software systems from system specifications (full life cycle automation including 100% production ready code for any kind or size of system)

• Automation of much of design/resource allocation; no longer a need to

understand details of programming languages and operating systems • Elimination of the need for high percentage of testing

• An integrated set of life cycle tools, all defined and automatically generated by itself

• Significantly higher reliability, higher productivity and lower risk



Perceptions and Perspective

• Most people would say “impossible—software by its very nature is destined to have the major problems of traditional environments”

• Some would say “impossible in the foreseeable future”

• Not only is it not impossible; it is possible to accomplish most of these goals today with at least one technology (a technology in large part derived/evolved from Apollo’s on-board flight software effort)

• Some might ask how a technology with Apollo roots could address problems "more modern" technologies have not solved

• Its evolution differentiates foundations from the "latest" and the "greatest" (e.g., OS, programming language, life cycle process)—"don’t throw out the baby with the bath water"

• Roots also from concepts older and newer than Apollo; keeping in mind the relevance of a technology is independent of its age

• New to the marketplace at large, it would be natural to make assumptions about what is possible and impossible based on its superficial resemblance to other technologies—like traditional object technologies

• It helps to suspend any and all preconceived notions when first introduced to this

technology because it is a world unto itself—a complete new way to think about systems and software



Background: Some Beginnings—Not to Reminisce...But to Understand the Culture

• Flip of a coin: on-board flight software for Apollo missions

• Software engineering/computer science not yet a field (no school to attend)

• Learning was by “doing” and “being”

• Problems had to be solved no one else had solved. At times we just had to make it up

• Stuff we did had to work—the first time

• Most were fearless twenty-something (technical managers and engineers)

• Dedication and commitment a given

• Mutual respect; managers gave software people freedom/trust; software a mystery

• Luckiest people in the world; no choice but to be pioneers



No Time to be a Beginner

• Some unmanned experiences

—Aukekugel [scientists’ method]

—Lunar Landmark tables

—Forgetit

• Manned missions came next

• These experiences were exciting enough in their own right



Fascination with Errors

• Even more exciting: how they contributed to what was to happen later, especially that having to do with errors—finding them, detecting and recovering from them, handling them, preventing them, fixing them, learning from them, learning about systems from them…even defining what an error is

• Errors had always been fascinating, even before Apollo (SAGE):

—Every error a major event (flashing lights, sirens...)

—Polaroid pictures taken of the crash site (person responsible)

—One day turnaround encouraged careful thought and multiple test cases, in parallel

—Seashore tracking program: finding the errors



It Quickly Became Clear No One and Nothing is Perfect

• Software gurus, hardware gurus, astronauts included

• Expect the "unexpected unexpected" [lightning struck spacecraft at least twice]: always have backups, "what ifs"

• Always searching for new and different ways to prepare for the unexpected

—P01 (3 year old), explicit real time "debug“, program notes

—Erroneous hardware signals on Apollo 14 (faked out software with manual intervention in real time). Simulation

—Asynchronous operating system (systematic reconfiguration in real time)

—Priority display (off nominal, emergencies): 1201, 1202 alarms

(Apollo 11) • Houston meeting said it all



Other Apollo Experiences Gave Insight to Understanding Software

(and its Development) as a System with a System Engineering Viewpoint• "What goes around comes around“; everything somehow related to everything else;

one seemingly small event can change everything, for better or worse (ACS)

• The very way one communicates can cause or prevent crashes, little ones and big ones (man/tech): ACS daily memos and off line versions

• Programmers and designers necessarily became interchangeable; as did life cycle phases

• Relationship of real time and development (async)

• “System wide recompute restart” far superior to “point repair with fallback results” restart

• Everything a moving target. The only constant is change

• Build on foundations that allow for freedom of choice without compromising integrity (open architecture, async)

• Never say never: more than one way to solve a problem (how affected, not what caused it)

• Once understood as a true system, possible to use power of reuse to the hilt and to the highest form (wisdom)



Experiences Like These Compelled Us to Learn from Them So Future Systems Could Benefit:

Top Priority—Reliability

• Apollo: opportunity to make just about every kind of error humanly possible (no software errors during flight)

• "What were we doing wrong so we could stop doing it and what were we

doing right so we could keep doing it?" • Analyzed every aspect possible of on board flight software and its

relationships

• Error study...majority interface (data, timing, priority conflicts to the finest grain): ambiguous relationships, mismatches and conflicts in the system, communication, integration and coordination problems. Military studies later had similar findings

• What is an "error"?* (medical): FLTs…catastrophic

• Led to a new mathematics/paradigm for designing systems and building software that would, among other things, eliminate all interface errors

• Repeat the process over and over again...never assume anything or anyone is perfect

*Hamilton, M., Hackler, W. R., What is an Error?, System Oriented Objects: Development Before the Fact, In Press.


001™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

Note 1: no software errors known to occur during flightNote 2: majority of 44% found by "Nortonizing"



Root problem: traditional systemengineering and software development environments supportusers in "fixing wrong things up" rather than in "doing things in the right way in the first place".


Solution: Development Before the Fact

A new paradigm: define each system with inherentproperties ("come along for the ride") that support its

owndevelopment.

• Each definition not only models its application but it also models properties of control into its own life cycle.

• Every object is a System Oriented Object (SOO), itself developed in terms of other SOOs. A SOO integrates all parts of a system including those that are function, object and timing oriented. Every system is an object. Every object is a system.

• Instead of Object Oriented Systems, System Oriented Objects. Instead of model driven systems, system driven models

• What is different about DBTF is it is preventative instead of curative. Instead of looking for more ways to test for errors, look for more ways not to let them in, in the first place

Development Before the Fact™, DBTF™ System Oriented Object™ and SOO™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

With Development Before the Fact a System is Defined from the Very Beginning to Inherently:

• Integrate and make understandable its own real world definitions

• Maximize its own —Reliability and predictability —Flexibility to change and the unpredictable

• Capitalize on its own parallelism

• Maximize the potential for its own —Reuse —Automation —Evolution

RESULT: a formal based system with built-in quality,and built-in productivity for its own development


Universal Systems Language™ (USL™), 001AXES™ and Development Before the Fact™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

The Universal Systems Language (001AXES) is the Key: Defines Each System with Development Before the Fact

Properties• Same language used to define and integrate

—All aspects and viewpoints* (of and about the system and its evolutions); relationships; levels and layers of requirements, analysis and design (seamless lifecycles)

—Functional, resource and allocation architectures including hardware, software and peopleware

—Sketching of ideas to complete systems

—GUI with documentation…with application

—Maps: hierarchical network control systems of interrelated objects

• Syntax, implementation, and architecture independent

• Unlike formal languages that are not friendly and friendly languages that are not formal this language is both formal and friendly

*Adheres to the principle that everything is relative. One person’s design is another person’s implementation.



Process of Building a Before the Fact System

•Define/Evolve any model in any phase (problem analysis,

specifications, operational scenarios, constraints, design…) with the before the fact systems

language

•Analyze automatically the model to ensure it wasdefined properly

•Generate automatically a complete, integrated, fully

production ready software implementation/simulation/

documentation for the architecture of choice consistent

with the model

•Execute the model

•Deliver the real system

– Process is iterative/recursive– Can be parallel, asynchronous or

incremental– Can be used for rapid prototyping

or for production ready, full scaledevelopment


™

001™ and System Oriented Objects™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

001 is usedto make System OrientedObjects, each of which is

based upon a uniqueconcept of control

Every system defined with 001, including 001 itself, is defined in terms of System Oriented Objects 001 was used to completely define–and completely and automatically (re)generate–itself


DBTF Philosophy: Reliable Systems are Defined in Terms of Reliable Systems

• Use only reliable systems

• Integrate these systems with reliable systems

• The result is a system(s) which isreliable

• Use resulting reliable system(s)along with more primitive onesto build new and larger reliablesystems

A recursively reliable and reusable process

MORE ABSTRACT SYSTEMS

ABSTRACT SYSTEMS

PRIMITIVESYSTEMS

Development Before the Fact™ (DBTF™) is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


SOO ™, 001AXES™, Function Map™ (FMap™) and Type Map™ (TMap™) are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

* A map is a hierarchical network of interrelated objects under control

Every SOO is Defined with the Building Blocks of 001AXES

All model viewpoints can be obtained from FMaps and TMaps. Maps of functions are by theirvery nature integrated with maps of types *

A system is defined from the very beginning to inherently integrate and make understandableits own real world definition

Ultimately in terms of 3 primitive control structures

Model Functional Behavior (Time)with Function Map (FMap)

Model Type Behavior (Space)with Type Map (TMap)

Control Structure Function Objects (Members of Types)

Constraint Type and its methods Relations


Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


001AXES™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

Systems Defined in Terms of the Primitive Control Structures Result in Properties for Real Time Distributed Environments

A system is defined from the verybeginning to inherently maximize itsown flexibility to change and the unpredictable and to capitalize onits own parallelism

Every object has a unique priority

Each object and changes to it are traceable Each object can be safely reconfigured

("pluggable" and "unpluggable")

Every system is event-driven

Concurrent patterns can be automatically detected

Every object has a unique parent andis under control

Every parent has a higher priority andBehaves as a master scheduler for its children

22 S216/MAPLD 2004HamiltonCopyright © 1986 - 2004 Hamilton Technologies, Inc.

A system is defined from thevery beginning to inherentlymaximize the potentialfor its own reuse

syntax (template) for its use:

Syntax defines aninterface (template)for families that wantto use the structure’shidden functionality

definition of structure:

J

I

J J

Hidden functionsto be appliedwhen used asa structure

replace:Coinclude?with ProcessA? with TaskAB? with TaskB

example of its use:

b1,a1 = Process(b,a)

b1 = TaskB(a) a1 = TaskA(b,a)

CI Use containscommon pattern ofhidden functions

CI

= A? a)(xay= B?b

yb

)(x

= A? a)(xay= B?

by

b)(x

= Coinclude?(x)b

y ay,

= Coinclude?(x)b

y ay,



An Async Structure and its Use(Distributed, Synchronous and Asynchronous Behavior)

J

CII

hidden functionsused to coordinateindependent functionsthat communicate ateach Async iteration

O

Structure:

A,B = Async(A1,toA1,B1,toB1)

Use: C,M=Steer_missile(C0,M0)CC,CJ

C,F=ControlSteering(C0,pos0,fin0,cmd0)

C1,nextcmd=ControlFin(C0,pos0)

rotatedFin,pos=Turn_fin(fin0,cmd0)

Async: areCommandsDone

M=intoMissile(F)pos0,fin0,cmd0=initialize(M0)

Controlled System

Controlling System

Syntax:

A and B to work independently. Each hasits own independent variable and adependent variable for passinginformation to the other

apply recursively

A ,B = Async?(A0,toA0,B0,toB0)

B1,toA1 = B?(B0,toB0)A 1,toB1 = A?(A0,toA0)

A 1,toB1=A?(A0,toA 0) B1,toA1=B?(B0,toB0)

A,B=Async?(A0,toA 0,B0,toB0)

Async: isDone?


FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


001AXES™, TMaps™, EMaps™, FMaps™ and Executor ™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.



Periodic Processing Using a Timed Interrupt

G 1=gu id ance(G 0) J

G =m anage_ gu id ance(G 0,from N ) p rocessP eriod ically :gu id anceD B

C 1=control(C 0)

C =m anage_control(C 0,from G ) p rocessP eriod ically :controlD B

C0,fromG=do_Guidance(G0)

N 1=nav igation(N 0) J

N =m anage_nav igation(N 0,from C C C ) p rocessP eriod ically :nav igationD B

G0,fromN=do_navigation(N0)

manage_navigation, manage_guidance, andmanage_control each interrupts its child whenfromCCC, fromN and fromG respectively arrive.Each of these parent functions coordinatesbetween its child and parent function in order torepeat its local cyclic interval period.

Real Time Schedule Characteristics

guidance

control

navigation

...

...

...

Sy n tax:

d b1=F(d b0)?

d b=__ (d b0,from ) p rocessP eriod ical ly :D B

T M ap Stru ctu re:

clockperiod (tim e)

D B?

w ithC lock P eriod

Sy n tax:

D B?

__ (w ithC lockP eriod )

Control(withClockPeriod)

guidanceDB

controlDB

...

Guidance(withClockPeriod)

PGM

...

navigationDB

Navigation(withClockPeriod)

...

U se:d b=p rocessP eriod ically :D B(d b0,from ) C J *2

c,t=v iew :clock ,p eriod ,D B(d b0)

d b=R U N (d b0,from ,end ) C O :is:p resent,any (from )

end =at:tim e,clock (c,t)

d b1=F(d b0)?

d b=incorp orate_m sgs(d b0,from )d b=cl1(d b0)

d b=d o_ again(d b0,from ) C J

d b=end _of_p eriod _or_ not(d b0,from ,end ) C O :is:p resent,any (end )

d b=R U N (d b1,from ,end )

F M ap Stru ctu re:

control runs an autopilot tomanage missile controls

U se:




Primitive Control Structure™ and FMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


TMap™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

Theater Defense (cont.)

30 S216/MAPLD 2004HamiltonArchitecture Independent Operating System™ (AIOS™), RAT™, DXecutor™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


Separating the Function, Allocation and Resource Architectures

Resource and Allocation Architectures

2 Robot Schedule

TransferBlock

TransferBlock

1 Robot Schedule

TransferBlock

TransferBlock

One or two robots can be used to transfer ablock from region A to region B and thenfrom a region C to region D.

CC

D1,C1,B1,A1,sam2=Transfer2Blocks(D,C,B,A,sam)

B1,A1,sam1=TransferBlock(B,A,sam)

D1,C1,sam2=TransferBlock(D,C,sam1)

I

D1,C1,sam1,B1,A1,joe1=Transfer2Blocks(D,C,sam,B,A ,joe)

B1,A1,joe1=TransferBlock(B,A,joe)

D1,C1,sam1=TransferBlock(D,C,sam)

Function, Resource and AllocationArchitectures as Separate Definitions

Functional Architecture

I

D1,C1,B1,A1=Transfer2Blocks(D,C,B,A )

B1,A1=TransferBlock(B,A)D1,C1=TransferBlock(D,C)

Allocation ArchitectureWhere: Transfer2Blocks on 2Robots

Or: Transfer2Blocks on Robot

Resource Architecture

2 Robotresources

r4,r3 (2Robots) r2,r1

r3(Robot)r1I

r4(Robot)r2

1 Robotresource

r(Robot)r0

r1(...)r0

holding(Hand)r1r(Block)holding

J J



Constraints Define Properties about Another System

EndPointConstraint states: an interval low point mustbe less than and therefore distinct from its high point

Intervals(OSetOf)

Interval

Low(Point)

High(Point)

TMap:

B=EndPointConstraint(I) CJ*2

h=moveto:high,Interval(I)l=moveto:low,Interval(I)

B=LessThan:Point(l,h)

B=IntervalConstraints(I) CJ*2

endsOK=EndPointConstraint(I)

sizeOK=SizeConstraint(I)

B=and(endsOK,sizeOK)

A. FMaps define constraints on types

FMaps define constraintson objects local to an FMap

B=OrderedBy:LowOrHigh(Intervals) checkTwoByTwo

ok=IsOrdered(I3,I4)

h4=moveto:LowOrHigh,Interval(I4)h3=moveto:LowOrHigh,Interval(I3)

ok=LessThan:Point(h3,h4)

This constraint FMap is parameterized (i.e. byLowOrHigh) to validate the ordering of Intervalsusing either the low or high point of an interval.LowOrHigh has the value Low when used as aconstraint in create_ordered_intervals

Constraints (or Axioms) for type Interval:

B.

Constraints associated with type Interval in the TMap (i.e IntervalConstraints)hold for all Interval instance objects in an FMap (e.g. I1 and I2 are consistantwith those constraints)

create_ordered_intervals constrained by bothIntervalConstraints and OrderedBy:Low constraints

OrderedBy:Lowconstrains outputorderedIntervals to beordered by its set ofinterval low points

Constraint:OrderedBy:Low(orderedIntervals)="True".

orderedIntervals=create_ordered_intervals(x,y) J

partiallyOrdered=order_by_lowest_point(I1,I2)

unOrdered=create_intervals(x,y)

orderedIntervals=order_intervals(unOrdered) sort_intervals

C.

TMap™ and FMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


Object Map™ (OMap™), Type Map™ (TMap™), Execution Map™ (EMap™) and Function Map (FMap™) are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


OMap™, TMap™, EMap™ and FMap™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


RMaps™, OMaps™, TMaps™, EMaps™ and FMaps™, RAT™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

User DefinedParameterized Type

Requirements System

Target Application System

Testing System

LayeredPrimitive Type

RMap of Definitions

RMap of Libraries

FMap

TMap

OMapFMap

SGT (RAT Specification)

UserDefinedStructure

Application Test

Reqs.validatedby

requires

Share libraries across and withinprojects, and definitions within andacross libraries (within projects)

* RMap shows integration of and connectionsbetween all the different system componentswithin an architecture--for example, howrequirements relate to testing system,user system (i.e., operationalscenarios), target system

team development can bedefined as a 001 systemusing this architecture

A Road Map (RMap) Defines the Architecture of a System *in terms of cooperating domain models and their inter-relationshipsand supports project management of cooperating team development

RMap of Projects


RT(x)™, FMaps™, TMaps™, Xecutor™, RT(x)™, 001 AXES™, Analyzer™, and RAT™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

• Organize projects into working libraries• Manage and trace requirements• Generate product and process metrics• Generate specification, design and test documentation

Management

• Revise FMaps and TMaps• Repeat engineering and/ or development process

Design Changesand Maintenance

• Define FMaps and TMaps for system architecture• Analyze• Simulate real-time behavior

System Engineering

A system is defined from the very beginning to inherently maximize the potentialfor its own automation and evolution

• Define FMaps and TMaps for application• Analyze• Generate production ready code• Execute on target resource/ machine

Software Development

- A 001 model is independent of language, architecture, technology, communications

protocol ... i.e., not locked in- The RAT can be used to weave aspects about the system into the generated code

- simulator (resource architecture metrics)- interpreter- meta executive (fine grained parallelism/ event driven)

* OMapEditorused for testing

System Engineering Seamlessly Integrated with Software Development

Manage/TraceRequirements and Metrics

with RT(x)

Generatefrom FMaps & TMaps

with RAT

Execute *with machine or

Xecutor

(re)DefineFMaps & TMaps with

001AXES

AnalyzeFMaps & TMaps with

ANALYZER


RMaps™, OMaps™, Omap Editor™, TMaps™, RAT™, EMaps™ and FMaps™ are all trademarks of Hamilton Technologies, Inc. (8-30-04) Copyright © 1986 - 2004 Hamilton Technologies, Inc.

One of the Most Powerful, If Not the Most Powerful Aspect:the Degree to which Reuse Inherently Takes Place

Inherent and explicit patternsof reuse provided withFMaps and TMaps*

Recursive, Inherent, Reuse:Types are Definedin Terms of Functions;Functions are Definedin Terms of Types

A layer of primitive Types isolatesthe system being specified (the WHAT)from its possible implementations (the HOW)

* Reuse also provided with RMaps, OMaps, EMaps, RAT(reusable architecture configurations), OMap Editor, etc.

functions

objects

Type nType mFMap

(doing)

TMap

(being)

op A

op B Type y

TMap

objects

primitive operationsType x

uses

Layer

Alternative Layer Implementations

Structure

Recursion

Leaf Extension

Leaf E xtensi on

Structure

Recursion

Layer

Leaf Extensi on

Structure

Recursi on

L ayer

38 S216/MAPLD 2004HamiltonXecutor™, 001AXES™, RAT™ and AIOS™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2003 Hamilton Technologies, Inc.


Before the Fact Testing: an Integral Part of Every Phase (Instead of Testing Something Over and Over Again After the Fact)

• Correct use of 001AXES eliminates majority of errors

• Analyzer hunts down all interface errors

• RAT always generates 1) embedded test cases into code for finding during execution

incorrect object use; 2) test harnesses for testing each object and its relationships

• Inherent reuse and automation remove need for most other testing: e.g., built in aspects,

inherent integration, 100% of code automatically generated

• Inherent testing support facilities include demotion and configurable RAT

• Testing components include Xecutor, RT(x) and Coverage Analysis Tool

• Remaining test cases can be defined and developed as 001 applications including those

having to do with defining constraints

• Maintenance shares same benefits as development-developer doesn't ever need to change the code-application changes made to the specification-not the code-architecture changes made to the configuration-not the code-only the changed part of the system is regenerated and integrated with the

rest of theapplication (again, all automatically). The system is automatically analyzed,

generated, compiled, linked and executed without manual intervention.

Xecutor™, RT(x)™, 001 AXES™, Analyzer™ and RAT™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

The need for most kinds of testing used in a traditional environment is removed. Most errors are prevented because of that which is inherent or automated (i.e., reused)

Since RT(x) automates the process of going from requirements to design to tests to use cases to other requirements and back again the need to ensure the implementation satisfies the design and the design satisfies the requirements is minimized


Alternative Approaches: Began with Opposite Focus

• Traditional

—Software centric

—Syntax first: software language(s) for defining software with (or without) object orientation

—In some cases many languages "merged" into one language

—Additional language mechanisms (sometimes additional languages), rules and tools added, ad hoc and "after the fact", as more is learned about a class of software systems

• Development Before the fact

—Systems centric

—Semantics first: empirical study of real world systems from which core foundations were derived for a generic system semantics that led to

a universal systems language

—Universal systems language used for defining (and developing) system oriented objects for software and systems in general

—Additional language mechanisms derived from core set of systems language primitive mechanisms

• Much of what seems counterintuitive with traditional techniques becomes intuitive with DBTF

Development Before the Fact™ (DBTF™) and Universal Systems Language™ (USL™) are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.


Integration ad hoc, if at all~Mismatched methods, objects, phases, products,

architectures, applications and environment~System not integrated with software~Function oriented or object oriented

~GUI not integrated with application~Simulation not integrated with software code

Integration~Seamless life cycle: methods, objects, phases, products,

architectures, applications and environment~System integrated with software~System oriented objects: integration of

function, timing, and object oriented~GUI integrated with application~Simulation integrated with software code

Behavior uncertain until after delivery Correctness by built-in language properties

Interface errors abound and infiltrate the system (over 75% of all errors)~Most of those found are found after implementation~Some found manually~Some found by dynamic runs analysis~Some never found

No interface errors

~All found before implementation~All found by automatic and static analysis

~Always found

Ambiguous requirements, specifications, designs …introduce chaos, confusion and complexity~Informal or semi-formal language~Different phases, languages and tools~Different language for other systems than for software

Unambiguous requirements, specifications, designs …remove chaos, confusion and complexity~Formal, but friendly language~All phases, same language and tools~Same language for software, hardware and any other

system

No guarantee of function integrity after implementation

Guarantee of function integrity after implementation

Traditional (After the Fact) Before the Fact

Some Differences

System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

Part 1 of 2 parts


Inflexible: Systems not traceable or evolvable~Locked in bugs, requirements products, architectures,

etc.

~Painful transition from legacy~Maintenance performed at code level

Flexible: Systems traceable and evolvable~Open architecture~No longer a need to understand details of programming

languages or operating systems~Smooth transition from legacy~Maintenance performed at spec level

Reuse not inherent~Reuse is adhoc~Customization and reuse are mutually exclusive

Inherent Reuse~Every object a candidate for reuse~Customization increases the reuse pool

Automation supports manual process instead of doing real work~Mostly manual: documentation, programming,

test generation, traceability, integration~Limited, incomplete, fragmented, disparate

and inefficient

Automation does real work

~Automatic programming, documentation, test generation,

traceability, integration~100% production ready code automatically generated for all and any kind or size of software

Trapped in "test to death" philosophy Less testing becomes necessary with each new before the fact capability

Product x not defined and developed with itself 001 defined with and generated by itself

Dollars wasted, error prone systems

~High risk~Not cost effective~Difficult to meet schedules~Less of what you need and more of what you don’t

need

Ultra-reliable systems with unprecedented productivity in their development~Low risk~Maximum dollars saved/dollars made~Minimum time to complete~No more, no less of what you need

Traditional (After the Fact) Before the Fact

Some Differences (Cont.)

System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.

Part 2 of 2 parts



Integrated, Seamless, Configurable Environmentfor Systems Engineering and Software Development

Degree of “before the factness”static better than dynamicInherent (by way it is defined) better than staticBetter yet, not having to define it at all

Requirements CaptureDocument ParsingUse CasesInputs from other tools

Analysis

Generation

Simulation/Testing/Execution

FormalDefinition

Real-time/DistributedSystem SimulationDynamic BehaviorTime, Cost, Risk, ...Resource Utilitization

Configurable OutputGenerationC, C++, C#,Java, HAL/ SEnglish, ...UNIX, LINUX, ...Embedded C, VxWORKSFirmware (Micro-HAL)outputs to other tools

*

CommunicationsAsync Serial IOAnalog IODiscrete IOTCP/ IPSSL

Graphics/GUILED/ LCD DisplaysMotif/ Xt/ XlibOpenGLAWT, Swing

DBMSOracle, VersantDistributedClient/ ServerSQL

GeneralLegacy CodePortable Standard LibrariesOperating System ServicesConfiguration ManagementInternet Services (J2EE)

OpenArchitectureInterfaces

* Automatically Generated DocumentationUser-Customizable FormatsRequirements Analysis, Functional SpecificationsDesign Documents, Metrics, CM

Automatically Generated CodeIntegrated, Complete (100%), Production-ready for any kind of systemDistributed/ Shared/ Real-time, Client/ Server, Graphics, User-interfaceCommunications, Scientific, Internet, Database, Manufacturing

*

ReuseLibraries

ReuseLibraries Formal

Def inition A nalysisG eneration

Simulation/Testing/Execution


The Heart and Soul of Apollo:Doing it Right the First Time

MAPLD International ConferenceSeptember 9, 2004

Margaret H. HamiltonHamilton Technologies, Inc.

Much of the material contained in thispresentation is based on work sponsored

by the Deeply Integrated-Guidance Navigation Unit (DI-GNU) program, U.S.

Army ARDEC, Picatinny Arsenal, NJ

Images on Slide 1 and this Slideare from The Apollo PropheciesCopyright © Nicholas Kahn &

Richard Selesnick

Copyright © 1986 - 2004 Hamilton Technologies, Inc. (8-24-04)
