R h ap sod y for S ystem s A rch itectu re Ð B etter A rch...

© I-Logix, Dr. Bruce Powel Douglass, June 2002, of 15I-Logix Inc. • 3 Riverside Drive • Andover, MA 01810 • Tel: 978-682-2100 • Fax: 978-682-5995 • http://www.ilogix.com

Rhapsody for Systems Architecture –Better Architecture With the UML

Dr. Bruce Powel DouglassChief Evangelist

I-Logix

IntroductionThere has been much discussion and confusion about proprietary extensions of the UMLbecause, so the claim goes, they are required for real-time systems development becausethe UML is inadequate. Long-time Rhapsody and UML users know this claim is false,but nevertheless the spread of FUD1 has confused newcomers who want to use the UMLto develop systems where architecture is important. This paper discusses what we meanby architecture in the UML and how we can represent, manipulate, and understandarchitecture in standard UML with Rhapsody.

So What Do We Mean by “Architecture?”In the ROPES process2 architecture is defined to be the set of strategic design decisionsthat affect the structure, behavior or functionality of the system as a whole. The ROPESprocess goes on to discuss 5 primary aspects of architecture:

• Subsystem/Component Architecture – the large scale pieces of the system that canbe done prior to the decomposition of the system into hardware and softwareaspects, or may refer to the large scale software pieces, as appropriate for theproject.

• Resource Architecture – the identification of the concurrent tasks, how theprimitive “semantic” objects map into those threads, the scheduling policies, andpolicies for synchronization and resource management. This is also known as the“Concurrency Architecture” because it tends to focus on the management ofconcurrency in the system. Note that in the UML, the primary unit of concurrencyis the «active» object, which creates and owns the thread in which it executes.Note also that this is primarily a software architecture concern and has a relatively

1 Fear, Uncertainty, and Doubt2 Rapid Object Oriented Process for Embedded Systems. For more information see references [1] and [2].


minor impact on system engineering and hardware architectures.

• Distribution Architecture – the identification of how objects map into differentaddress spaces, and how they will communicate across those address spaceboundaries including distribution patterns (such as Publish/Subscribe, Broker, etc)and communication protocols.

• Safety and Reliability Architecture – the specification of how faults will beidentified, isolated, and managed during the run-time of the system. This typicallyincludes the redundant architectural substructures and their management in theevent of faults.

• Deployment Architecture – the specification of how the other architectural aspectsare mapped onto the underlying hardware environment. This can be doneasymmetrically, where each piece of software is assigned at design time to run ona particular hardware target, or symmetrically where run-time locale decisions aremade dynamically at run-time to permit load-balancing.

We call these architectural aspects because there is a single system that in fact containsall of these. Therefore the system model must likewise have an architecture that containsALL of these different aspects in a coherent and consistent way.

In the UML, diagrams may be divided into three different types – structural, behavioral,and function. Each of these architectural aspects is shown using one or more of thesediagram types. Structural diagrams include class, component, and deployment diagrams.Subsystem and component architecture is usually shown on either or both class diagrams(using the «subsystem» stereotype on the class boxes to indicate subsystem) andcomponent diagrams. Concurrency architecture structure is likewise shown on the so-called task diagram that is nothing more (or less) than a class diagram showing primarilythe «active» objects as well as optionally the classes used to help manage theconcurrency, such as queues and semaphores. Distribution and safety and reliabilityarchitectures are commonly shown with either or both class and deployment diagrams,the class diagrams emphasizing the classes and their relations, and the deploymentdiagrams emphasizing how those software parts map on to distributed and possiblyredundant hardware. And, of course the deployment architecture is shown pretty muchexclusively on the deployment diagrams.

In terms of behavior, the UML provides two different kinds of diagrams – diagrams thatshow dynamic interactions of multiple elements and diagrams that show the behavior ofan element in isolation. The former are called interaction diagrams and the most commonand useful form is the sequence diagram. Interaction diagrams show how a set ofelements interact over time, and provide an extremely useful guide to exactly how a theelements shown in a structural diagram interact dynamically. For behavior of individualelements, statecharts and their cousin, activity charts, are used. Both these diagrams can


depict the behavior of a UML Classifier, including class, subsystem, component, or usecase. In addition, activity charts of often used to show the algorithmic behavior ofoperations.

Functional diagrams refer to the expected or specified functionality of a system or systempart (e.g. subsystem or component) without regard to the design or implementation ofthat behavior. Use cases provide the organization means to capture required functionalityof the system and the behavioral diagrams mentioned above are then used to capture thedetailed specific requirements.

