Using UML to Represent Regulatory Material

Originally Published MDDI May 2002

SOFTWARE

A software-development tool for understanding complex systems, the unified modeling language can confer several benefits, including reduced training costs, more-precise standards, and higher-quality FDA submissions.

Bruce Knoth and Barry Craner

Perhaps it is time for regulatory specialists to share a language with software engineers. Both professions deal with complex systems that require specialized knowledge, and the practitioners of each intermingle constantly. Regulatory professionals work in a world of laws, regulations, standards, and guidelines that software engineers must understand and comply with; hence, it is often the regulatory specialist's job to explain the overall structure and details of the various regulatory documents to software engineers.

Many software engineers are familiar with a software design tool called the Unified Modeling Language (UML). This language helps engineers model complex systems and design software. Because it can represent the regulatory environment, UML can provide a useful tool for communications between regulatory and software experts.

This article demonstrates how to use UML to model the medical device regulatory environment. It also shows how UML can be used to analyze a standard, and then uses UML to suggest an improvement to that standard.¹

These UML techniques confer several benefits to manufacturers. First, they can reduce the cost of training engineering staff by enabling trainers to present the regulatory structure in a context that engineers understand, thus saving time and improving comprehension. Second, these techniques can lead to more-precise standards. Using UML to analyze a draft standard may unveil inconsistencies in its language and allow errors to be remedied before the standard is released. Third, these techniques can be used to plan FDA submissions and to document product design activities, thus improving the quality of FDA applications and potentially reducing the time to market.

UML OVERVIEW

Engineers use many notations to design software. For example, flow charts help define program flow and logic, in addition to showing processes extrinsic to software development. Other graphical notations include state diagrams—which illustrate the states that an entity can take and the triggers that cause transitions between states—and data flow diagrams— which show how data moves and changes in various processes.

Object-Oriented Development. In the mid-1980s, a style of software engineering called object-oriented development became popular. This style of development comprises object-oriented analysis (OOA), object-oriented design (OOD), and object-oriented programming (OOP). Some practitioners began to refer to an object-oriented programming style (OOPS).

A variety of notations and techniques were developed for object-oriented development, with the intent of improving software design and development processes. These techniques are referred to as object oriented because they focus on modeling real-world objects, including both descriptive data and behavior. For example, an object-oriented model of a pendulum could include parameters for the pendulum's mass and length and an equation that describes its motion.

Among the popular object-oriented development techniques have been the Booch Method, named for its creator, Grady Booch; object modeling technique (OMT), created by James Rumbaugh; and object-oriented software engineering (OOSE), the development of which was led by Ivar Jacobsen. These methods had strong similarities, but their notations differed and each had unique features. Their respective designers recognized the value of using one system of notation instead of many, so they joined together to create one language, UML.^2,3

CLASSES AND OBJECTS

Classes. The concepts of classes and objects are central to object-oriented techniques. A class describes the characteristics of members of a set that share common attributes and behaviors. In UML, a class is shown as a rectangle, often with three regions, as in Figure 1.

The top region gives the name of the class, the middle region gives the attributes, and the lower region shows what operations are available to operate on the class. One may choose not to show the operations or the attributes regions. (Note: The operations region is not included in the following examples because it does not pertain to modeling regulations.)

Consider the example of a class representing wheeled vehicles. In Figure 2, the class is shown with one attribute—the number of wheels. For example, unicycles and automobiles are vehicles with one and four wheels each, respectively.

A significant portion of the UML is devoted to class diagrams, which show the relationships among classes. There are three fundamental types of relationships, inheritance, association, and dependency.

Inheritance. Inheritance signifies specialization, and is sometimes referred to as an "is-a" or a "parent-child" relationship. For example, the automobile class inherits the features of the vehicle class, as shown in Figure 3. The arrow with the closed arrowhead signifies inheritance. Hence, the diagram can be read as "An automobile is a vehicle." In this relationship, the automobile class is the child of the vehicle class.

The diagram shows that automobiles are vehicles and that automobiles have a number of doors, an engine size, and a number of wheels. Now that the class of automobiles has been described, how does one refer to a specific car?

Objects. UML defines an object as, among other things, an instance of a class. Elvis's pink Cadillac is an object. It exists (in a museum), it is real, and it is an instance of the class of automobiles.

In UML, objects as well as classes are shown as rectangles. In Figure 4, PinkCadillac identifies a specific object that is shown to be an instance of the class of automobiles.

Objects are not usually shown in class diagrams. Instead, they are shown in separate diagrams illustrating the interactions among objects. When using UML to show regulatory structure, it is useful to show objects on a class diagram in order to express where specific documents fit into the regulatory structure. This is done with UML's extension capabilities.

