ATM Software Analysis and Design

OMT helps you understand problems and develop solutions

Derek Cheung

Derek works as the software architect in the Advanced ATM system development division of Nortel Technology (Bell Northern Research) in Ottawa, Canada. He has designed and managed various large-scale network and software-development projects. Derek can be contacted at derekc@nortel.ca.

With the maturity of the methodology and its supporting tools, object-oriented analysis and design (OOAD) has replaced structured analysis and design methodology as the dominant methodology in software development. Among all the available OOAD methodologies, the Object Modeling Technique (OMT) developed by James Rumbaugh and others (see Object-Oriented Modeling and Design, Prentice-Hall, 1991) is one of the most widely adopted OOAD methodologies, with more than 20 software vendors producing OMT-based development tools. Because of OMT's problem-abstraction capabilities, it is especially useful for large software-development projects (see my article, "Fax Switch System," Communication International, August 1994).

In this article, I'll examine how you can apply OMT to analyze and develop software for a simple Asynchronous Transfer Mode (ATM) switch. For background information on ATM, see ATM: Theory and Application, by David E. McDysan and Darren L. Spohn, McGraw-Hill, 1995. Since my focus here is on OMT in system analysis and design, I'll not delve into ATM-switch design details.

Requirements

The simple ATM switch I'll develop here has 12 ATM ports, 10 of which are used to connect customer premises equipment (CPE), while the remaining 2 are for network trunk connections to connect the switch to the ATM network. Each port or connection supports 1024 virtual circuits (VC). Signaling messages from a CPE are sent at VC 5. The switch supports only one-way ATM setup-and-release requests from CPEs. Figure 1 shows a typical network configuration using the ATM switch, while Figure 2 illustrates the setup-and-release protocol supported by it (this is the only protocol sequence this switch supports).

When, in Figure 2, CPE-M accepts the connection setup request by responding to a connect message to CPE-B, the ATM switch will set up its ATM fabric for the session and select a free VC (that is, bearer_vc_assigned) for bearer traffic exchange between CPE-B and CPE-M.

As Table 1 describes, there are four distinct development phases with different deliverables in OMT. Each stage adds more detail to the models developed in the system-analysis stage until the models become meaningful for coding. In short, OMT (as with any object-oriented methodology) is a continuous development process based on iterative refinement.

System Analysis

The goal of OMT system analysis is to understand the problems or requirements of the project and develop models that represent what the system will do. Three models-object, dynamic, and functional-are developed during the system-analysis stage, each of which represents the objects and their relationship, dynamic control flow, and functional transformations of the system, respectively.

The object model. This shows the static data structure of the real-world system and organizes it into workable pieces. The object model is the most important model in OMT. It describes real-world object classes and their relationships to each other. Figure 3 shows the object model of the simple ATM switch presented here. Designers must be familiar with the problem domain (in this case, ATM signaling and switching) in order to transform the requirements into an object model, though some methods can help to refine the set until they make sense in the object model. No matter which method is used to develop the object model, none can replace designers' knowledge and experience in that area.

In the object model in Figure 3, the session-manager class consults with the bandwidth- and route-manager classes. It manages many session classes and it interacts with 12 port classes. The bandwidth-manager class controls one ATM-fabric class. The ATM-fabric class has 12 port classes. User- and network-port classes are a kind of port class (inheritance). The port class has 1024 virtual-circuit classes and they are controlled by the ATM-fabric class. The port class is an abstract class; it has no direct instances, but its descendent classes (user- and network-port classes) have direct instances.

The dynamic model. This shows the time-dependent behavior of the system and the objects in it. Normally, message-sequence charts are drawn before producing dynamic models of the classes defined in the object model. Figure 4 illustrates the message-sequence chart of the ATM switch that supports the setup-and-release protocol. Normally, exceptional events are not shown in the message-sequence charts but are detailed in the dynamic models.

Figure 5 is the dynamic model of the session manager. Note that each class defined in the object model should have a dynamic model. The dynamic model of the session manager is self explanatory.

The functional model. This shows how values are computed, without regard for sequencing decisions or object structure. It is normally constructed after the object and dynamic models. Figure 6 is the functional model of the simple ATM switch.

There are three processes in the simple ATM switch, namely parse signaling message, find destination, and allocate resource, that transform input and output values-parameters of events between the system and the outside world.

System Design

The system-analysis phase determines what the implementation must do. It is represented by the object, dynamic, and functional models. The system-design phase determines the high-level strategy for solving the problem and building a solution. For large software projects, this is the stage where subsystems are identified and partitioned in order to make development more manageable.

