Upload
cameron-nicholson
View
217
Download
0
Embed Size (px)
Citation preview
1 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
2 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
3 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
4 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
5 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
6 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
7 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
8 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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)
9 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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.
10 S216/MAPLD 2004Hamilton
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"
11 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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".
12 S216/MAPLD 2004Hamilton
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.
13 S216/MAPLD 2004Hamilton
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
14 S216/MAPLD 2004Hamilton
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.
15 S216/MAPLD 2004Hamilton
Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
16 S216/MAPLD 2004Hamilton
™
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
17 S216/MAPLD 2004Hamilton
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.
18 S216/MAPLD 2004Hamilton
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
19 S216/MAPLD 2004Hamilton
Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
20 S216/MAPLD 2004Hamilton
001AXES™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
21 S216/MAPLD 2004Hamilton
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,
23 S216/MAPLD 2004Hamilton
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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?
24 S216/MAPLD 2004Hamilton
FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
25 S216/MAPLD 2004Hamilton
001AXES™, TMaps™, EMaps™, FMaps™ and Executor ™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
26 S216/MAPLD 2004Hamilton
FMap™ and TMap™ are 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:
27 S216/MAPLD 2004Hamilton
FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
28 S216/MAPLD 2004Hamilton
Primitive Control Structure™ and FMap™ are trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
29 S216/MAPLD 2004Hamilton
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.
31 S216/MAPLD 2004Hamilton
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
Copyright © 1986 - 2004 Hamilton Technologies, Inc.
32 S216/MAPLD 2004Hamilton
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.
33 S216/MAPLD 2004Hamilton
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.
34 S216/MAPLD 2004Hamilton
OMap™, TMap™, EMap™ and FMap™ are all trademarks of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
35 S216/MAPLD 2004Hamilton
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
36 S216/MAPLD 2004Hamilton
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
37 S216/MAPLD 2004Hamilton
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.
39 S216/MAPLD 2004Hamilton
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
40 S216/MAPLD 2004Hamilton
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.
41 S216/MAPLD 2004Hamilton
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
42 S216/MAPLD 2004Hamilton
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
43 S216/MAPLD 2004Hamilton
Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Copyright © 1986 - 2004 Hamilton Technologies, Inc.
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
44 S216/MAPLD 2004Hamilton
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)
44 S216/MAPLD 2004Hamilton