The AdAPT architectural blueprint was introduced to ASF clients in 1996.
Austin Software Foundry released the first version of its AdAPT architectural bluebrint in 1996
to provide its clients a partitioned and layered software architecture.
Effective, object oriented development requires a well-developed architecture. A partitioned architecture enables developers to derive maximum benefit from object oriented technology. Its fundamental value lies in creating discrete, loosely coupled components with minimal interdependencies.
AdAPT had its foundation in the preceeding 5+ years of software development undertaken by Austin Software Foundry for its Fortune 1000 clients. AdAPT has benefited from Austin Software Foundry's subsequent 10+ years of software development experience.
Austin Software Foundry released the first version of its ASAP software development process blueprint in 1996 to provide its clients with a jump start on an agile, iterative development process that is matched to a partitioned approach to software architecture.
One of the largest obstacles to implementing flexible, defined software development processes is the amount of time and experience required to develop a critical mass of organizational knowledge and experience. In order to jump start this process, ASAP provides a core library of training and mentoring materials, process definitions, templates, artifacts and examples. ASAP gives an application development organization a consistent, sound and customizable process foundation.
ASAP had its foundation in the preceeding 5+ years of software development undertaken by Austin Software Foundry for its Fortune 1000 clients. ASAP has benefited from Austin Software Foundry's subsequent 10+ years of software development experience.
The ASAP process blueprint was introduced to ASF clients in 1996.
Effective, object-oriented development requires a well-developed architecture. A partitioned architecture enables developers to derive maximum benefit from object-oriented technology. Its fundamental value lies in creating discrete, loosely coupled components with minimal interdependencies. AdAPT provides a partitioned and layered architecture with the following characteristics:
The Problem Domain Partition focuses on business models. This is the area in which business events and rules are included in the application. Business models handle requests captured in the user interface and coordinate other system components to satisfy those requests.
The User Interface Partition provides the means by which the user manipulates the system. Many products on the market provide a range of UI mechanisms and controls. However, they rarely are well-encapsulated. In fact, the class structures often encourage developing business rules within UI controls and windows. This violates good object-oriented design and reduces object reuse. The AdAPT GUI classes do not replace these controls; they just enhance their object-oriented features.
Objects within the user interface partition use a standard method within the application to interface with objects in the other partitions. Examples are the Model-View-Controller Kit, the Publish and Subscriber Pattern Kit and the Multiple Document Interface (MDI) Kit.
The system management partition focuses on application services and connections to external systems. Application services are those components used throughout the application. External systems include database management systems and external server applications.
The Kernel Layer in AdAPT provides a set of common classes that are non-partition specific. These are typically utilities and data structures used repeatedly throughout all applications; traditionally, they have been recreated for each application. Either root classes or abstract data types, they are commonly inherited from, but rarely instantiated themselves. The key kernel classes that provide AdAPT with its unique flexibility are:
Built from the foundation provided in the kernel layer, the component layer is where individual classes are combined to create stand-alone modules. Each of these stand-alone modules provides a single distinct function or behavior, related to the user interface, problem domain or system management partition. Once a module is defined from AdAPT classes, it then can be packaged for use as a PBD, DLL or JAR, or in any of the industry-standard component models such as CORBA, DCOM/Active X, Enterprise JavaBeans, SOA or WOA.
Achieving high levels of reuse has been an elusive goal for many organizations, even as they adopt object-oriented software development processes and techniques. One of the most significant problems these organizations encounter is an attempt to reuse very fine-grained artifacts, such as individual classes and objects. This results in extremely large libraries, difficulty searching for and finding appropriate classes, and a lack of guidance regarding how individual classes should be combined.
Conversely, a recent focus on "services" as in "service-oriented architecture" has caused a degeneration of software architecture into the days of procedural or function-oriented programming. This approach has lead to tightly coupled components very difficult to reuse outside of the application or context in which they were developed.
The key to improving this situation is providing developers with larger-grained artifacts to reuse, using predefined combinations of classes and components, while still respecting the bounds of user interface, problem domain and system management partitioning. AdAPT kernel classes and components are combined into frameworks that represent combinations of entire ranges of behavior into discrete, reusable "kits." Application developers then can combine these kits quickly to solve development problems in a fraction of the time it would take, even using object-oriented development techniques.
Copyright 1989-2008 Austin Software Foundry, Inc.