© 2003, 2004, 2005 Bedarra Research Labs. All rights reserved. Some of My Best Friends Still Use Objects?! Objects are too hard for normal people, including

© 2003, 2004, 2005 Bedarra Research Labs. All rights reserved.

Some of My Best Friends Still Use Objects?!

Objects are too hard for normal people, including many people who supposedly know them!!

Object think is artificial for many computations which are better described through function composition, algorithms, transformations, rules etc.

Objects are too cumbersome and slow for current machines to execute them efficiently

Objects are a modeling, meta data concept, but a bulky and computationally expensive runtime abstraction.

Objects at runtime suffer an acute impedance mismatch with memory and storage

Objects need a little HW support, but never get it

www.dreamsongs.com/ObjectsHaveFailedNarrative.html


AOP Democrats and Republicans

Smart Macro Programming

Lisp/Smalltalk Hackers

Code Snatchers

Interception = Interrupt, exception programming

AOP Improves Systems Software

AOP Is a software engineering best practice

AOP is Next OO – AO Programmer Wanted $300K

AOP is right, it they don’t get it their stupid or just don’t get it.


Transitioning AOSD from Research Park to Main Street

Challenges and Opportunities

Dave [email protected]

www.davethomas.net

Bedarra Research Labs

Carleton University and University of Queensland

mailto:[email protected]

http://www.davethomas.net/


Overview

• Complexity of Application Development Today

• Challenges of Application Development 2010

• Experiences Selling New Technology

• AOSD Works!

• AOSD Analysis and Design

• AOSD Software Engineering

• AOSD Speculation

• AOSD Research


The Challenges of Current Generation Application Development

Life In Middleware USA - The OO API Field Of Dreams

Latent Technical Complexity

Accidental Complexity

Open Source from OS to Application allow every customer application to be “unique”!

=> Creates An Immense Tool and Services Opportunity To Make An Even Bigger Layer CAKE!


The Complexity of Software Technology

Latent Complexity Of Technology Objects, Components, Interfaces, Patterns, AOP, MOF,

UML, Java/C#, XML, Web Services, Scripting, Messaging, Transformations…

Crossed trained in the essence of enterprise applications and their customization

Requires MSc or PHD ++

Gratuitous technical complexity for simple problems

“The Impedance Imperative – Tuples + Objects + Infosets = Too Much Stuff!”, in Journal of Object Technology, vol. 2, no. 5, September-October 2003, pp. 7-12. http://www.jot.fm/issues/issue_2003_09/column1

http://www.jot.fm/issues/issue_2003_09/column1




The Complexity of Software Technology

Accidental Complexity Schemata, protocols, languages, libraries, tools,

platforms, enterprise applications, middleware, standards, security, reliability, interoperability

Multiple technologies with 100s of APIs Requires extensive expert level experience with

platform technologies Integration requires EAP expertise in addition to

platform expertise

Complex and bug ridden libraries "The Deplorable State of Class Libraries", in Journal of Object

Technology, vol. 1, no. 1, May-June 2002, pp. 21-27, http://www.jot.fm/issues/issue_2002_05/column2

Flagrant disregard for limited resources Embedded Java, XML and SOAP …

http://www.jot.fm/issues/issue_2002_05/column2/column2


The Skills Gap

Focus on short-term knowledge (certification) versus professionalism (competence).

IT employers increasing hiring platform specific single language 3 year graduates and vendor certification.

Program specialization and compression (3 years) means that graduates have little application context and are essentially “blue collar programmers”.

Computational competency and programming languages has reduced stature in ACM and IEEE programs and there is a distinct lack of appreciation for computational diversity.

Decreased enrollments in graduate CS/SE programs and hence the availability of competent.

Lack Of Application Domain Knowledge in CS/SE Graduates


The Challenges of Next Generation Applications

Business Driven vs. Technology Driven Based on sound and deep understanding of the

business Complexity mandates inter-disciplinary collaborative

definition and development driven by business experts First Time Applications vs. Traditional Processes

Improvement Support For High Performance Teams Enterprise Application Platforms (SAP, PeopleSoft…) vs.

Technology Platforms (J2EE, .NET, Unix, Mainframes)


The Challenges of Next Generation Applications

Real-time Business Development in Real-time Execution in Real-time Massive Amounts Of Data

– 3D Data – semi-structured numeric, text, multimedia Processors, Memory, Bandwidth and Storage are “free”

– 100s to 1000s of processors– Multiprocessing and Memory System On Chip– Gaggles of Memory and Disk Storage– Dynamically Reconfigurable Systems


Experiences Selling New Technology

This is exactly the same as you have been doing it all along except that it is completely different!