The system design consists of the three refined analysis models that satisfy all the technical, business, and architectural constraints described in the requirements. High-level design decisions (such as the use of CORBA or distributed-signaling processing) should be factored into the analysis models. The system-analysis and -design phases are highly iterative. It is not uncommon to oscillate between these two stages 10 to 20 times before the final models are hammered out.

In theory, the models developed in the system-analysis stage should be separate from the actual design regardless of the high-level solution or architecture chosen in the system-design stage. It is my experience that this only works for small software projects. For large software-development projects, high-level design decisions, such as the use of distributed-signaling processing, will no doubt affect analysis models, and when this happens, the models should be revised to reflect to the actual system that is going to be developed.

Object Design

The classes (or objects) identified during the system-analysis and -design phases are high level, without much detail. The object-design phase determines the full definitions of the classes and associations used in the implementation, as well as the interfaces and algorithms of the methods used to implement operations. At this stage, designers change their design perspective from application to computer domains. New objects, object attributes, and operations are usually added. The designer must choose ways to implement the objects to minimize execution time and memory required.

Figure 7 is the refined object model of the simple ATM switch. All attributes and operations of the classes can be derived directly from the object, dynamic, and functional models produced in the system-analysis and -design stages. For example, the route-manager class has a member function called find_destination() as the message-sequence chart, and the dynamic model of the session manager in Figures 4 and 5, respectively, reveal this requirement in the route-manager class.

Implementation

Once the design phase is complete, you can map the models into executable programs using object-oriented languages such as C++. The operations and attributes defined in the refined object model (Figure 7) are simply member functions and private data of the class in C++. Dynamic models defined for each class constitute the program control flow of the classes. Program control flow can be easily implemented using C++ features, such as if-else, switch, exception handling, and the like.

Most object-oriented languages do not support association relationships defined in the object model. There are several ways to provide this support in C++, such as using pointers or templates (see "Reusable Binary Associations in C++," by Terris Linenbach, DDJ, June 1996). Listing One shows the session and session-manager class definitions with the manage-association relationship implemented using pointers.

The aforementioned pointer implementation of OMT's association relationships is rather primitive. Fortunately, most OMT design and analysis tools, such as Rational's ROSE C++ OMT package, generate C++ template code for association relationships. This takes the burden off the programmer's shoulders, since association relationships should be an object-oriented programming language's feature.

Conclusion

The hypothetical ATM switch is, of course, much simpler in design than a real-world ATM switch. For example, the software for a contemporary ATM switch that runs PNNI routing protocol for ATM-traffic routing can comprise about 100,000 lines of code.

OMT enforces up-front software analysis and design. To produce the three models defined in the system-analysis and

-design stages, you have to have a good understanding of the product being developed and its associated problems. Working out those problems with the models prevents designers from coding prematurely.

Another argument for OMT is that the use of the widely accepted OMT notations and methods improve communication among software designers. This is especially important for large software-development projects, which may involve hundreds of software designers across multiple sites. Software or object reuse can be another big benefit of using OMT, although it requires persistence and dedication from designers and management. All these advantages translate into production of higher quality software that requires less time to develop and maintain.

Table 1: Software development phases and deliverable using OM.

Phase               Deliverable

System analysis     Object, dynamic, and functional models

System design       Refined models that meet the desired technical, business, and architectural constraints

Object design       Refined object, dynamic, and functional models with implementation details

Implementation      Executable programs

Listing One

const int MAX_SESSION = 2000;     // max sessions supported by the ATM switch
enum SessionState {IDLE,SETUP,CONNECT,CONNECT_ACK,RELEASE,RELEASE_COMPLETE};
enum Status {INACTIVE, ACTIVE};
class session{
        private:
                SessionState state;
                Status status;
                class session_mgr *sm_pt;
                friend class session_mgr;
        public:
                session();
                ~session() { status = INACTIVE;
                void enable_session() { status = ACTIVE; };
                void disable_session() { status = INACTIVE; };
               class session_mgr *get_SessionManager() { return sm_pt; };
}
class session_mgr {
        private:
                session *sess_pt[MAX_SESSION];
        public:
                session_mgr();
                ~session_mgr()
                int setup(char *orginating_address, char *destination_address,
                                                        int bandwidth_desired);
                int connect(int vc_assigned);
                int connect_ack(void);
                int release(void);
                int release_complete(void);
                void add_session(session *);
                void delete_session(session *);
                session *get_session();
}