Hardware/software co-development using a model-driven systems development approach -- Part II: Illustrating the solution

from The Rational Edge: The second in a three-part series, this article details a process for model-driven systems development (MDSD) in the example context of a high-end printing system. The authors identify actors and their system interactions, itemize system use cases and services, and demonstrate the use of UML visual modeling in the process.


Murray Cantor, Distinguished Engineer, IBM

Murray CantorAs a leader in the IBM Rational field services group, Murray Cantor promotes and extends Rational best practices, including Rational Unified Process for Systems Engineering® (RUP-SE®). Murray has been named distinguished engineer both for his contributions to RUP-SE and for his successes with client enterprise transformations. He has published two books and numerous papers, and plays a key role on standards committees relating to UML and RUP. He received his Ph.D. in mathematics from the University of California at Berkeley in 1973.

Gene Roose, Systems Engineering Consultant, IBM

author photoGene Roose is a senior systems engineering consultant for IBM Rational, concentrating on model-driven systems development methods for the industrial sector. He assists clients with solution analysis and design, architectural derivation and validation, and overall project management. His collaboration with Murray Cantor on a significant systems engineering process study for a major automotive concern provided foundational material for this article.

Previously, he developed, deployed, and supported IBM printing systems and document publishing products, beginning with the development of advanced function printing (AFP) software and hardware in the early 1980s.

He holds a B.S. in mathematics and an M.A. in statistics from Arizona State University as well as a master's certificate in project management from George Washington University.

15 February 2006

illustrationThis multipart article explores joint hardware/software product development from a systems perspective and offers a generalized model-driven systems development (MDSD) approach designed to optimize functional allocation. It applies techniques and utilizes framework elements incorporated in the current release of Rational Unified Process for Systems Engineering (RUP-SE), a proven MDSD framework that is an extension of the IBM Rational Unified Process®, or RUP®. These artifacts are available in the current release of IBM Rational Method Composer (released December 2005), which provides a flexible framework for tailoring methods and processes, along with best practices and online guidance for product development teams engaged in MDSD.

Part 1 of this article discussed the unique challenges of hardware/software co-development and the limitations of traditional systems engineering approaches. We introduced a model-driven systems development approach based on the RUP framework with RUP-SE extensions. We also presented Rational's six principles of systems engineering and described how they relate to MDSD.

Here in Part 2, we will begin to illustrate our MDSD approach by outlining the architectural derivation of an example printing system. We will determine the printing system's context, identifying actors and the collaborations between actors and the printing system to satisfy stakeholder needs. The needs will be itemized as the system use cases and the services necessary to accomplish the intended results are depicted. This activity is analysis at the context level. In the process, we will demonstrate UML sequence diagramming, and we will visually model the context-level logical and physical views.

In Part 3, we will continue the recursive structural decomposition of our sample printing system, demonstrating activity at the analysis level of system architectural development. Here we identify candidate subsystems (logical elements) and localities (physical elements) whose interactions will satisfy the services discerned in the system-level use cases. We will illustrate the joint realization of requirements crossing hardware and software boundaries and multiple viewpoints using our MDSD approach. We'll also discuss techniques for moving from the abstractions contained in the context and analysis model levels to system realization in a partitioned collaboration of hardware, software, firmware, and workers. We'll conclude with a summary of how this approach provides an effective hardware/software co-development process that facilitates appropriate collaboration within and among multidisciplinary teams, and guides project and program management to help ensure stakeholder value is optimized throughout the product lifecycle.

Before discussing the model, we'll present a brief history of modern printing systems to help you understand the need for robust printing system architectures and their representations in model form.

Until the mid 1970s, printing systems were all line-oriented and almost exclusively print-chain based.1 Each new printing system required extensive changes to the supporting operating system in the areas of input/output services (IOS), job scheduling (for example, MVS scheduler), job execution and disposition (job entry subsystem -- JES), and system attachment (SYSGEN).

This world began to change in the latter half of the 1970s, as the complexity of a printing system grew enormously as advances in technology enabled a printing system to handle not just lines of data, but pages.

The catalyst for this change was electro-photography (the printing technology behind laser printers), which allowed a page to be divided into a large matrix of addressable elements (called printer elements, or pels). Suddenly, groups of dots could be logically formed into print characters, images, logos, and other elements more familiar to operators of printing presses.

The print datastreams2 prevalent in the 1970s were not scalable to support this new method. Software and hardware engineers were presented with a challenge -- to develop architecture broad enough to address hardware, microcode, and software requirements, and then to design, develop, and integrate the various printing system components across the supported operating system platforms.

Furthermore, compatibility with existing print applications, print datastreams, and operating system components had to be assured, which would allow for a gradual introduction of these new printing systems into customer environments.

It is interesting to note that three different approaches were taken by the printing system OEMs of the era:

  • Xerox designed a self-contained printing system that included all printer hardware, supporting print server software and print resources in a single physical unit. This system accepted either line data from a host system or tapes of line data that were directly attached and processed on the printing system. Each printing system had its own operations console and unique print resources.
  • IBM designed a cooperative printing system environment. The primary printing function resided within the printing system hardware, but the supporting print server and print resources were included in the host operating system. Comprehensive, extendible, object-oriented print datastream architectures were created with a device-independent print application program layer and a device-specific printing system layer.
  • Siemens designed a printing system that largely emulated the IBM printing system and used the IBM host software and resources.

