Applications Development Methodology

Steps to Developing SAS/AF Applications

Use the following steps as a guideline when creating a SAS/AF application:

Analyzing the problem or business process.
Setting up the development environment.
Designing and develop components.
Developing the application and implement the components.
Compiling and testing the application.
Deploying the application.

Analyzing the Problem or Business Process

You can begin an applications development project by conducting an analysis to discover the key concepts that pertain to the problem. Such an analysis enables you to understand and describe the problem, which promotes the mapping of these concepts and their relationships to your application's components. The purpose of object-oriented analysis, then, is

to define the boundaries of the problem domain to specify what the application will do
to describe the problem domain in terms of objects and classes, and to determine what services the objects and classes must provide
to identify relationships between the objects in the problem domain, especially from the perspective of different types of users.

In short, the objective of the analysis is what, not how.

When you model a problem or business process, it is important to consider all potential users of the application. Such consideration promotes cross-functional input and a more complete understanding of the problem. The terminology and concepts that describe the problem lead to new process concepts that enable you to better meet the needs of the users.

For example, consider the problems and business processes that underlie a financial application. Users may include executives, managers, accountants, clerks, and auditors. Concepts such as "balance sheet" and "invoice" may be easily understood, but a process such as "consolidation of balance sheets" may have different connotations to different user groups. Executives may be interested in the bottom line, whereas auditors may focus more on the details of the consolidation process.

The outcome of an analysis phase is typically a requirements specification document. In some cases, it may be important to prepare simple class diagrams that provide an overview of what the application should do. There are many formal object-oriented methodologies as well as a number of commercial products that can assist you in the design process.

Setting Up the Development Environment

As you begin planning a new SAS/AF application, consider the following:

Will you need to create a common SAS library or use a combination of new and existing libraries to access the application, its classes, and the data that it requires?
How will you reference SAS catalogs and catalog entries during the development and deployment of your application?
What SAS software products will end users have to license?

Creating SAS Libraries and Catalogs

You may consider setting up a common SAS library and appropriate catalogs for an applications development project. Often, this makes it easier for your development team to locate, share, and store the SAS catalog entries that your application requires.

You can store a mixture of entry types in a SAS catalog. The following table lists some of the more common entry types that you are likely to use in your SAS/AF applications.

Entry Type	Description
CLASS	Stores the properties that define a class.
FRAME	Stores the properties that define a frame.
INTRFACE	Stores the definition of an interface, which is a group of abstract methods that are shared by related classes.
KEYS	Stores function key settings.
PMENU	Stores the code that defines a pull-down menu.
RANGE	Stores the definition of a range of values. Range entries can define ranges for both numeric text-entry fields and critical success factor (CSF) controls.
RESOURCE	Stores the definition of a resource, which typically includes a group of related classes.
SCL	Stores SCL program code.

You can also use library or catalog concatenation so that you can access entries in multiple libraries or catalogs by specifying a single library reference name (libref) or a catalog reference name (catref). If you create a catalog concatenation, you can specify the catref in any context that accepts a simple, nonconcatenated catref.

For example, you may need to access entries in several SAS catalogs that may be designated as the development, test, and production areas. The most efficient way to access the information is to logically concatenate the catalogs, which allows access to the information without creating a new catalog. The following statement assigns the catref app to development, test, and production catalogs:

catname app (corp.app mis.testapp projects.newapp);

In this example, corp.app is the production environment, mis.testapp is the testing catalog, and projects.newapp is the development area.

Catalog concatenation is useful when you need to migrate catalog entries -- particularly those that have hard-coded SCL entry names such as classes -- between different environments. For details on catalog concatenation, see SAS Language Reference: Dictionary. For information on the use of libraries and catalogs when you deploy applications, see Deploying Your Application.

Using Existing SAS Components

Your organization may already have a number of existing custom SAS components available. If you plan to use any of these custom components in your new application, then you should consider how the classes are grouped and made available in a resource. See Deploying Components for more information.

Licensing SAS Software Products

When you create an application, you may use the functionality of different SAS software products. Or, you may develop objects (such as a graph or an MDDB) that require other SAS software products in order to operate. In either of these cases, you must ensure that your end users license all the SAS software products that they need for your application to run.

Designing and Developing Components

The object-oriented design phase of the development life cycle is often focused on the work of component developers or "class writers." As a component developer, you can define how the elements of the application work. During this phase, you can detail and describe

the services provided by each class
the actual name, data type, and default values of class attributes
any class relationships -- especially inheritance
the business rules that govern object behavior
other features that are specific to SAS software. See SAS Object-Oriented Programming Concepts for details.

You can construct classes in terms of their attributes and behaviors. For complete information on using SAS/AF software to design and implement classes, see Part IV: Developing Custom Components. For information on making the components that you create available for use, see Deploying Components.

Developing the Application

This phase of the development life cycle is where application developers build the system or application, using the objects that have been created by component developers. For complete information on using SAS/AF software to develop applications, see Part III: Developing Applications.

Designing the User Interface

You can use any one of a number of modeling tools and flow chart techniques to help determine how many windows your application will need, as well as how the user should interact with each window and how the windows should be connected to each other.

Consider the tasks that a user needs to perform in a window, then build a frame that enables the user to complete those tasks. For information on building frames, see Working with Frames.

Adding Communication Between Frames and Components

Your application design may dictate that the components on a frame, or even the frames themselves, need to work with each other. For example, you may want a graphic object to display a specific graph when a user selects a graph from a list box. Or, you may want the user to open another frame when a push button is selected. You can add component and frame communication either by using SAS Component Language (SCL) programs or by taking advantage of the features included in components that have been built using the SAS Component Object Model (SCOM) architecture.

For more information on SCL, see Adding SAS Component Language Programs to Frames. For more information on SCOM, see Communicating with Components.

Designing for Reuse

After you build a few frames, you may begin to notice that your frames share some common traits. For example, most of your frames of type dialog may include OK, Cancel, and Help buttons. Common components can be combined to create composites. For more information on composites, see Re-using Components.

Compiling and Testing Your Application

If you use SCL programs with the frames of your application, you must compile and test your frames. You can perform debugging and unit testing as well. Once all of the individual pieces are working, you may also consider assembling all application components and performing integrated testing.

For information on compiling and testing, see Compiling and Testing Applications.

Testing the Usability of Your Application

Your application may enable users to perform all the tasks that they need to complete, but it may still be difficult to learn or to use. Just as the early analysis phase encourages input from users, you may want to revisit the design by having users test the application during its development. Usability testing enables you to enhance or correct usability issues that may arise from difficult concepts or business processes. There are many different kinds of usability testing, ranging from user exploration of the application to formal testing that assesses validity and usability. Numerous books and other media are available on the subject to help get you started.

Your usability testing can be used to iterate your design as necessary to correct problems.

Deploying Your Application

Once you have designed, created, and tested your application, you are ready to deploy your application to users. Deploying applications involves many considerations, including how the application should appear when it opens, whether the application will run on a stand-alone machine or a network, and what should happen when the application closes.

For more information on application deployment issues, see Deploying Your Applications.

Top of Page