The “Proprietary” Approach to ArchitectureThe proprietary, single-vendor solutions to architecture require the invention of new,proprietary diagrams to replace the standard UML diagrams. The claim is that the UMLdiagrams are inadequate. Certainly this has been shown to be untrue by the thousands ofreal-time and embedded systems of a wide-ranging complexity – from very simple tovery complex – that have been successfully developed using standard UML. Thisproprietary approach typically uses 3 primary diagram types which, as we will see, areeasily created using the standard UML diagrams.

System Architecture DiagramsThe SADs, or System Architecture Diagrams, concentrate on trying to show two primaryarchitectural aspects from the above discussion – subsystem/component architecture anddeployment architecture. Figure 1 shows a subsystem diagram from Rhapsody using the(optional) iconic form.


Figure 1: Subsystem Diagram in Rhapsody

Figure 1 shows both the icon form and the standard class form for the subsystems. TheRobotArm_Subsystem shows the pieces of that subsystem using the standard UMLcomposition relationship. This is how subsystems normally work – the subsystem itself isa run-time container of smaller elements that do the real work. When the arm gets acommand to perform some activity, it delegates that responsibility to its internal pieces,which it owns via composition. The diagram also illustrates how constraints are typicallyshown – they are shown in the UML diagrams connected to the elements to which theyrelate. This is in contradistinction with the proprietary approaches that may clump themall in a separate “Constraints” diagram. While that can be done as well (and we’ll showyou in a little bit how to do that), most engineers find it more useful to show theconstraints in the context of the elements they are constraining.

The question arises how these subsystems interact at this level. This is where a sequencediagram is very useful. It can show the interaction of elements at any level of abstraction.Figure 2 in fact shows the interaction of the elements of Figure 1 at two levels ofabstraction – the subsystem and the pieces inside a couple of them.


Figure 2: Interaction of Subsystems via Sequence Diagrams

Between the class diagram, showing the subsystem architectural structure and thesequence diagram, showing the interaction of those elements, we can easily understandhow the elements work together. This executability provided by Rhapsody and the UML,as we will see later, is key to proving the correctness of the architecture. How do youknow the architecture is correct? By showing that it executes correctly and efficiently tomeet the system functional and quality of service requirements.

We can also focus on the deployment architecture using the deployment diagrams inRhapsody 4.0. Figure 3 shows a typical deployment diagram with heavy use of icons toshow the stereotype. If we desire, we can omit the icons and show the stereotype usingthe guillemot notation (e.g. «processor» or «motor»), or not deal with stereotypes at all.


Figure 3: Deployment Architecture in Rhapsody (with Icons)

We can even show how software components map onto the deployment architecture, asin Figure 4. We can show simple deployment architectures, or, as we see, more elaborateones depicting more details of the hardware organization. UML component are depictedin standard form as a box with two smaller boxes attached on one side. Figure 4 shows anumber of different software components on the two processor nodesDataAcquisitionSystem and DataProcessingSystem.


Figure 4: Mapping Components onto Deployment Architecture in Rhapsody

Since these are standard UML diagrams shown here, we can easily see that anything canbe represented on SADs can be depicted in UML with Rhapsody.

Concurrency DiagramsThe concurrency model is of vital importance for most real-time systems. Remember thatin the UML a Task or Thread is represented as an «active» object – an object that createsa thread to run in when it is created and then executes in that thread. Passive objectsowned (via the UML composition relation) by an active object execute within the threadof the active object. When creating a “Task Diagram” or “Concurrency Diagram” theprimary elements of the diagram to show are the «active» objects. Other things may beshown as well, if desired, such as the schedulability and timeliness constraints applied tothe elements (see [4] for some standard constraints for schedulability and timeliness),objects used for synchronization and resource sharing (such as objects stereotyped as«resource», «mutex», and «queue»), passive objects contained within the active objects,and so on. That is, we can show as much or as little detail as we need to in order to make


the concurrency model clear. Note that we don’t need to stereotype objects as «resource»or «mutex», but their role may be clearer if we do so.

In the UML, the standard icon for an active object is a class box with a heavy border line.

Figure 5: Concurrency Diagram

Constraint DiagramsAnother proprietary constraint diagram collects up all the constraints and groups themtogether. We’ve seen that the common way of managing constraints is to put them next tothe element(s) to which the constraint applies and most engineers prefer this approach.However, if desired, a constraint diagram can easily be constructed as a class diagram onwhich you only show constraints. Again, you don’t need to go outside of the UML tomodel the real-time aspects of your system.


Figure 6: Constraint Diagram in UML

