• Home
• About Us
• Services
• Products
• Contact

The AdAPT architectural blueprint was introduced to ASF clients in 1996.

The ASAP process blueprint was introduced to ASF clients in 1996.

Advanced Application Partitioning Tools

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:

• pattern-based component library that reduces development time, decreases maintenance costs and preserves legacy value
• Problem Domain components for true application partitioning and distributed business objects
• User Interface components that support a variety of user interface styles and industry standards
• System Management components
• a layered architecture that promotes reuse and design standards
• complete documentation and object models of each component for use with Rational Rose

The Problem Domain Partition

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.

• ASFBusinessContext class provides the basic mechanisms needed to orchestrate multiple business entities to solve context-specific problems. It also provides the public interface to the rest of the business-related objects. Decoupling of business classes from other application classes enhances the reusability of business-related classes.
• ASFBusinessEntity embodies real business objects for the application.
• ASFBusinessRule class provides flexible, rule-based behavior to both the ASFBusinessContext and ASFBusinessEntity classes.

The User Interface Partition

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

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.

• AdAPT Manager is a class that provides the ability to maintain a list of objects by registration.
• AdAPT Resource class provides a common interface to any of the three most common methods of providing information during program execution: 1) initialization files 2) registries and 3) database tables.
• AdAPT Controller class provides the base class for application controllers. A controller accepts messages, interprets them and then directs objects to perform certain tasks.

The Kernel

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:

• Adapters -- Objects that provide a common, public interface to another system or component. An adapter is a two-way translation device that takes standard commands and events from an application or component, and translates them into specific messages or function calls to a server system or other component.
• Object Factories -- Responsible for creating objects. Specific object factories create related or dependent objects. They allow the developer to specify objects to be created while maintaining a loose coupling between the requesting object and the created object.
• Facades -- Objects that act as the public interface to a complex subsystem of objects. A facade also routes messages from objects external to the subsystem to objects within the subsystem. They simplify the interface between a subsystem, and define the public component interface for implementation using DCOM or CORBA.
• Containers -- Objects that hold and manage lists, groups or sets of other objects or data structures. A container's member elements then can be accessed through iterator objects defined for the container.

The Component Layer

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.

The Framework Layer

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.