• Sell concept and benefits relating to current/previous practice – avoid the language/tool debate

• Illustrate with an example which makes sense to them

• Address the critics concerns before they ask

• Explain that tools help productivity and quality


Experiences Selling New Technology

This is exactly the same as you have been doing it all along except that it is completely different!

Early Adopters Pull the ideas, tools and move aggressively aheadWill inflate your most conservative claimsWill alienate others inside their companyPosition between the early adopter and those who fear/oppose

them

Later Adopters Have a long list of questions they just need to have answered Often have very different skills and must less software

engineering experience than any AOSD attendee can imagine Want standards, customer references, case studies and

insurance of major vendors/ISVs


“AOSD Inside” Works!• Encourage Separation of Concerns as a Best Practice

• Encourage Role/Subject Modeling

• Refactor to improve maintainability of large complex products – e.g. middle ware

• Refactor to improve usability of large complex products - e.g. middleware

• Manage Variability of Product Line Assembly/Deployment

J2EE desperately needs an industry standard Aspect Library to provide a simpler programming model.

Java desperately needs a better model than J2EE


AOSD Analysis and Design

• Revive an understanding or Role Modeling, Interfaces

• Provide an implementation of Use Case Extensions

• Require a revision to UML and associated tool chain

• What does A/D mean in the presence of Aspect libraries

• What does it mean w/respect to Architecture


AOSD Software Engineering

• Who, where, when should AOP be applied?

• What does unit testing, acceptance, regression testing mean in the context of aspects?

• How can we avoid the problems we found with before, after, doesNotUnderstand etc. in large Lisp and Smalltalk programs?

• How does one debug at the level of the abstract – can powerful tools really fix a bad language or platform?


AOSD Software Engineering

• When do we need an aspect language vs. an aspect transformer vs. an aspect runtime?

• Are there a useful subset of AOSD that can be implemented via existing OO mechanisms? E.g. Envy/Developer, AspectJ2EE

• Is there “standards” of practice and convergence of key concepts?

• Are some problems better solved using non OO languages/techniques – e.g. dependencies?


AOSD Education

• Teach Computational Reflection ( SCIP+, AMOP-) Functional Programming Design Patterns Meta Object Protocols big ideas behind AOP/SEP Separation of Concerns

• Teach Program Transformation

• Where in the curricula should we teach Aspect Programming?


AOSD Predictions

• AOSD will at a minimum be a master craftsman tool for systems programmers. It isn’t clear that AOP will be “outside” for application developers?

• AOP will likely find success in software product engineering vs. application development in the same way that OO CBSE has.

• Aspect Libraries should increase the use, and also reduce the need for aspect developers in favor of aspect users.

• AOP Analysis and Design will find a slow adoption, and may get stuck behind UML 2.

• Teaching AOSD concepts - Separation Of Concerns, Role Modeling and Meta Object Protocols may find a resurgence. AOP will be a challenge to position in undergrad curriculum


AOSD Predictions

• Language neutral tools will find better acceptance than new languages. <yuck @ wins \yuck>

• AOP in every language is easy but not interesting. e.g. AspectJavascript.

• AOSD tools will fill current gaps e.g. true OO - > AOP Refactoring, AOP tools for AOP users.

• AOP “load/deployment” time will become the preferred implementation

• AOP OS and VMs will remain a research topic for at least another generation of commercial VMs


AOSD at The Edge of Something Deeper?!

• What formal machinery can be usefully bring to bare on AOP?

• Does the holy grail of a declarative reflective language philosophized by Brian Smith really exist?

• AOSD suggests we may be closer to true meta programming? – program composition of fragments of requirements, design, code into programs. e.g. Hyperspaces, Feature Oriented Programming, Beta


References

"Computational Diversity, Practice and a Passion for Applications”, in Journal of Object Technology, vol. 2, no. 3, May-June 2003, pp. 7-12. http://www.jot.fm/issues/issue_2003_05/column1

"Reflective Software Engineering - From MOPS to AOSD, in Journal of Object Technology, vol. 1, no. 4, September-October 2002, pp. 17-26. http://www.jot.fm/issues/issue_2002_09/column1

"Refactoring as Meta Programming?", in Journal of Object Technology, vol. 4, no. 1, January-February 2005, pp. 7-11. http://www.jot.fm/issues/issue_2005_01/column1

MDA: Revenge of the Modelers or UML Utopia? <http://www.martinfowler.com/ieeeSoftware/mda-thomas.pdf>




http://www.martinfowler.com/ieeeSoftware/mda-thomas.pdf



Documents

© 2003, 2004, 2005 Bedarra Research Labs. All rights reserved. Some of My Best Friends Still Use Objects?! Objects are too hard for normal people, including