Stereotypes. The creators of UML recognized that users would want to extend the language to accommodate unforeseen needs and applications. One way UML can be extended is through the use of stereotypes. Stereotypes change the meaning of UML elements, and are shown as names between guillemets—for example, <>. An "Instance of" stereotype is shown in Figure 5.

Now the arrow shows that Pink Cadillac is an instance of an automobile. The pink Cadillac is, therefore, an object, so no classes can be derived from it. Although UML provides object diagrams that show objects and the relationships among objects, the "Instance of" stereotype can be used to help describe the regulatory structure for medical devices.

Figure 6 depicts the U.S. regulatory environment that affects medical devices. This diagram shows a parent class that embodies all regulatory material, including laws, regulations, standards, and guidances. The diagram shows four general categories of material: federal law, international material, FDA material, and standards. There are two instances of federal law, the Food, Drug, and Cosmetic Act and the Safe Medical Devices Act, and two examples of guidances, "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices" and the "General Principles of Software Validation."^4,5 The diagram shows 21 CFR 820 as an FDA regulation, and SW68 and ISO/IEC 12207 as two standards. This diagram is not comprehensive; it shows how specific documents can be viewed in the context of the overall regulatory environment.

Association. The second fundamental relationship between classes, association, can be considered a "has-a" relationship. Figure 7 shows how the relationship between vehicles and owner is modeled as an association. This relationship is a two-way association. It shows that an owner has one or more vehicles, and that a vehicle has one owner. The numbers at each end of the line connecting the vehicle and owner classes show the cardinality of the association (the possible number of objects at each end of the association). To visualize this relationship, imagine standing on one box, the Owner class for example, looking down the line and seeing the cardinality (1..* [one or more]) of the vehicle class at the vehicle end of the line. That is how to read the diagram and know that an owner has one or more vehicles.

A one-way association is shown in the relationship between an automobile and its engine. The one-way association is illustrated as an arrow indicating the direction of the association. Figure 8 shows that an automobile has one engine. If one identifies a specific automobile, one can find the type of engine. If one identifies an engine type, however, one cannot find the automobile.

Aggregation. A stronger association, aggregation, is a whole-part relationship. In Figure 9, aggregation is shown by a diamond at the automobile end of the line.

Figure 9 models an automobile as having three types of parts—seat, engine, and tire. It has one or more seats, four tires, and one engine. An aggregation diamond would be inappropriate for the vehicle-owner relationship discussed earlier, since a vehicle is not part of an owner, or vice versa.

Composition. UML recognizes another, stronger, form of aggregation, called composition. One shows composition by making the diamond solid black instead of outlined as it is in aggregation. In composition, the lifetimes of the parts coincide with the lifetime of the whole, so the parts are destroyed at the same time as or before the whole object is destroyed. An example of composition is an animal, which is composed of organs. The organs are created when the animal is created, and die at the same time as or before the animal dies.

SW68

Now consider UML as an analysis tool for SW68, a new ANSI/AAMI standard for software life-cycle processes.¹ SW68 offers the following definitions:

With UML, each of these entities can be represented as a class, so there are four classes. The definitions can be interpreted to show the relationships among the entities. The definition of a software unit implicitly suggests that a software item may or may not contain additional software items, so the UML diagram shown in Figure 10 indicates that the "Software Item" class is an aggregate of zero or more software items (0..*).

A software unit is a software item, so the relationship between unit and item is shown as inheritance, with a closed arrowhead. Furthermore, a software unit cannot comprise any other software items; that restriction is illustrated explicitly with aggregation that shows that a software unit contains zero software items.

A software system is defined as an integrated collection of software items; that relationship is shown as an aggregate of one or more (1..*) software items.

The definition of a software item suggests that a software product contains one or more software items, so that relationship is also shown as an aggregate of one or more (1..*) software items.

The UML representation of the four definitions (Figure 10) does not show a difference between software products and software systems. Even the standard's definitions of a software system and a software product are hard to differentiate. Using UML, one could suggest that a better definition of a software product could be "a collection of one or more software systems." That definition would change the diagram, as shown in Figure 11.

Note that the software product is now shown as an aggregate of software systems, not of software items.

SW68 does not define software-unit, integration, system, or validation tests, but a UML diagram such as Figure 12 could help define them.

In Figure 12, each software unit has one unit test, and each unit test has one software unit. An integration test operates on two or more software units, and each software unit is part of zero or more integration tests. System tests apply to software systems, and software validation tests are for products. Although these definitions are debatable, this diagram shows how UML can be used to help define terms.

Dependency Relationship. The final relationship is the dependency, or uses, relationship, which is shown with a dashed line and open arrowhead. For example, Figure 13 shows that class B uses class A.

This relationship shows that a change in the specification for class A may affect class B, but not vice versa. Dependency is a weaker relationship than association, because it does not suggest ownership, lifetimes, or relationships between objects.