Other Architecture DiagramsThe other architectural diagrams can be depicted using the standard UML diagrams aseasily as those above. Safety and reliability architecture for example, normally shows theredundant subsystems on a class or deployment diagram and then shows how theseredundant subsystems interact with one or more sequence diagrams.

How do You Know It’s Right?In the hardware design world, when a portion of a design is complete, it is simulated andtested before the design is considered valid, before the system is constructed. While thisis becoming more true with the advent of the UML and executable tools such asRhapsody, it is still most common to build the entire system, hoping that the architecturewill be adequate but without actually testing it. The problem with this approach is thatarchitectural defects can be as much as 10,000 times the cost of simple coding efforts toidentify and repair.


The reason is that architectural defects have broad-sweeping effects, since most or allelements in the system design must be congruent with the architecture. When thearchitecture is changed, then all of the design elements must likewise be changed toaccount for the different architecture. If we can do early architectural testing, we canidentify and eliminate these strategic defects while relatively few design elements dependon them and they are inexpensive and easy to correct.

This is, in fact, the basis for the success of the iterative lifecycle approach todevelopment. By building the system incrementally, we test the architecture as early aspossible, even if it is incomplete. As the design gets fleshed out, the architecture isretested with the evolving prototype. In this way, the system correctness is assuredthrough testing, early and often. This creates a more reliable, robust system at a lowercost than the traditional “build the entire thing and pray” approach.

So how do I do this, you ask? It turns out to be surprisingly easy with a fully executabletool such as Rhapsody. In the UML, you can draw the subsystem and componentarchitecture on a class diagram and execute the system at that level of abstraction. It is asimple matter usually to show, given reasonable expectations of the design andimplementation of the subsystems, that the subsystems are correctly collaborating torealize the system use cases. If the system use cases are captured with sequence diagrams,then they can be the basis of the proof-through execution of the architecture.


Figure 7: Systems Requirement Use Case Scenario

Figure 7 shows a typical systems requirement use case scenario in which only objectsshown are the actors and the system use case (the System object can be used here instead,if desired). The internal subsystem architecture can then be elaborated, as shown inFigure 8.


Figure 8: Subsystem Architecture

Now we can execute the requirements with this architecture. We can now add thesesubsystem elements and, via execution, show how they collaborate to realize the samerequirements. We do this by elaborating the sequence diagram, adding these architecturalelements, showing how these elements work together. Since Rhapsody is an executabletool, we can run the model and capture the collaborative behavior in a sequence diagram.

The next two figures show how the subsystems collaborate to realize exactly the requiredbehavior from Figure 7. The same messages between the use case and the actors arethere, but in addition, the messages among the subsystems as they collaborate togetherare added, making a more complete picture of how the architecture works to satisfy therequirements.


Figure 9: Elaborated Sequence Diagram 1


Figure 10: Elaborated Sequence Diagram 2

SummaryThe UML has found great acceptance in the real-time and embedded world. There aremany reasons for this. First, it is a standard, meaning that a variety of tools, emphasizingdifferent aspects of the UML or providing different features provide a wide selection;training is widely available; there are dozens of reference books available on applying theUML in all kinds of different environments and in many different ways. A proprietarymethod locks the engineer into a single vendor, with no possibility of hiring staffexperienced in that approach, no available reference books, training available only fromthat single vendor, and into a single tool which may, or may not, meet your needs. Manypeople use UML today to build simple embedded systems as well as very complexavionic, space and military systems. The UML is, as we have seen, very expressive andcan capture your system model, not merely as a set of figures without meaning – but with


a well-defined semantic base that can be used to automate the generation of executablecode, automate testing, apply formal verification methods, and so on.

We have also seen that this proprietary method really offers nothing that cannot be donealready in the UML. Clearly, as Grady Booch has said, and as hundreds of engineershave learned through practical application, “The UML is completely adequate for real-time systems.”

References[1] Douglass, Bruce Powel “Rapid Object Oriented Process for Embedded Systems”,available for download from www.ilogix.com

[2] Douglass, Bruce Powel “Doing Hard Time: Developing Real-Time Systems withUML, Objects, Frameworks, and Patterns” Addison-Wesley, 1999

[3] “OMG Unified Modeling Language Specification version 1.4”, available fordownload from www.ilogix.com or www.omg.org

[4] “Response to the OMG RFP for Schedulability, Performance, and Time” June 2001,available for download from www.ilogix.com or www.omg.org

R h ap sod y for S ystem s A rch itectu re Ð B etter A rch...

Documents

Transcript of R h ap sod y for S ystem s A rch itectu re Ð B etter A rch...