Steps to Developing SAS/AF Applications

Step 1: Analyze the Problem or Business Process

Begin a development project by conducting an analysis to discover the key issues of the problem. Such an analysis enables you to understand and describe the problem, which promotes the mapping of the issues and their relationships to your application's components. The purpose of object-oriented analysis, then, is

to define the boundaries of the problem domain so that you know what the application will do (and what it will not 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

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 issues 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 might include executives, managers, accountants, clerks, and auditors. Concepts such as “balance sheet” and “invoice” can be easily understood, but a process such as “consolidate balance sheets” can mean different things to different user groups. Executives might be interested in the bottom line, whereas auditors might focus more on the details of the consolidation process.

The outcome of an analysis phase is typically a requirements document. In some cases, it might be important to prepare simple class diagrams that provide an overview of what each object 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.

Step 2: Set Up the Development Environment

Considerations When You Are Planning a New Application

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 need to license?

Creating Common SAS Libraries and Catalogs

You might 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 the common entry types that you are likely to use in your SAS/AF applications.

SAS/AF Entry Types

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 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 might need to access entries in several SAS catalogs that might 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 hardcoded SCL entry names such as classes — between different environments. For details on catalog concatenation, see the SAS Language Reference: Concepts. For information about the use of libraries and catalogs when you deploy applications, see Step 6: Deploy Your Application.

Using Existing SAS Components

Your organization might 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. For more information, see Deploying Components.

Licensing SAS Software Products

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

Step 3: Design and Develop 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 about using SAS/AF software to design and implement classes, see Part 3: Developing Custom Components. For information about making the components that you create available for use, see Deploying Components.

Step 4: Develop the Application

Overview of Developing Applications

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 about using SAS/AF software to develop applications, see Part 2: 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, and a frame that enables the user to complete those tasks. For information about building frames, see Working with Frames.

Adding Communication Between Frames and Components

Your application design might specify that the components on a frame, or even the frames themselves, need to work with each other. For example, you might want a graphic object to display a specific graph when a user selects a graph from a list box. Or, you might 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 about SCL, see Adding SAS Component Language Programs to Frames. For more information about SCOM, see Communicating with Components.

Designing for Reuse

If you notice that several of your frames share common traits, you can create a composite object that includes those traits. For example, you could create a dialog box frame that included OK, Cancel, and Help buttons. For more information about composites, see Re-using Components.

Step 5: Compile and Test Your Application

Testing SCL Programs with Frames

When 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 might also consider assembling all application components and performing integrated testing.

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

Testing the Usability of Your Application

Although your application enables users to perform all the tasks that they need to complete, it might still be difficult to learn or to use. Just as the early analysis phase encourages input from users, you might 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 might arise from difficult concepts or business processes. There are many different types of usability testing, ranging from user exploration of the application to formal testing that assesses validity and usability.

Step 6: Deploy 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 about application deployment issues, see Deploying Your Applications.