Comment. An additional UML icon shows comments. The comment symbol suggests a note card with one bent corner. Typically, the comment is attached by a dashed line to the item that it references, as shown in Figure 14.

PREMARKET SUBMISSION GUIDANCE

UML can be applied to the FDA guidance for premarket submissions for software.⁴ Figure 15 shows an example of part of a fictitious medical company's plan for the software in a PMA application. The plan centers around the PMA submission document. As Figure 15 indicates, the document has many sections,including Software Requirements Specification (SRS) and Software Hazards Analysis (SWHA). Most of the sections included in the diagram are recommended in the PMA guidance document.

Furthermore, Figure 15 shows which sections are controlled documents. These include the SRS, SWHA, and many more. Other sections, including Level of Concern and Release Version Number, are not controlled. A controlled document has a revision level, an approval list, and a master copy. Although other organizations may choose a different interpretation of the PMA requirements, or choose to use different controlled documents, this diagram shows how UML helps visualize the overall PMA submission and gives details about the company's plans for that submission.

The diagram shows how the company plans to fulfill the requirements for the sections of the submission. The engineers will follow applicable standards, which are listed as attributes for each section (the attributes refer to standards and section numbers). For example, the SRS will follow the SW68 standard, section 5.1.2.

The diagram also shows that the verification and validation testing ("VV Testing") follows SW68 section 6.4. It includes one or more integration test plans and one or more system test plans, and it also may have unit test plans.

The PMA guidance calls for a detailed discussion of the life-cycle model for the software. This diagram shows that the software life-cycle development plan (SW Life Cycle Dev Plan) uses SW68 and that SW68 is a specialized adaptation of ISO/IEC 12207. The software life cycle has two sections—a development process and a maintenance process. The maintenance process, in turn, also consists of two parts: one is a problem and modification analysis (which proposes solutions for specific problems), and the other is a method of implementing modifications for released software. The modification process follows the development process, which is spelled out in the PMA submission (not shown in the diagram).

ACTIVITY DIAGRAMS

In addition to class diagrams, UML also offers other types of diagrams. Activity diagrams can help firms to fulfill FDA documentation requirements. An activity diagram shows a chain of activities and how the activities modify objects. UML defines an activity as an "Ongoing nonatomic execution within a state machine"; a looser definition of an activity could simply be "a task." An activity or a series of activities can change the state of an object.

The state of an object is the object's condition when parameters that describe its status have specific values. For example, an automobile might be "occupied" and "on." In a model of the regulatory environment, documents are objects. The documents have states, and there are activities that change those states. For example, participants in a design review meeting might change a specification document's status from "draft" to "approved."

Figure 16 shows a simple activity diagram that incorporates three activities and two states. The black circle at the top shows the starting point of the process. It leads to the first activity. Once activity A is completed, activity B starts. This activity puts the object into its first state and triggers activity C. This final activity changes the state of the object to state 2 and ends the process, which is shown by the concentric circles at the bottom of the diagram.

Activity diagrams may be used in FDA submissions, and software life cycles are good candidates for activity diagrams. Section 4.1 of FDA's PMA guidance document states that "a software life cycle model should be understandable, thoroughly documented, results oriented, auditable, and traceable, and should promote appropriate feedback within the development process."⁴

Figure 17 demonstrates how part of a software life cycle can be documented with an activity diagram. This diagram shows the first part of a life cycle. The first steps in the process are the analyses of the system specification and hazards, followed by the creation of the software requirements specification. The system specification and system hazard analyses are inputs to the analysis activity.

Once the SRS has been created, it is in the draft state. The draft SRS is the input to a formal review. Once the review has been completed, either the draft will need revision or it can be released. The formal review activity produces a review record, and the release activity changes the state of the SRS from draft to Revision 1 (Rev 1).

Swimlanes. Figure 17 shows two columns, which UML calls swimlanes. UML's creators intend swimlanes to show who is responsible for which activities, but here swimlanes are used to show what documents go into the design history file. A similar swimlane could show which items enter the device master record.

CONCLUSION

UML is a software design notation that can be used to represent and analyze regulatory material. UML representation can clarify the complex medical device regulatory structure by helping engineers understand the regulatory structure quickly, thus reducing training costs and increasing their expertise.

In particular, UML can be used to represent and analyze regulations, standards,X and guidance documents. This use of UML can lead to more-precise documentation, thus enabling designers and manufacturers to fulfill regulatory requirements more easily. Furthermore, the use of UML for FDA submission planning and in the documentation of product life cycles can improve FDA submissions, leading to shorter product-release cycles and enhancing communication with FDA and other regulatory agencies.

REFERENCES

Bruce Knoth is a senior software engineer with SRI International (Menlo Park, CA). Barry Craner is a director of quality assurance with Lipid Sciences Inc. (Pleasanton, CA).

Copyright ©2002 Medical Device & Diagnostic Industry