With a little reflection, it should become apparent that all three approaches were sound and played to the strengths of the three vendors. While all three approaches satisfied the main requirement of page-oriented printing, the different implementations certainly had varying strengths and weaknesses (which we won't address here). Clearly, making intelligent choices is a significant architectural development challenge.

By the 1990s, technology was once again the catalyst forcing major change in printing system architectures and implementations. This time the catalyst was the proliferation of personal computers and high-powered workstation hardware.

Printing systems of the 1980s were largely variations on the 1970s technology. A major limitation in product development and an inhibitor to rapid innovation was the requirement to build most of the major printing system functions directly into hardware (multiple circuit boards with proprietary content).

The PC changed all that. Instead of highly complex and expensive proprietary boards, the majority of printing systems functions could now be implemented in software, supported by widely-used operating systems (such as AIX and Microsoft Windows) and hosted on PCs or workstations. Besides driving down costs and increasing reliability, this change also allowed for scalability and component reuse.

This brings us to today. There are a wide variety of printing systems in the marketplace. The high-end printing systems still require PCs or UNIX boxes as physical printing system elements, but the low-end is full of "systems on a card," driven by an embedded host (based on embedded operating systems like Wind River's VxWorks). And the typical system is really a system of systems, with a variety of general-purpose and specialized systems working in concert to perform the tasks of a printing system.

With that as a perspective, the lowly printing system begins to look like many other systems of systems in the marketplace -- automobiles, aircraft, and telecommunication networks, to name just a few.

Change is inevitable, and the rapid pace of technological evolution mandates not only a respect for change, but a strategy to utilize change as an agent for excelling in successful product introductions on accelerated schedules.

System description

We begin the derivation of our printing system model by first identifying the scope of our printing system environment, including interacting systems and other actors that will interface with the printing system to accomplish work.

The work is described initially in a set of system-level use cases. These will be used to help derive context and analysis-level views from a minimum of logical and physical viewpoints. As we begin to decompose the printing system into components and subcomponents, we will need to also break down the system-level use cases into more specialized subsystem-level use cases based on the services identified in the system-level use cases.

This process -- moving up and down the levels as necessary to refine the model -- allows us to separate complex concerns into more manageable ones (by focusing on specific viewpoints such as process, data, or physical) and at the appropriate time reintegrate all the elements into a composite whole.

It also helps bring greater clarity to the typical design and development phases of product development, and bridges hardware, software, microcode, and other traditional vertical domains within systems development groups.

System scope

We will follow the second approach described above (IBM's cooperative system of systems design), beginning with a description of the printing system's immediate environment. As we constrain the system's environment, we may also need to note actors, systems, and business considerations just outside the system boundary, which will add pertinent content to the overall discussion and perhaps even introduce supplemental requirements affecting the system's design (in such areas as extendibility, scalability, reliability, and performance).3

In the second printing system design approach (used for more than a decade within IBM), the system developer (IBM again) is actually more of a system integrator. While IBM does develop significant content, it acquires many physical printing system elements from other companies. Sometimes the elements are acquired as-is; in other cases, IBM collaborates with certain OEM partners in customizing elements to IBM specifications.

In addition to elements tightly integrated within a printing system, there is the potential for the printing system to include loosely coupled elements that provide capabilities augmenting the services performed by the base system. These loosely coupled elements can either be shipped as part of the base system or acquired separately by a client. Since the functions performed by these loosely coupled elements are viewed holistically as part of the printing system, we must account for them architecturally and also include them in all of the system development lifecycle efforts.

Here we are choosing to illustrate a high-end printing system involving, for example, a continuous roll web press. Based on the size and cost of these systems, they are primarily used for high volume printing needs and require specialized operators. These systems are typically found in data centers and are used for processing checks, financial statements, insurance policies, utility bills, and for printing books.

At the speeds and volumes achieved by such a printing system, regular maintenance is required, both by the enterprise and those contracted, to ensure the system meets service levels mutually agreed between the enterprise and the maintenance vendor. In addition, the speeds involved mandate the use of additional equipment to keep paper running through the base system for hours at a time and also to allow efficient post-processing of the printed output at rates compatible with the printing system's speed and volume.

A typical print center will operate a minimum of five days per week, eight hours per day and a maximum of seven days per week, twenty-four hours per day (where the printing system is only off-line for regularly scheduled preventative maintenance). Needless to say, these printing systems have high availability and high throughput requirements. Continuous printing operation is expected to range upwards of 70 percent of maximum capacity.

Given the above, along with the knowledge that the second design approach de-couples the print server (which supplies documents for processing to the printing system and oversees all electronic aspects of the printing process) from the printing system, our initial system environment includes the following:


  1. The printing system

    The printing system: truly a system and not simply a printer. In its simplest case, the printing system is a single self-contained device with an embedded printing system control unit, networking hardware and software, paper bins, and the marking engine (which actually transfers document elements to paper).

    In the general case, the printing system is composed of discrete components -- each performing a subset of the actions required to produce the final output document (which could be a report, a simple mail piece, or a stitched book). The components may be loosely or tightly coupled or integrated.

    Loosely coupled means the components are physically separated, but communicate across a simple interface to indicate whether they are ready or not ready (called Type I).

    Tightly coupled means the components are physically separated, but communicate across an intelligent interface, which allows the printing system control unit to manage a subset of the components' printing activities. For example, one way to incorporate spot color in a document with primarily black print is to separate the printing commands and data for the black elements from the spot color elements. Black elements are sent to the printing system marking engine(s) and spot color elements are sent to the appropriate post-processor using a more robust interface (called Type II).

    In both loosely and tightly coupled environments, the pre- and post-processing components have their own control units, which are ultimately responsible for ensuring those components perform their subset of the printing process.

    Integrated means the components are supplied as part of the printing system. The components may be physically joined or separate and will likely contain embedded controllers -- which carry out the instructions sent from the printing system control unit. For example, in an Infoprint 4000 duplex printing system, there is a single printing system control unit (physically residing in a control unit assembly attached to the second marking engine) and two marking engines (one to print the front sides of a document and the other to print the back sides of a document). The individual elements (the printing system control unit and the two marking engines) appear to the operator as a single integrated complex.
  2. The print server (a system actor)

    The print server is the system that provides document spooling, document conversion (from one format to another), and print/printer management (document queuing, document/control communication with a printing system, printing system resource management, error management, and so on).

    Print servers have their origins in job spooling and scheduling systems (such as JES). The first print servers were envisioned to offload the printing-specific services from the job entry subsystems.


  1. The operator

    The operator is the enterprise worker responsible for the day-to-day operation of the printing system. A single operator typically monitors and operates a bank of printing systems, moving from system to system as necessary to perform setups and maintenance or handle device interventions.
  2. The key operator

    The key operator is a worker in the enterprise with primary responsibility for the printing system. The key operator has a higher level of control than the pool of "regular" operators and has access to restricted functions (such as setting the parametric values for key marking engine operational controls associated with certain forms or jobs).
  3. The customer engineer

    The customer engineer is usually a worker for the vendor that supplied the printing system. The customer engineer is responsible for ensuring the printing system is kept in optimal operating condition and is available for use as specified in service-level agreements between the service vendor and the enterprise.
  4. The print administrator

    Print administrators are responsible for the business and technical management side of printing within the enterprise. The print administrator typically will track and review printing metrics, including supplies usage, operator efficiency, cost per page, and so on.

Candidate use cases

Clearly, the primary use case for a printing system is processing and printing documents. This will be the main service providing the enterprise value. There are several other key use cases to consider, based in part on what we've described above. The first must be preparing the site and performing the printing system installation, which is the precursor to any productive system utilization.

Based on the high availability requirements, we'll need a use case depicting system maintenance. There are also other practical operational aspects to consider, such as powering the system on or off, configuring and reconfiguring the system, performing setups (to process documents requiring different media, for example), responding to system events (especially those requiring some action by the operator to return the printing system to an operational state -- what we refer to as "intervention required" events), and more.

We'll take an initial pass at system-level use cases in a moment, with the understanding that the list will likely condense somewhat as some use cases are determined to be alternate flows of other use cases and don't really stand on their own. Before we do, let's expand our system's scope to get a better understanding of the context.

Expanded system scope

As is often the case in the real world, events and conditions close to or at the defined system boundary must be considered, as they aid in system comprehension and provide a basis for ensuring the system design is robust (at a minimum, in terms of extensibility and scalability). Here are two examples to illustrate:

  • Clearly, our printing system must process documents. We have already indicated that the print server is responsible for selecting documents for processing and managing the printing process. But where did these documents come from in the first place? And how was data formatted so it could be successfully processed by the print server/printing system system of systems? How do we ensure we can introduce new printing capability (which may require architectural changes to both application and printer datastreams) and enterprises can exploit the capabilities (which necessitate print application modifications)?
  • We understand that the act of printing does not by itself provide the enterprise with significant value. The value comes when the documents are appropriately finished, bound for distribution, and transported to the intended document consumer (for instance, the utility customer).

    If we consider a typical mailpiece for a utility customer, we can infer that the original document (likely many thousands of individual utility bills processed as a single set) had to be printed, separated into individual bills by customer, combined with regulatory and marketing inserts, bundled into an envelope or other package, stamped (and perhaps sorted by ZIP code to obtain favorable postage rates), and staged for distribution. So the utility enterprise, while certainly interested in tracking documents, is much more interested in tracking individual mailpieces as they move through the various stages just depicted.

    While much of this extends well beyond printing, the enterprise will definitely be concerned with the business processes and overall system integrity of the print/mailroom operation.

The key point is that the eventual customer (whether an enterprise, an operator, or an end user) has a perspective on the system and the value it provides. In every case, their perspective is end-to-end, which often encompasses elements and processes outside the system's scope (as constrained by the system developer/integrator).

With that in mind, let's list significant system elements just one step removed from our printing system's environment:


  • The print application (a system actor to the print server)

    The print application is the software responsible for creating documents in a format acceptable for processing by a print server and/or a printing system.

    Typical formats (print datastreams) are IBM's MO:DCA-P, Adobe's Postscript, and HP's PCL. Documents include data and formatting, as well as either implicit (called) or explicit (contained within the output document) printing system resources.

    The print application is always an actor to a print server, but is one step removed from the actors in our sample printing system model, since the printing system illustrated here does not accept print jobs directly from a print application (an initial assumption).


  • The end user

    End users are enterprise workers with materials to print. They typically submit print jobs from either their personal workstations or from a terminal (attached to a host of some type). This submission can be direct (document already available in a form accepted by the printing system) or indirect (document not in final form, but exists in some intermediate format required by a document formatting application).

    In the first case, end users typically can submit documents directly to the print server (across a networking connection).

    In the second case, end users utilize a print application to format (and then transmit) their documents to the print server.

    End users are not shown as actors in the sample printing system model, since the printing system in question requires an IPDS print server to manage print jobs (another initial constraint). That is, end users are one step removed from the printing system (they are actors to the print server, sending documents and print requests to the print server).

System use cases

Having determined the system scope and actors, and surveyed significant elements just outside the system's strict environment, we now focus on identifying and highlighting as complete a set of use cases as we can (given the information gathered so far).

Brief system use-case descriptions

Note: The following are brief descriptions of the printing system's system use cases. The descriptions become progressively more detailed as the use-case flow is understood and alternate flows are described (in many cases, to handle potential error conditions). We will show more detailed descriptions for the power-on and print-document use cases as a foundation for illustrating joint realization techniques.

  1. Install printing system: The IBM customer engineer will uncrate the printing system elements, assemble the printing system, and run internal tests. At the completion of the internal tests, the printing system is turned over to the client for final configuration.
  2. Diagnose printing system: Respond to client call requests and perform diagnostics to isolate problem(s). Depending on the error condition, diagnostics may be performed either online (printing system connected to a print server) or off-line (printing system isolated from the network and potential print servers).

    Diagnosis involves all the activities needed to determine a follow-on course of action, which leads to returning the printing system to operational status.
  3. Repair printing system: Perform maintenance actions to return the printing system to its normal (and hopefully optimal!) running state. This maintenance could be preventative (actions scheduled based on system usage counters and designed to prevent unscheduled outages) or reactive (in response to a customer service request). In the latter case, the maintenance actions here are a logical follow-on activity to diagnostics.

    In some cases, repair immediately follows diagnostics (for example, physical adjustment of a marking engine element). In other cases, repair occurs at a noticeably later point in time following diagnostics (for example, when parts required to repair the error condition must be procured from an off-site source).
  4. Configure printing system: Configure the printing system (including any attached pre- and post-processing devices). Configuration includes defining printing system attachments to print servers, setting marking engine parameters specific to certain forms or print jobs, and defining what services various operators can perform. Initial configuration is done following the printing system installation -- usually performed jointly by the customer engineer and the key operator.
  5. Power-on printing system: This use case describes the events associated with starting up the system -- either from a hard or soft power-off. A hard power-off means the entire system has been powered off (printing system control unit and all marking engines). The power-on process following a hard power-off is a bit more involved than a soft power-off (described below) since the printing system control unit and all managed marking engines must be powered on and initialized.

    A soft power-off means the printing system control unit was powered off, but the marking engines are still powered on and available. There are two soft power-off states:
    • A true power-off, in response to a "Shutdown" request by the operator.
    • A transient power-off, in response to a "Restart" request by an operator or as a response to a reconfiguration.
    The power-on sequence following a soft power-off is a logical subset of the full power-on use case from a hard stop.

    Note: The above use case description actually addresses anticipated physical components (localities) for our sample printing system. This is a fairly normal occurrence in practice. The system designer/integrator in this example does not actually engineer or manufacture marking engines: these are procured from printer OEMs. So an initial system architecture decision has come as a prerequisite. We will see later that this initial specification will lead to further design decisions as the use case evolves.
  6. Print document: This is the primary printing system use case -- the activity involved in actually printing documents. In the IBM mid-range and high-end IPDS print environment, document spooling, printing, and subsequent post-print operations are managed by the print server, working in collaboration with the printing system.

    The following are alternate flows that may be encountered in the course of executing the print-document use case:

    • Set up printing system: Setting up the printing system includes loading the paper (or multiple forms in input bins for a cut-sheet printing system), activating the proper printing system setup (as requested by a print server), and ensuring the paper is loaded properly for correct printing. Once the setup is complete, the operator completes the activity by readying the printing system (which lets the print server know the printing system is available for work).
    • Satisfy intervention requests: Certain asynchronous events are possible, which prevent the printing system from processing documents. These events result in an intervention request, usually accompanied by visual or aural clues to the operator. Intervention requests must be handled and resolved before the printing system can be returned to a ready state and document processing (printing) can restart.
    • Collect output: After printing has occurred and the printed documents are secure (which means the last sheet of printed information has reached a physical location where the operator can gather the output and send it on to the next stage in the process [either additional off-line post-processing steps or some step in the print distribution process]), the output can be collected.

      This process can either be done synchronously (as part of the "normal" flow) or asynchronously (in parallel to the normal flow).
  7. Maintain printing system: Perform normal maintenance tasks, such as supply replenishment (toner, paper, oil, etc.) and cleaning.
  8. Reconfigure printing system: Some (but not all) printing systems have multiple physical configurations (for example, a duplex printing system composed of two continuous form marking engines has up to four different configurations: duplex, dual-simplex, engine-one only, and engine-two only).

    Systems can also be formed using a variety of pre- and post-processing devices in different combinations and permutations.

    So the reconfigure printing system use case covers the activities performed by the operator to switch from one physical configuration to another. This involves changes to configuration settings within the printing system control unit. Some are relatively benign and can be accomplished without requiring a major configuration change of the printing system control unit components. Others (such as reconfiguring from duplex to dual-simplex) are so involved, the printing system control unit must be shut down and restarted to support the reconfiguration.
  9. Power-off printing system: This use case describes the events associated with shutting down the printing system. There are two primary power-off sequences: shutdown and restart.

    In the case of a shutdown, there are multiple scenarios:

    • A full shutdown of the printing system control unit and all marking engines
    • A shutdown of the printing system control unit and some (but not all) marking engines
    • A shutdown of the printing system control unit only
    For a restart sequence, the normal scenario is for an automatic reboot and reinitialization of the printing system control unit.

    There may also be optional sequences to power-off one or more marking engines and/or pre/post processors, and/or power-on one or more marking engines and/or pre/post processors.
  10. Audit printing system: Auditing the printing system involves regularly collecting statistics from the printing system. The print administrator will then perform data reduction and analysis to determine printing system metrics of value to the enterprise.

Note: One step removed, but important to document is the following print server use case:

  • Submit documents: Print job submission is an asynchronous activity to the actual operation of the printing system. In order for the printing system to perform productive work, there must be print jobs available to process on the print server.

    The operator (and by association, the key operator/customer engineer), the print administrator, and enterprise end users can all submit print jobs, either to generalized collections of printing systems (using print class, for example) or specific destinations (submitting a print job to a uniquely identified printing system in the printing system pool).

Printing system use-case diagram

The system-level use-case view for the sample printing system is shown in Figure 1.

Figure 1: The initial system-level use-case diagram

Figure 1: The initial system-level use-case diagram

The majority of use cases are assigned to the printing system operator, who is responsible for the day-to-day running of the printing system. The most significant of these is printing documents. After all, this is how the printing system supplies value to the enterprise; it produces documents for use by the enterprise's internal and external customers.

Context-level views

We have exposed enough detail in briefly considering the printing system environment and what high-level services are needed in fulfilling its mission (transforming electronic data into fully composed and secure physical documents) to now articulate the logical and physical contextual model views.

Without allocating detailed requirements, let's quickly outline (in no particular order) the interactions (collaborations), interfaces, and artifacts (resources, messages, etc.) identified above:

  • The print server and the printing system are clearly two distinct physical entities. There must be an interface between the two to allow for messages, commands, and data to flow between the two.
  • Documents consist of data, formatting instructions, and printing system resources (elementary objects representing images, graphics, lines, boxes, and character data, and so on).
  • There needs to be some physical interface for operators, administrators, and service personnel to interact with the printing system. This human-machine interface must allow for configuring, maintaining, operating, and statistical information gathering.

With the above in mind, here are the logical (Figure 2) and physical (Figure 3) context-level views of the printing system.

Context-level logical view

Figure 2: The context-level logical view diagram

Figure 2: The context-level logical view diagram
Click to enlarge

The printing system is shown above in its logical contextual environment.

The two primary actors are the operator (and by generalization, the key operator and customer engineer) and the print server.

The print server provides the electronic management for the printing system, including assigning what work will be processed by the printing system.

The operator provides the physical management of the printing system and often is the actor using an interface on the print server to schedule work.

The printing system and its actors were first identified in the system-level use-case diagram. In this contextual view, we see for the first time the primary I/O entities passed between the printing system and its actors.

I/O entities

  1. System status -- between printing system and operator/customer engineer/key operator

    System status is displayed (at a minimum) on the operator console. There may also be additional displays and consoles associated with physical elements of the printing system. For example, in addition to the operator console on a continuous-form duplex printing system, there will be minimal operator displays in the front of the marking engine (adjacent to where the paper is loaded in the marking engine) and on the side of the marking engine (where paper exits the marking engine).

    System status is divided into the following categories:

    • Initializing (after a soft or hard power-on)
    • Not ready or ready (indicates the printing system's ability to accept work)
    • Intervention required (a not-ready status requiring operator response before the system is again available to process work)
    • Operational (receiving data, saving pages, warming up, and/or printing -- actively processing work in communication with a print server)
    System status may also include information on supply levels, hot roll temperature, and other printing system environmental parameters.
  2. Configuration settings -- between printing system and key operator/customer engineer

    There are a wide variety of configuration settings available to the customer engineer (and to lesser extents, the key operator and operator). The initial configuration settings are made immediately following printing system installation. Changes may occur after installation for the following primary reasons:

    • The hardware configuration has changed (new functions added, for example).
    • Supporting system elements have changed (for example, pre- or post-processors).
    • The print server environment has changed (printer attachments, addresses, or print servers).
    • Additional document types have been added, requiring specific parametric configuration settings and operational processes.
    Configuration settings include such items as datastream input resolution, desired output resolution (for printing), printing system attachment options, system networking address(es), and so on.
  3. Control messages -- between print server and the printing system

    The print server sends three distinct types of data to the printing system:

    • Control messages (commands and queries)
    • Data blocks (document content and format)
    • Print resources (document resources)
    Control messages are sent to initialize communication between the print server and the printing system, to establish the appropriate environment for printing the document currently number one in the ready-for-processing document queue, to track status of the printing process, to manage error recovery, to resynchronize the printing system and the print server, and to manage resources and data in the printing system.

    Some control messages require synchronous and immediate responses, while others allow asynchronous responses (or no response at all).
  4. Print resources -- between print server and the printing system

    Print resources are composition elements. For example, a bitmap font is a print resource. Others include compressed or uncompressed images (which could be signatures, logos, photos, or artwork), bar codes, vector graphic objects, and overlays (overlays are static composite objects -- the digital equivalent of preprinted areas on a form).

    Two MO:DCA-P print resources (page definitions and form definitions) are not sent in their original form to the printing system, but are used by the print server to assist in the creation of the final form data blocks and formatting instructions.
  5. Data blocks -- between print server and the printing system

    Data blocks are composed of the actual document data, along with the formatting commands necessary to position the data on the form and assign attributes (such as font size and color and print direction).

    In the IBM AFP world, there is an important distinction made between application data and printing system data. The former is printing system and print server independent (MO:DCA-P), while the latter is printing system-specific (IPDS). The print server is responsible for the transformation of printing system-independent data to the printing system-specific form.
  6. Printing system responses and return codes -- between the printing system and print server

    Printing system responses and return codes are sent by the printing system to the print server either synchronously or asynchronously.

    They are also sent either by request (print server sends a message requesting an immediate response) or unprompted (when the printing system encounters an error or some type of intervention request, for instance).

    Return codes normally result in some kind of print server response. For example, if the printing system completes the printing and "stacking" (that is, moving the document to a secure retrieval position) of a document with no error message, the print server could kick off a process to remove the document from the active queue and then either erase the completed document from storage or mark it as complete and retain it for a given period (either system or end user defined).

    As a second example, a negative printing system response to a print server query about a document resource could result in a print server search for the missing resource and its subsequent transmission to the printing system.
  7. Printing system log

    There are basically two types of printing system logs available to the print administrator. The first is an audit log created by the print server (in communication with the printing system). The second are logs (or more correctly, data) directly extracted from the printing system using SNMP (a TCP/IP-based networking management protocol).

    Printing system statistics are collected and stored by the printing system in industry-standard printer management information bases (MIBs). The print administrator could use a query program to retrieve the printer MIB information from the printing system and then run a statistical program to analyze the data.

Note: Not shown in the diagram, but documented here for better system understanding is the following I/O entity between end users/print application and the print server (since this is outside our printing system's scope).

  • Document: A document is the primary work element for a printing system. Documents contain content (at a minimum) and typically also formatting control (attributes associated with content -- for example, font type, size, or color and content positioning values).

    Documents may also contain either implicit or explicit print resources. Explicit resources are fully contained within the document itself, whereas implicit resources are called for use as needed to satisfy formatting commands.

    Implicit resources can either be hosted by the print servers or the printing systems. It is possible for a single resource to exist within the document, on the print server, and within the printing system.

Context-level physical view

Figure 3: The context-level physical view diagram

Figure 3: The context-level physical view diagram
Click to enlarge

There are many physical printing system configurations implemented today.

Conscious decisions are usually made when settling on the desired physical configuration, often in response to a large number of competing static and behavioral requirements.

In the IBM mid-range to high-end printing system environment, the physical configuration is as shown in this view.

At the context level, the printing system is shown as a coherent whole. As we begin to dig deeper, we will need to make further decisions in system partitioning.

Supporting systems

  1. The print server host (one or more) -- physically embodies the print server actor

    The print server host is the physical element where the print server software is hosted. Multiple print servers can reside on a single host, but typically there is a one-to-one relationship between print server and print server host.

    It is technically possible in some cases to actually host the print server on the printing system (on the printing system control unit hardware). The architectural derivation performed here assumes the print server host is physically separate from the printing system. This is the standard architectural implementation in general industry use (although many Xerox high-end cut-sheet printing system implementations embed the print server within the printing system). Print applications are generally hosted on end-user workstations (the most widespread means of creating documents today). Thus, there normally will be a many-to-one or a many-to-many relationship between application hosts and print server hosts.

    For mid- to large-scale enterprises, there also is normally a considerable amount of document creation and print management on a single host. This is the case for enterprises with large IBM mainframes and mid-range systems (iSeries and zSeries). For these data center-centric printing operations, a typical printing system would have a single host for both print applications and the print server. The print server would likely manage several printing systems.

    As processing technology has evolved and improved over time, print servers have migrated from mainframe and mid-range systems to workstations and general purpose PCs. In many heterogeneous customer environments, this results in multiple print servers managing one-to-many printing systems.
  2. The print application host (zero or more, since the print server host could also be the print application host)

    The application hosts are the physical elements where the print applications are running. They are actually one step removed from the printing system's environment, since in this architectural implementation, we are focusing on printing systems that require a print server (that is, documents generated by print applications cannot be sent directly to the printing system).

    There is no direct connection between the application hosts and the printing system in this case, as all documents are spooled (queued) and managed by the print server. This is clearly an implementation choice, as the logical print servers could certainly be integrated within the printing system itself (which is the case for low-end to mid-range personal and departmental printing systems). In these systems, documents are sent by print applications across some type of networking transport (PC serial, PC parallel, PC USB, or network TCP/IP), spooled within the printing system, and processed.

Note that we're showing attributes of the printing system (such as IPDS level) in the context-level physical view. These attributes were described in the initial specifications document provided by the marketing team and given to the product manager. An excerpt of these specifications follows.

Printing system example requirements

We will base our requirements on the generally accepted set of requirements for a continuous-form, duplex monochrome printing system with a NGCU (next-generation control unit) printing system control unit.

Functional requirements

  • Base requirements:
    1. The printing system shall support all the functions specified in the IPDS Handbook (manual number G542-3865-8) applicable to the Lightspeed 300D.
    2. The printing system shall support monochrome black-and-white, duplex printing on either pinfed or pinless continuous-form paper.
    3. The printing system shall support the new FS50 image format, providing 1,024 levels of grey.
    4. The printing system shall support communications to/from the print server using any of the following attachments: S390 fiber channel (FICON), Gigabit Ethernet, and FDDI (Gigabit Ethernet attachment will be supplied with the printing system; all three are available either as field or manufacturing plant-installed priced features). A maximum of two attachments shall be supported.
    5. The printing system shall support (as an optional feature) MICR printing, either in simplex mode or on a single side in duplex print mode.
    6. The printing system shall support (as an optional feature) spot color along with black printing in the following modes of operation: simplex printing -- black on one engine/spot color on the other print engine, or duplex printing -- spot color (only) on one side of the paper and black (only) on the other side of the paper.
    7. The printing system shall support the attachment of at least two Type I and one Type II pre- and post-processors to each marking engine.
  • Engine-based requirements:
    1. The printing system shall support native marking engine print resolutions of 600 and 1200 dpi (1200 dpi is supported in 600 dpi emulation mode using "double-dotting" techniques).
    2. The printing system shall support electronic settings for the following adjustable marking engine parameters: pre-heat platen temperature, oiling rate, hot roll fusing temperature, integer contrast settings from one through five (three nominal), backup roll engaged or not.
    3. The printing system shall support a maximum user-accessible print width of 19 inches (in pinfed mode) and 19.5 inches (in pinless mode). Note: The marking engine drum is 20 inches wide.

Supplementary requirements

  1. Supported platforms

    Minimal printing system control unit configuration

    The printing system control unit microcode will be housed on an RS/6000 Model 75 or above with 2 GB of main memory, 4.5 GHz Power5 processor, 2 200 GB 200 MB/sec SCSI drives, and planar Gigabit Ethernet attachment. The minimal operating system is AIX 5.2.
  2. Usability

    Paper autoload

    The printing system shall provide mechanical and visual assistance to the operator when initially loading forms. A newly trained operator shall be able to load forms through both engines and bring the printing system to the "ready" state in five minutes or less.
  3. Accessibility

    Operator command input

    The printing system shall provide operator command entry via touch screen and (optionally) keyboard and mouse. Voice commands are a highly desirable feature if time permits.

    Operator intervention-required alerts

    The printing system shall provide both audible and visual alerts for intervention-required conditions.
  4. Performance

    Nominal print speed (in 2-up 8.5-by-11-inch impressions per minute)

    The printing system shall support a nominal print speed of at least 550 2-up 8.5-by-11-inch impressions per minute in simplex printing, and at least 1,100 2-up 8.5-by-11-inch impressions per minute in dual-simplex or duplex modes of operation. (Note: The Lightspeed family marking engine selected for use with this printing system moves paper through the system at 52 inches per second <260 feet per minute>, which translates to 1,135 2-up 8.5-by-11-inch impressions per minute in dual-simplex or duplex mode.)

    Legacy benchmark performance

    The printing system shall be able to run the full suite of legacy benchmark applications at least 10 percent faster than the Lightspeed 300D (up to the nominal print speed).
  5. Software reuse and componentization

    Printing system control unit microcode

    The printing system control unit microcode will be based on NGCU microcode v7.3 for Lightspeed derivatives. Support for the new FS50 compressed image format is required.

Detailed system use cases and resulting system services

We have not yet illustrated the critical set of artifacts resulting from more in-depth use-case analysis and workflows represented with sequence and, optionally, activity diagrams. As use cases are documented textually, in parallel we transform the text diagrammatically within our developing system model.

This actually serves multiple purposes. As sequence diagrams are built, services, interactions, and messages are identified. These are captured in the model and reflected in the system elements. The very process of stepping through use cases and identifying the required communications, collaborations, and services needed to achieve the desired results is a form of continuous system testing.

At this point, we are not referring to code verification, but rather repeated modeling decision validation. As the system is progressively modeled, it is very likely we will uncover unforeseen requirements, reusable elements, and possibly even deficiencies in the model that require system repartitioning.

This effort reinforces two of the six principles of systems engineering, namely specifications flow up and down the architecture and base the lifecycle on removing risk and adding value.

A couple of examples will help illustrate the process and the resulting artifacts. Let's consider the power-on and print-document system use cases in turn.

Power-on printing system

A more detailed textual description of the power-on printing system use case follows:


  • The printing system (printing system control unit and/or marking engines) is in a powered-off state.
  • The marking engine power switches are in the enabled position (which means power will be applied when the main power switch is moved to the ON position).
  • Paper has been threaded through the printing system complex and matches the parameters identified in the printing system's default forms setup (which will be applied during initialization).

Note: Since the customer engineer must be able to perform maintenance and problem determination/resolution activities on either marking engine independently -- and without power applied to the printing system control unit, this suggests the need for each marking engine power switch to have two positions: OFF and Enabled. It also suggests either multiple LEDs or multicolored LEDs to indicate the discrete Enabled and ON states for each marking engine.

Special requirements


Basic flow

  • {Turn on printing system}
    1. The use case begins when the operator applies power to the printing system by pressing the master power-on switch. (Note: In our example printing system, there are multiple physical units, each with its own power circuitry. Separate power switches are required for the printing system control unit and each marking engine to support the three print modes: one-engine simplex printing, two-engine dual-simplex printing, or two-engine integrated printing (either duplex or simplex spot color). Separate power for each primary physical printing system element is also required to enable independent testing of either marking engine or the printing system control unit. As a result, there is a requirement to allow the operator to switch on each engine and the printing system control unit independently. From a usability standpoint, the printing system should have a single master power-on switch that would allow both marking engines and the printing system control unit to be powered up concurrently.)
    2. The printing system (specifically each marking engine and the printing system control unit) provides the operator with visual feedback that power has been applied.
  • {Initialize printing system components}
    1. The printing system (specifically each marking engine and the printing system control unit) begins to execute the power on sequence.
    2. As the initialization proceeds, the printing system (each marking engine and the printing system control unit) provides visual and (optionally) aural messages to the operator giving initialization status.
    3. When the printing system (all marking engines and the printing system control unit) has completed the primary power-on sequence, the main operator console display is activated.

      {Initialization complete}
  • {Authenticate operator}
    1. The printing system prompts the operator to log on.
    2. The operator logs on to the printing system, using the touch screen (or optionally keyboard, mouse, or voice input facilities [if implemented]) to input user ID and password.
    3. The printing system validates the operator log-on information and configures the console to support commands that the logged in operator is permitted to perform.

      {Operator authenticated}
  • {Ready the printing system}
    1. The operator readies the printing system by pressing the appropriate key on the marking engine keypads or touching the ready button on the touch-screen operator console.
    2. The printing system displays a ready indicator and is now in an operational state to receive and print jobs from a print server.

      {Printing system in operational ready state}
    3. The use case ends.

Alternative flows

  • Power-on unsuccessful (no power indicator on marking engines or printing system control unit)
  • Printing system control unit error during power-on
  • Marking engine(s) error(s) during power-on
  • Operator console not powered on
  • Operator user ID/password combination not valid
  • Printing system control unit unable to communicate with marking engine(s)
  • Printing system encounters an error that prevents entering the Ready state (Intervention Required on printing system or Not Ready state on attached and configured pre/post processors)
  • Single-engine simplex mode power-on
  • Dual-simplex mode power-on
  • Printing system control unit only power-on (marking engines already powered on)

Post conditions

  • The printing system is in a powered-on, ready to accept commands (from either an operator or a print server) state.

The power-on printing system use-case basic flow is shown in the sequence diagram shown in Figure 4.

Figure 4: A sample sequence diagram for the power on use case basic flow

Figure 4: A sample sequence diagram for the power-on use-case basic flow

A few notes regarding the above sequence diagram are in order:

  1. The solid arrows represent services (operations in UML) that the printing system performs as part of the power-on system-level use case. When we move down to the next system-model level, we will describe how the next-level system model elements (in this case, logical subsystems and physical localities) must collaborate to satisfy the system-level services just identified (at that point, we will be identifying subsystem-level services). We will continue this process recursively through as many system levels as necessary to describe system elements and services with enough clarity to facilitate the logical and physical partitioning of the model's abstract elements into design- and implementation-level hardware, software, firmware, and worker elements.
  2. The dotted arrows represent printing system-level messages to system actors either in response to requests contained explicitly within the system-level services we are defining, or inferred to impart key status information to the system's actors while services are being performed or completed.
  3. The sequence diagram shown for the power-on use case only graphically describes the workflow, collaborations, services, and messages required for the basic use-case flow (what we'll call the "happy path"). Diversions from the happy path to handle errors, changes in system state, or other concerns require additional sequence diagrams to describe those alternative flows. The set of happy path and alternate flows is both sufficient and necessary to identify all communications, collaborations, services, and messages.
  4. The underlying documentation for the power-on system use-case base flow at this point does not indicate when or how the alternate flows are invoked. Activity diagrams (essentially flowcharts within UML) can provide clarity in determining alternate flow behavior.

Print document

Let's move on to the print document system use case, which follows:


The printing system (printing system control unit and/or marking engines) is in a powered-on and ready state. The printing system is not currently bound to a print server. At least one print document is queued on the print server.

Special requirements


Basic flow

{Enable printing system}
  1. The use case begins when the operator enables the printing system at the print server host.
  2. The print server checks to see if the printing system is attached and able to communicate.
  3. The printing system checks to ensure it is in an "available to begin IPDS session" state.
  4. The printing system responds positively to the print server.
  5. The print server queries the printing system to understand its capabilities.
  6. The printing system returns its capabilities and configuration to the print server.
  7. The print server stores the responses provided by the printing system for use in print document selection and status responses to the operator.
  8. The print server reports the printing system as available and ready for work to the operator.

    {Printing system enabled}

    {Select print document}
  9. The operator marks one or more print documents as ready for processing on the print server.
  10. The print server scans through the documents queued list, checking to see if there are any documents marked as ready for processing that match the current printing system setup and other identified selection criteria.
  11. When an appropriate document is found, the print server updates the printing system status information, indicating the selected document is processing.

    {Document selected for printing}

    {Initialize print document environment}
  12. The print server sends the printing system necessary print document initialization information, including print document-level printing system resources.
  13. The printing system indicates data is being received to the operator and performs print document initialization.
  14. As data is being received and processed, the printing system sends responses to the print server at intervals requested by the print server to indicate status and that the data is properly received.

    {Print document initialization complete}

    {Transmit print document}
  15. The print server sends page-level document data, resources, and commands to the printing system.
  16. The printing system processes the page-level document data and digitally renders it to the physical medium (continuous-form paper in this case).
  17. The printing system continues sending status to the print server at the requested intervals. The status includes where sides reside physically within the printing system. This information is used to verify when the document has been stacked and is secure. It is also used to determine how to recover from errors in the printing process and redrive the printing system. (Note: On the Lightspeed series of printing systems, the rendering is done on sides, which may contain up to eight logical pages from the print document.)
  18. As the physical printing is underway, the printing system indicates it is printing to the operator.
  19. As the physical printing is underway, the print server also indicates printing status (pages processed) to the operator.
  20. Once all data has been processed and rendered on the printing system, the printing system performs necessary cleanup (for instance, to ensure secure print resources cannot be accessed by other documents).
  21. The printing system indicates document processing and printing has completed to the print server.
  22. The print server updates the document status, indicating processing has completed. Any identified post-printing services would now occur on the print server (we aren't showing any at this point).
  23. The printing system returns to the ready state and indicates such to the operator.

    {Print document processing complete}
  24. The use case ends.

Alternative flows

  • Print server unable to communicate with printing system.
  • Printing system is not available (it is currently bound to another IPDS print server).
  • No documents on print server queue in ready-for-processing state.
  • Documents ready for processing require change-to-printer setup.
  • Print document datastream error found during document processing on printing system.
  • Printing system state goes to not ready (potentially with intervention required) during print document processing.
  • Output generating by the printing system needs to be collected by the operator before attempting to process and print additional documents.

Post conditions

The print document has been digitally rendered on the printing system and the printing system returns to the ready state.

The print-document use-case basic flow is shown in the sequence diagram in Figure 5.

Figure 5: A sample sequence diagram for the print document use case basic flow

Figure 5: A sample sequence diagram for the print-document use-case basic flow

As we noticed with the power-on system use-case basic flow, communications, collaborations, and services are uncovered in the use-case documentation and captured graphically in sequence diagrams within our sample printing system model.

Two additional points are worth mentioning:

  • For overall clarity, it is often necessary to examine interactions between actors that are required to satisfy the pertinent stakeholder needs addressed by a given use case. In the print-document use case, we see that the operator must interact with the print server in order to establish the appropriate environment to facilitate specific interactions with the printing system. In so doing, services the print server must perform in preparing to interact with the printing system are discovered.

    While our focus is not on these services and the requirements they ultimately place on subsystems within the print server, these services must obviously exist for our use case to achieve the intended results. If we were to step up one level above the printing system and focus instead on the print room where both the print server and printing system are distinct print room elements, we absolutely would be interested in capturing services performed by both the print server and the printing system.

    In other words, the approach we are recommending applies regardless of the size or perceived environment of the system under consideration. The same structural decomposition will be done for the print room, the printing system, the marking engine, or even a component of the marking engine.
  • There is significant debate on the value and embodiment of system architectures. Some approaches advocate "throw-away models"; for example, a model representation of an architecture drawn on the back of a napkin, used to foster discussion and establish high-level guidelines leading immediately to system construction, and discarded.

    While such an approach may suffice for very simple systems where an architectural model might only contain several subsystems, it certainly doesn't work when significant complexity is introduced (thousands of requirements, systems of systems, hundreds of nonfunctional requirements, or systems with great flexibility in partitioning between hardware, software, firmware, and workers).

Our position is complex systems must be sufficiently modeled to easily capture and depict the interactions, communication, and collaboration required of subsystems, localities, and more atomic system elements. A more robust modeling tool that captures these facets and allows for clear and concise communication between the various development teams provides significant benefit.

As we've previously seen, pertinent system attributes are easily added to our model elements in our modeling tool. In the course of describing the basic flow of the power-on and print-document system use cases, we have identified several system-level services, some of which the printing system must provide and others which the print server must perform. The very act of identifying these services adds clarity and information to our model. Figure 6 offers another look at the context-level logical view of our printing system model to see some of the additional information captured through the sequence diagramming.

Figure 6: As additional facets of our system are modeled, more details are captured in the various views.

Figure 6: As additional facets of our system are modeled, more details are captured in the various views
Click to enlarge


In this second part of our article, we have illustrated the main activities involved in deriving a system's architecture at the context level. We began by determining the system's environment, looking for things the system interacts with, identifying potential communications, collaborations, and interfaces. This first step establishes a boundary for the system's scope. We also looked just outside the system boundary, which helps provide a big-picture view of the system in context with other enterprise elements. We indicated that this expanded view can provide valuable insight into design considerations affecting system extendibility and scalability, while potentially allowing the development team to profit from reusable components, shared services, and the like available in a wider enterprise context.

We then began an initial partitioning of the system's capabilities into use cases, which describe the services performed by the system, resulting in tangible value to the enterprise and/or its customers.

We went one step further in providing more detail for both the power-on and print-document use cases, documenting the basic flow in text and then depicting the flow in sequence diagrams. Doing this exposed system-level services (normally referred to as "operations" in our modeling tools), which serve as input to the next stage of structural decomposition (deriving subsystems and localities at the system model's analysis level).

Finally, we provided visual representations of the printing system at the context level from logical and physical perspectives. The resulting views capture not just the printing system, its actors, and their system-level interaction, but also system attributes and the expanding set of system services (operations) exposed in the system use-case sequence diagrams.

These activities attempt to demystify the inherent system complexity by analyzing the system from different (yet valuable) perspectives. In our example, we have concentrated on logical and physical perspectives. In the real world, both joint hardware/software and pure software systems require examination from additional perspectives (such as the information perspective, where data models are created).

At this point, the system remains a black box, yet we already have amassed an incredible amount of information about our system, its environment, and its services.

We see that as our analysis proceeds through the system-level use cases, significant decisions made (such as identifying services that our system needs to perform or data elements contained within discrete I/O entities) are reflected in the system elements contained in our context-level logical and physical views. Our next step is to begin white-box analysis of our printing system (to identify candidate-logical subsystems and physical localities). We'll continue with our analysis in the third and final part of this article in an upcoming issue of The Rational Edge.


1 "Line-oriented" in this context refers to the way data was formatted by print applications, transmitted to the printing system, and ultimately processed by the printing system. Each line record contained either an EBCDIC or ASCII coding representation of characters to print, with optional control indicating line placement on the paper (spacing between lines, skipping lines, skipping to a new page). The printing systems of the era contained a print element (train, chain, or band) with fully-formed characters in a single typeface, style, size, and weight. This physical constraint confined printing systems to producing documents containing only words (no logos, images, graphics, or even more than one typeface in a document).

2 A print datastream is an electronic representation of the contents of a document. It is created by a print application running on a mainframe, workstation, or personal computer and transmitted across some data connection to a printing system for processing. As mentioned above, the printing systems of the era were limited to line-oriented printing, also known as 3270 line data. Common print datastreams used today include Adobe PostScript, Hewlett-Packard PCL, and IBM’s MO:DCA-P (commonly known as AFPDS).


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, Architecture
ArticleTitle=Hardware/software co-development using a model-driven systems development approach -- Part II: Illustrating the solution