ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications smoothly into Java implementation code. For demonstration purposes the authors applied ArchJava to Aphyds, a moderate-size circuit design application with ~12,000 lines of code.
There appears a common theme among the existing tools and languages -- failure to ensure or enforce communication integrity. This include architecture design languages (ADLs), module interconnection languages (MILs), CASE tools, and component infrastructures such as COM, CORBA, and Java Beans all fail to be satisfactory according to the authors.
If a development team is not applying the concepts and guidelines of agile development, I could see where ArchJava might provide a benefit. The time spent time on adapting and integrating with ArchJava could have been spent on the design decisions. Development teams could do a little upfront design to hash out some of the architecture and the rest would be resolved through the use of pair programming. Could peer code reviews provide the inherent benefit of "ensuring communication integrity" instead of additional complexities presented in ArchJava?
I have to question whether or not ArchJava has been put on the back burner as the little no verifiable activity or maintenance releases since version 1.3.2 in June 2005. It is hard to win over an audience when there is little progress being made.
As a newbie to ArchJava or anything similar, I would be hesitant to use Java extensions for this purpose. This is just my opinion without and actually reaping the benefit myself. There have been many successful development projects that did not use ArchJava. However, it is unknown if those same successful projects ensured communication integrity throughout the source code.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment