Transcript Document

Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
1
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
2
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
3
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
4
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
5
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
6
S216/MAPLD 2004
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
7
S216/MAPLD 2004
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)
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
8
S216/MAPLD 2004
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.
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
9
S216/MAPLD 2004
Note 1: no software errors known to occur during flight
Note 2: majority of 44% found by "Nortonizing"
001™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
10
S216/MAPLD 2004
Root problem: traditional system
engineering and software
development environments support
users in "fixing wrong things up"
rather than in "doing things in
the right way in the first place".
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
11
S216/MAPLD 2004
Solution: Development Before the Fact
A new paradigm: define each system with inherent
properties ("come along for the ride") that support its own
development.
• 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.
Hamilton
12
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
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
Development Before the Fact™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
13
S216/MAPLD 2004
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.
Universal Systems Language™ (USL™), 001AXES™ and Development Before the Fact™ are trademarks of Hamilton Technologies, Inc.
Hamilton
14
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
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 was
defined properly
•Generate automatically a complete, integrated, fully
production ready software implementation/simulation/
documentation for the architecture of choice consistent
with the model
– Process is iterative/recursive
– Can be parallel, asynchronous or
incremental
– Can be used for rapid prototyping
or for production ready, full scale
development
•Execute the model
•Deliver the real system
Development Before the Fact™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
15
S216/MAPLD 2004
001 is used
to make System Oriented
Objects, each of which is
based upon a unique
concept 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
001™ and System Oriented Objects™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
16
S216/MAPLD 2004
DBTF Philosophy:
Reliable Systems are Defined
in Terms of Reliable Systems
• Use only reliable systems
• Integrate these systems with
reliable systems
PRIMITIVE
SYSTEMS
• The result is a system(s) which is
reliable
ABSTRACT SYSTEMS
• Use resulting reliable system(s)
along with more primitive ones
to build new and larger reliable
systems
MORE ABSTRACT SYSTEMS
A recursively reliable and reusable process
Development Before the Fact™ (DBTF™) is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
17
S216/MAPLD 2004
Every SOO is Defined with the Building Blocks of 001AXES
Model Functional Behavior (Time)
with Function Map (FMap)
Model Type Behavior (Space)
with Type Map (TMap)
Ultimately in terms of 3 primitive control structures
Control Structure
Constraint
Function
Type and its methods
Objects (Members of Types)
Relations
All model viewpoints can be obtained from FMaps and TMaps. Maps of functions are by their
very nature integrated with maps of types *
A system is defined from the very beginning to inherently integrate and make understandable
its own real world definition
* A map is a hierarchical network of interrelated objects under control
SOO ™, 001AXES™, Function Map™ (FMap™) and Type Map™ (TMap™) are trademarks of Hamilton Technologies, Inc.
Hamilton
18
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
19
S216/MAPLD 2004
001AXES™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
20
S216/MAPLD 2004
Systems Defined in Terms of the Primitive Control Structures
Result in Properties for Real Time Distributed Environments
Every parent has a higher priority and
Behaves as a master scheduler for its children
A system is defined from the very
beginning to inherently maximize its
own flexibility to change and the
unpredictable and to capitalize on
its own parallelism
Every object has a unique parent and
is under control
Every system is event-driven
Concurrent patterns can be automatically detected
Every object has a unique priority
Each object and changes to it are traceable
Each object can be safely reconfigured
("pluggable" and "unpluggable")
Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
21
S216/MAPLD 2004
A system is defined from the
very beginning to inherently
maximize the potential
for its own reuse
definition of structure:
y , y = Coinclude?(x)
b a
J
I
Syntax defines an
interface (template)
for families that want
to use the structure’s
hidden functionality
J
J
y = B? ( x )
b
b
y = A? (x a )
a
syntax (template) for its use:
y , y = Coinclude?(x)
b a
CI
y = B? ( x )
b
b
Hidden functions
to be applied
when used as
a structure
example of its use:
replace:
Coinclude?
with Process
A? with TaskA
B? with TaskB
y = A? (x a )
a
b1,a1 = Process(b,a)
CI
Use contains
common pattern of
hidden functions
b1 = TaskB(a) a1 = TaskA(b,a)
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
22
S216/MAPLD 2004
An Async Structure and its Use
(Distributed, Synchronous and Asynchronous Behavior)
Structure:
A,B = Async?(A0,toA0,B0,toB0)
hidden functions
used to coordinate
independent functions
that communicate at
each Async iteration
O
J
I
A,B = Async(A1,toA1,B1,toB1)
CI
apply recursively
A1,toB1 = A?(A0,toA0)
Syntax:
A,B=Async?(A0,toA0,B0,toB0)
Use:
B1,toA1 = B?(B0,toB0)
C,M=Steer_missile(C0,M0)CC,CJ
Async: isDone?
M=intoMissile(F)
A1,toB1=A?(A0,toA0)
C,F=ControlSteering(C0,pos0,fin0,cmd0)
B1,toA1=B?(B0,toB0)
A and B to work independently. Each has
its own independent variable and a
dependent variable for passing
information to the other
pos0,fin0,cmd0=initialize(M0)
Async: areCommandsDone
rotatedFin,pos=Turn_fin(fin0,cmd0)
C1,nextcmd=ControlFin(C0,pos0)
Controlled System
Controlling System
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
23
S216/MAPLD 2004
FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
24
S216/MAPLD 2004
001AXES™, TMaps™, EMaps™, FMaps™ and Executor ™ are all trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
25
S216/MAPLD 2004
Periodic Processing Using a Timed Interrupt
FMap Structure:
db=processPeriodically:DB(db0,from) CJ*2
c,t=view:clock,period,DB(db0)
end=at:time,clock(c,t)
db=RUN(db0,from,end)
CO:is:present,any(from)
db=__(db0,from)
processPeriodically:DB
db1=F(db0)?
withClockPeriod
PGM
clock
period(time)
DB?
...
Navigation
(withClockPeriod)
navigationDB
__(withClockPeriod)
db=do_again(db0,from) CJ
Syntax:
Use:
Syntax:
db=end_of_period_or_not(db0,from,end)
CO:is:present,any(end)
db1=F(db0)?
db=RUN(db1,from,end)
db=cl1(db0)
db=incorporate_msgs(db0,from)
TMap Structure:
DB?
Use:
guidanceDB
N=manage_navigation(N0,fromCCC)
processPeriodically:navigationDB
...
Control
(withClockPeriod)
N1=navigation(N0) J
controlDB
G0,fromN=do_navigation(N0)
G=manage_guidance(G0,fromN)
processPeriodically:guidanceDB
manage_navigation, manage_guidance, and
G1=guidance(G0) J
manage_control each interrupts its child when
fromCCC, fromN and fromG respectively arrive.
Each of these parent functions coordinates
C0,fromG=do_Guidance(G0)
between its child and parent function in order to
C=manage_control(C0,fromG)
repeat its local cyclic interval period.
Real Time Schedule Characteristics
guidance
...
...
control
...
navigation
processPeriodically:controlDB
C1=control(C0)
FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
...
Guidance
(withClockPeriod)
control runs an autopilot to
manage missile controls
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
26
S216/MAPLD 2004
FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
27
S216/MAPLD 2004
Primitive Control Structure™ and FMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
28
S216/MAPLD 2004
Theater Defense (cont.)
TMap™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
29
S216/MAPLD 2004
Architecture Independent Operating System™ (AIOS™), RAT™, DXecutor™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
30
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
Separating the Function, Allocation and Resource Architectures
Resource and Allocation Architectures
Function, Resource and Allocation
Architectures as Separate Definitions
D1,C1,B1,A1,sam2=Transfer2Blocks(D,C,B,A,sam)
Functional Architecture
CC
D1,C1,B1,A1=Transfer2Blocks(D,C,B,A)
B1,A1,sam1=TransferBlock(B,A,sam)
D1,C1,sam2=TransferBlock(D,C,sam1)
D1,C1,sam1,B1,A1,joe1=Transfer2Blocks(D,C,sam,B,A,joe)
I
B1,A1,joe1=TransferBlock(B,A,joe)
D1,C1,sam1=TransferBlock(D,C,sam)
One or two robots can be used to transfer a
block from region A to region B and then
from a region C to region D.
B1,A1=TransferBlock(B,A)
D1,C1=TransferBlock(D,C)
Allocation Architecture
Where: Transfer2Blocks on 2Robots
Or: Transfer2Blocks on Robot
Resource Architecture
r(Robot)r0
1 Robot Schedule
Transfer
Block
I
J
J
Transfer
Block
r1(...)r0
1 Robot
resource
holding(Hand)r1
r(Block)holding
2 Robot Schedule
r4,r3 (2Robots) r2,r1
Transfer
Block
Transfer
Block
I
r4(Robot)r2
2 Robot
resources
r3(Robot)r1
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
Hamilton
31
S216/MAPLD 2004
Constraints Define Properties about Another System
TMap: Intervals
(OSetOf)
Interval
A. FMaps define constraints on types
Constraints (or Axioms) for type Interval:
B=IntervalConstraints(I) CJ*2
endsOK=EndPointConstraint(I)
Low
(Point)
High
(Point)
sizeOK=SizeConstraint(I)
B=and(endsOK,sizeOK)
B. FMaps define constraints
on 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. by
LowOrHigh) to validate the ordering of Intervals
using either the low or high point of an interval.
LowOrHigh has the value Low when used as a
constraint in create_ordered_intervals
h=moveto:high,Interval(I)
l=moveto:low,Interval(I)
B=LessThan:Point(l,h)
EndPointConstraint states: an interval low point must
be less than and therefore distinct from its high point
C. create_ordered_intervals constrained by both
IntervalConstraints and OrderedBy:Low constraints
Constraint:
OrderedBy:Low(orderedIntervals)="True".
orderedIntervals=create_ordered_intervals(x,y) J
OrderedBy:Low
constrains output
orderedIntervals to be
ordered by its set of
interval low points
unOrdered=create_intervals(x,y)
orderedIntervals=order_intervals(unOrdered)
sort_intervals
partiallyOrdered=order_by_lowest_point(I1,I2)
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 consistant
with those constraints)
TMap™ and FMap™ are trademarks of Hamilton Technologies, Inc.
Hamilton
B=EndPointConstraint(I) CJ*2
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
32
S216/MAPLD 2004
Object Map™ (OMap™), Type Map™ (TMap™), Execution Map™ (EMap™) and Function Map (FMap™) are all trademarks of Hamilton Technologies, Inc.
Hamilton
33
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
OMap™, TMap™, EMap™ and FMap™ are all trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
34
S216/MAPLD 2004
A Road Map (RMap) Defines the Architecture of a System *
in terms of cooperating domain models and their inter-relationships
and supports project management of cooperating team development
* RMap shows integration of and connections
between all the different system components
within an architecture--for example, how
requirements relate to testing system,
user system (i.e., operational
RMap
scenarios), target system
RMap of Projects
of Libraries
Share libraries across and within
projects, and definitions within and
across libraries (within projects)
team development can be
defined as a 001 system
using this architecture
RMap of Definitions
Application
Reqs.
requires
Test
Layered
Primitive Type
validatedby
User Defined
Parameterized Type
FMap
SGT (RAT Specification)
Testing System
User
Defined
Structure
TMap
FMap
Target Application System
OMap
Requirements System
RMaps™, OMaps™, TMaps™, EMaps™ and FMaps™, RAT™ are all trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
35
S216/MAPLD 2004
System Engineering Seamlessly Integrated with Software Development
System Engineering
• Define FMaps and TMaps
for system architecture
• Analyze
• Simulate real-time behavior
(re)Define
Software Development
• Define FMaps and TMaps
for application
• Analyze
• Generate production ready code
• Execute on target
resource/machine
FMaps & TMaps with
- 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
001AXES
Manage/Trace
Requirements and Metrics
with
Analyze
RT(x)
* OMapEditor
used for testing
FMaps & TMa ps with
ANALYZER
Design Changes
and Maintenance
• Revise FMaps and TMaps
• Repeat engineering and/or
development process
Execute *
with machine or
Xecutor
Management
• Organize projects into working libraries
• Manage and trace requirements
• Generate product and process metrics
• Generate specification, design and test
documentation
Generate
from FMaps & TMaps
with RAT
- simulator
(resource architecture metrics)
- interpreter
- meta executive
(fine grained parallelism/
event driven)
A system is defined from the very beginning to inherently maximize the potential
for its own automation and evolution
RT(x)™, FMaps™, TMaps™, Xecutor™, RT(x)™, 001 AXES™, Analyzer™, and RAT™ are all trademarks of Hamilton Technologies, Inc.
Hamilton
36
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
One of the Most Powerful, If Not the Most Powerful Aspect:
the Degree to which Reuse Inherently Takes Place
Inherent and explicit patterns
of reuse provided with
FMaps and TMaps*
Leaf Extension
Recursive, Inherent, Reuse:
Types are Defined
in Terms of Functions;
Functions are Defined
in Terms of Types
Recursion
Structure
TMap
Le afE x
t e nsi on
Lea f Ext ens i on
Re cur s io n
Str uctur e
Re curs i on
Layer
St ruct ure
primitive operations
Layer
Type x
L a
yer
objects
Alternative Layer Implementations
Type m
Type n
FMap
(doing) uses
A layer of primitive Types isolates
the system being specified (the WHAT)
from its possible implementations (the HOW)
functions
objects
TMap
op B
Type y
(being)
op A
* Reuse also provided with RMaps, OMaps, EMaps, RAT
(reusable architecture configurations), OMap Editor, etc.
RMaps™, OMaps™, Omap Editor™, TMaps™, RAT™, EMaps™ and FMaps™ are all trademarks of Hamilton Technologies, Inc. (8-30-04)
Hamilton
37
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
Xecutor™, 001AXES™, RAT™ and AIOS™ are all trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2003 Hamilton Technologies, Inc.
38
S216/MAPLD 2004
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
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)
• 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
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
• 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 the
application (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.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
39
S216/MAPLD 2004
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.
Hamilton
40
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
S216/MAPLD 2004
Part 1 of 2 parts
Some Differences
Traditional (After the Fact)
Before the Fact
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
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
~All found before implementation
~All found by automatic and static analysis
~Always found
System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
41
S216/MAPLD 2004
Some Differences (Cont.)
Traditional (After the Fact)
Part 2 of 2 parts
Before the Fact
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
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
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
~Automatic programming, documentation, test generation,
traceability, integration
~100% production ready code automatically generated for
all and any kind or size of software
~High risk
~Not cost effective
~Difficult to meet schedules
~Less of what you need and more of what you don’t
need
System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
42
S216/MAPLD 2004
Integrated, Seamless, Configurable Environment
for Systems Engineering and Software Development
* Automatically Generated Code
Integrated, Complete (100%), Production-ready for any kind of system
Distributed/Shared/Real-time, Client/Server, Graphics, User-interface
Communications, Scientific, Internet, Database, Manufacturing
Requirements Capture
Document Parsing
Use Cases
Inputs from other tools
Reuse
Libraries
Re us e
Librarie s
F o rm al
D ef initio n
A na ly sis
G ener atio n
Sim ula tio n/
Te sting/
Exe cutio n
* Automatically Generated Documentation
User-Customizable Formats
Requirements Analysis, Functional Specifications
Design Documents, Metrics, CM
Formal
Definition
Analysis
Communications
Async Serial IO
Analog IO Graphics/GUI
Discrete IO LED/LCD Displays
TCP/IP
Motif/Xt/Xlib
SSL
OpenGL
DBMS
AWT, Swing
Oracle, Versant
Distributed
Client/Server
SQL
Open
Architecture
Interfaces
Simulation/
Testing/
Execution
Generation
*
General
Legacy Code
Portable Standard Libraries
Operating System Services
Configuration Management
Internet Services (J2EE)
Configurable Output
Generation
C, C++, C#,
Java, HAL/S
English, ...
UNIX, LINUX, ...
Embedded C, VxWORKS
Firmware (Micro-HAL)
outputs to other tools
Real-time/
Distributed
System Simulation
Dynamic Behavior
Time, Cost, Risk, ...
Resource Utilitization
Degree of “before the factness”
static better than dynamic
Inherent (by way it is defined) better than static
Better yet, not having to define it at all
Development Before the Fact™ is a trademark of Hamilton Technologies, Inc.
Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
43
S216/MAPLD 2004
The Heart and Soul of Apollo:
Doing it Right the First Time
MAPLD International Conference
September 9, 2004
Margaret H. Hamilton
Hamilton Technologies, Inc.
Much of the material contained in this
presentation 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 Slide
are from The Apollo Prophecies
Copyright © Nicholas Kahn &
Richard Selesnick
Copyright © 1986 - 2004 Hamilton Technologies, Inc. (8-24-04)
Hamilton
44
S216/MAPLD 2004