7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

Including SysML in the 4+1 View Model of

Architecture for Software-Intensive Systems
Michel dos Santos Soares1 and Jos Vrancken2
12
Delft University of Technology, The Netherlands, {m.dossantossoares, j.l.m.vrancken}@tudelft.nl

Abstract
The 4+1 View Model of Architecture consists of four views, named logical, process, implementation and deployment, and the
plus one, the use case or scenario view to integrate the other views. The architecture is generic, in the sense that there are no
specific recommendations on which languages and methods to use at each one of the views. As UML is nowadays the de facto
Software Engineering modeling language, using its diagrams is common when creating software models using the 4+1 View
Model. Nevertheless, software-intensive systems are normally large scale systems in which software plays a fundamental role,
but other elements are also important. The purpose of this article is to show where and how SysML, a Systems Modeling
Language applied to model other elements than just the software in a software-intensive system, can be included in the 4+1 View
Model of Architecture. For each view, UML and SysML diagrams are jointly used. This will bring together Software and Systems
Engineering domains, and extend the 4+1 View Model of Architecture to be used in a Systems Engineering context. The article is
a result of the application of these ideas in a company that develops road traffic management systems.

Keywords - UML, SysML, 4+1 View Model of Architecture, Software-Intensive systems.

cases [8]) to the whole language (too many diagrams [9],
1 Introduction semantics problems [10][11]).
Software-intensive systems are systems in which software
plays a fundamental role, influencing the design, From a Systems Engineering point of view, important
construction, deployment and evolution of the whole characteristics are lacking in UML. As a software-oriented
system [1]. Examples can be found in many domains, such language, it lacks modeling power, which is fulfilled by
as telecom networks, transportation, military command and other languages, leading to additional integration efforts.
control, and manufacturing systems. Independently of the The emphasis is on the graphical modeling of functional
domain, normally these are large scale, highly distributed requirements, and little attention (if any) is paid to other
systems, which are difficult to design, implement and requirements types. For instance, there is no specific
evolve. diagram to model non-functional requirements, which are
proved to be fundamental for systems’ success. The UML
A common accepted notion for developing software- Activity diagram models discrete behavior, but does not
intensive systems is that having a well-defined architecture have easy means to model continuous flow. In general,
description is essential. Empirical results and practical UML is weak on modeling other elements that are not
experience show that systems with defined architecture are related to software, such as hardware, machines and their
resilient to change [2]. Future systems’ maintenance and parts, relationships, properties and constraints.
evolution are facilitated when the architecture is clear for
all stakeholders. In summary, architecture is a critical In order to address the specific problems from a Systems
element for developing software-intensive systems. Engineering point of view, a Request for Proposal [12] was
issued to create a language designed to model systems that
Among the software architectures proposed in the literature, involve software and would also be capable of modeling
we investigate the 4+1 View Model of Architecture [3], other engineering components. As a result, the SysML
which is used in the RUP process [4]. The architecture language [13] was created.
consists of four views (logical, process, deployment, and
implementation) and the plus one (use case) crosscutting Our proposal in this article is to describe where and how
view that integrates the other four. Although not advocating SysML can be included in the 4+1 View Model of
a specific method or language for design, normally the most Architecture, and the possible advantages of combining
common modeling language associated with the 4+1 View UML and SysML models. Theoretically the approach
Model is UML [5]. seems to be feasible due to two important facts: 1) UML
and SysML are conformant to the same metametamodel,
UML is heavily criticized (perhaps because it is the most the MOF [14]; and 2) SysML reuses and adapts diagrams
used graphical modeling language in Software and constructs from UML. In order to prove that the theory
Engineering). Criticism varies from specific diagrams is sound, we are applying in practice the approach in this
(Sequence diagrams poor time representation [6,7], Use research, by using it in a company that develops Road

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

Traffic Management Systems. The evaluation steps are: 1) 3 The 4+1 View Model of Software Architecture
Build a pilot application using SysML and UML diagrams A view is an abstraction of a system from a particular
to design models according to the 4+1 View Model; 2) perspective, covering particular concerns and omitting
Introduction of SysML to the company employees, through elements that are not relevant according to the specific
a course; 3) Evaluation with the employees, through perspective.
interviews and surveys; 4) Application on real projects; and
5) Changing the current development approach used at the The 4+1 View Model proposes the organization of the
company. In the discussion section, each step will be description of a software architecture using five concurrent
explained. views, each one addressing one specific set of concerns.
Separating concerns in views avoid the misunderstandings
The article is organized as follows. The importance of and incorrect interpretations when a single view of the
describing the architecture for software-intensive systems is architecture is described. For instance, common elements
presented in Section 2, and Section 3 briefly presents the used to describe the architecture, such as blocks and arrows,
4+1 View Model of Architecture. The SysML language is may represent different elements depending on which view
introduced in Section 4 and used in Section 5, in which how is described. If the semantics of the view is not clear, its
and where the SysML diagram can be inserted in each view elements will be incorrectly interpreted. A brief description
is shown. A case study on the domain of Road Traffic of each view is given as follows.
Management Systems is presented in Section 6. The article
ends with discussion and conclusion. Logical view: the concerns of this view are the functional
requirements of the system. When using an object-oriented
2 Software Architecture Importance approach, the main elements are classes and relationships,
In simple terms, the description of the architecture involves such as association, composition, aggregation and
the elements that compose the system and how they inheritance. Only relevant elements, in terms of the
interact, including the interaction points. One formal architecture, are represented. In this view, how classes
definition, given by [1], is that a “Software architecture is cooperate with each other and the internal behavior of
the fundamental organization of a system, embodied in its classes are also described.
components, their relationships to each other and the
environment, and the principles governing its design and Implementation view: the system is decomposed into
evolution”. subsystems, which are organized in layers and packages,
which contain components, executables, files and source
Architecture is part of design, but with focus on major code. A layered implementation approach offers separation
elements, such as major classes and their communications, of concerns, from domain-specific and hardware
patterns, frameworks, layers, subsystems, components and independent (top layers) towards domain independent,
interfaces. The way these elements are distributed, hardware specific (bottom layers). Constraints depend on
communicate with each other and with the system the programming language and the development
environment is also described in the system architecture. A environment. For instance, it is important to take into
common misconception is that architecture is only about account the modularization capabilities of the programming
structure of elements and their relationships. Architecture is language. This view can also help in defining parts to be
also about behavior and interfaces between elements. built by subcontractors or internal development teams.

Decisions made when defining the architecture have long- Process view: address the concurrent aspects of the system
lasting impact on the design and major quality attributes of at runtime - tasks, processes, threads, as well as their
a software-intensive system, such as performance, evolution interactions. Examples of inter-process communication
and safety. These decisions will reflect on design models mechanisms include synchronous communication, remote
and on system implementation. As a matter of fact, the procedure calls, publish-subscribe, and event broadcast.
architecture description is an effective communication Many aspects are addressed in this view, such as
mean between different stakeholders. parallelism, fault tolerance and object distribution in real-
time, dealing with issues such as deadlocks, response time
Poor architecture definition is recognized as a major and scalability.
technical risk when designing a software-intensive system
[15]. Research on software architecture is rapidly growing Deployment view: shows how the various executables and
as many researchers and practitioners recognize the other runtime components are mapped to the physical
importance of having a well-defined architecture to support processing nodes and platforms.
activities such as project management, design and
implementation. Many architecture models were proposed Use Case view: contains the main scenarios that are
in the past years, such as [16][1][17]. The focus of this represented as use cases. These scenarios act to illustrate in
article is on the 4+1 View Model of Software Architecture. the software architecture document how the other four
views (and elements) collaborate in order to realize the use
case.

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

Diagrams), some are derived with changes (Activity, Block

The 4+1 View Model of Architecture is generic, thus it is Definition, Internal Block Diagrams) and there are two new
possible to use diverse diagrams/languages for each view. diagrams (Requirements and Parametric Diagrams). As a
In fact, the original paper published in 1995 used the Booch matter of fact, SysML is compatible with UML, which can
method [18] to model the examples. Currently, UML is facilitate the integration of the disciplines of Software and
commonly used to design the models of each view. In this System Engineering.
article, SysML, a UML profile for Systems Engineering is
proposed to be used jointly with UML. 5 Adding SysML in the 4+1 Views

5.1 Logical view

4 Systems Modeling Language Currently, common diagrams used for creating models for
SysML (Systems Modeling Language) is a graphical this view are the UML Class and Object diagrams, for the
modeling language that supports the specification, analysis, structural aspects, and the Sequence and Activity diagrams
design, verification and validation of a broad range of for dynamic aspects. Three SysML diagrams are proposed
complex systems [13]. The language is an evolution of for this view.
UML 2.0 to be applied to systems that may include
hardware, software, information, processes and personnel. With the SysML Block diagram, elements of the system
This may facilitate the communication between such as hardware, data, procedures, and persons can be
heterogeneous teams (for instance, mechanical, electrical modeled. The representation of system architecture can be
and software engineers) that work together to develop a made by means of blocks, without concerning only on the
system. The basic difference from UML is that SysML was software structure of each system element, but also on the
built from scratch to support System Engineering activities, general structure, including parts of each block, constraints
which means that some specific software oriented and properties not necessarily related to software. SysML
constructs and diagrams not necessary to systems modeling Blocks are candidates to be refined as one or more UML
were avoided. The language is effective in specifying Classes during the software design and implementation
requirements, structure, behavior, allocations of elements to phases.
models, and constraints on system properties to support
engineering analysis. SysML is supported by the OMG The SysML Requirements diagram allows crosscutting with
Systems Engineering Domain Special Interest Group and other diagrams, mapping a requirement to other design
by INCOSE (International Council on Systems models. Relationships between requirements, and their
Engineering). It is expected that the language will become a classifications, are also represented, being useful for
de facto standard for Systems Engineering, just like UML is requirements management and to plan system releases. For
for Software Engineering. instance, when a requirement is modified, it is possible to
trace which requirements and models are affected, and how
they are going to be affected. In addition, knowing all
requirements dependencies show the stakeholders which
requirements may have priority over others and need to be
implemented first. Another difficulty when using UML
only is to map directly requirements into UML Use Cases
[19]. The main advantages of using SysML Requirements
diagrams are the graphical representation of requirements,
the improved requirements traceability through system
development, and the possibility of modeling other
requirements types, such as non-functional and external
ones.

Figure 1 - The SysML diagrams structure and their relation The SysML Sequence diagram offers the same syntax and
to UML. elements of the UML counterpart, but with different
semantics. Within UML, Sequence diagrams are used to
Both SysML and UML languages are conformant to the model communication between software objects, which are
same metametamodel, the OMG Meta Object Facility instances of software classes. In SysML there is no notion
(MOF) [14]. SysML is considered both a subset and an of instance or objects. Thus, the communication is between
extension of UML 2.0 (Fig. 1). As a subset, UML diagrams the main structural elements, normally blocks and
considered too specific for software (Objects and subsystems. Another difference is that the messages
Deployment diagrams) or redundant (Communication and exchanged are not methods of an object.
Time Diagrams) were not included in SysML. Some
diagrams are derived from UML without significant 5.2 Process view
changes (Sequence, State-Machine, Use Case, and Package The Class diagram can also be used in this view, but the
focus is different from the logical view. The classes at this

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

view are active classes that represent threads and processes, sensors and the effects of the application of actuators are
such as the <<control>> stereotype for classes used within important quantities to be visualized for decision makers.
RUP. Thus, having application systems that can visually show
numerical values resulting from measurements is
The UML Activity diagram is used with emphasis in tasks, fundamental. This case study is about a system that
main processes and flow of control. The SysML Activity provides visualization of road traffic measurements at
diagram offer additional modeling possibilities when junctions controlled by traffic signals. It can be seen as a
comparing with the UML version. The notion of token decision support tool for traffic operators, providing
flowing along edges through the activities still exists, but reliable, real-time information of road traffic measurements,
there is support for modeling continuous flow as well as which can be useful to improve traffic signals planning.
discrete flow. A rate describing the frequency in which This application will be used as a subsystem for other road
elements traverse an activity edge can be added to inflow traffic management systems.
and outflow edges. To each edge, <<continuous>> or
<<discrete>> stereotypes can be added depending on the The location where traffic can change its routes, directions
flow type. The flow can also contain a specific probability and sometimes even the mode of travel is named Junction
of occurrence of an activity/task, which describes at each (Fig. 2). A junction comprises the outgoing Main link and
outgoing edge how probable it is that the token will flow the incoming Accessor links of a crossing or motorway.
over it. Each Main link and Accessor link only belongs to one
specific junction. For each direction of the Accessor link
5.3 Deployment view (turn left, go ahead, or turn right), information about
SysML does not provide a deployment diagram. This velocity, waiting time, intensity and density is shown in the
decision, as well as not including other UML diagrams such system (Fig. 3). An automated image of the junction is
as Object and Time, was taken in order to simplify the created based on links information. This image and a table
language and to avoid the notion that other engineers with measured data are shown in a graphical user interface.
should first learn the object-oriented notions in order to The list of requirements and some models of each view are
understand SysML. As a SysML block can describe general shown in the following subsections.
structural elements, varying from very small to very large,
they can be used to represent the physical deployment
nodes.

5.4 Use Case view

The Use Case view (formerly known as the scenario view)
is most frequently modeled with UML Use Case diagrams
and natural language for descriptions. The SysML Use Case
diagram is derived without important extensions from the
UML Use Case diagram. The main difference is the more
wide focus, as the purpose is to model complex systems
that involve not only software, but also other systems,
personnel, and hardware.
Figure 2 – A Junction representation.
The SysML Use Case diagram shows system functionalities
that are performed through the interaction of the system
with its actors. The idea is to represent what the system will
perform, not how. The diagrams are composed of actors,
use cases and their relationships. Actors may correspond to
users, other systems or any external entity to the system.

5.5 Implementation view

The Package diagram is used to organize semantically close
models by partitioning elements into packages and
establishing dependencies between the packages and/or
Figure 3 – Measurements table.
model elements within the package. The same syntax and
semantics are presented for both UML and SysML Package
diagrams. 6.1 List of requirements
1. For each direction, the user wants to visualize
6 Case Study information about splitfactor and waiting time.
2. The number of directions depends on the number of
The case study proposed is a system to visualize
Accessor links.
measurements at junctions. Measurements obtained by

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

3. The symbol “-” should be used in the place of 9. The information shown shall be from all Accessor links
numerical values when there is no direction. into the junction;
4. Junction must have an automatic created image based 10. The information shall be shown for each traffic stream
on Links information; into the junction;
5. Junction image must be by default on the geographical 11. Accessor link information should contain the
map (Trinivision). splitfactor.
6. Junction image on the geographical map (Trinivision) 12. Information about intensity and waiting time must be
must be shown in a small form shown when there is a Direction with an actuator or
7. Clicking in the junction image will result in an sensor from the Accessor link.
overview from this image containing the junction
information;
8. The junction image must have an understandable and
representable layout;

Figure 4 – The SysML Requirements diagram modeled based on the system list of requirements.

6.2 Logical view 6.3 Process view

For this view, the list of requirements was modeled using The SysML Activity diagram of figure 6 shows the general
the SysML Requirements diagram (Fig. 4). Two extensions process view. Initially, based on data of the location of
for the basic SysML Requirements diagram were used, as Links, a single visualization of the junction is created. A
proposed in [20, 21]. The first is to group requirements into table similar to the one shown in figure 3 is inserted in the
sub-packages of requirements, when these are semantically junction image, for each group of Accessor links. The
related. The second is to specify a requirement as image is created only once; only data filled in the table
Functional, Non-functional or External. Part of the UML changes, which provide better performance.
Class diagram for this view is shown in figure 5.
The rate of the signal “Direction_update” is “rate = 60 s”,
which means that every minute a signal is sent from the
Direction to the Junction process with data about the road
measurements. These data are formatted as a table and
shown in the Graphical User Interface (GUI).

Distributed software objects in a network must

communicate with each other by asking and providing
services. There are many different means of implementing
process communications [22]. The simplest is by using
synchronous communications, based on point-to-point and
blocking communication between processes. This type of
communication presents many disadvantages [23]. As
processes have to wait for a response in order to continue
further operation, performance is reduced. In addition, there
is lack of transparency and flexibility, as it is necessary to
Figure 5 – UML Class diagram. know which process to call for a given service. The

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

environment characteristics (distributed elements in a Each layer can be detailed into sub-layers, and sub-layers
network) imply a need for a distributed system architecture, can be combined into layers, providing flexibility for
and the real-time constraints, which calls to high development. Finally, regular changes may be easily
performance, are important non-functional system implemented when they are related to a specific layer
requirements. Not only having correct data is important, but instead of to a whole system.
also the availability of data. Respecting real-time
constraints is difficult as sensors and actuators are The Presentation layer is used mainly only to present the
physically distributed, which increase the possibilities of applications results, and can be made for diverse
missing or receiving data outside of the bounded time. This devices/platforms. Developers may use a list of existing
indicates the importance of using an asynchronous Generic Components and combine them as much as
middleware to coordinate communication and data necessary to help in building Functional Components,
exchange between software objects. which implement the user requirements.

The Publish-subscribe middleware provides a high-level of

abstraction, by hiding the complexity of dealing with a
variety of platforms, networks and low-level processes
communications. Application developers may use lower-
level services provided by the middleware when necessary.

The Junction Measurements Visualization is one

application running together with many others. Their
objects may be used concurrently in other applications and
should not be blocked in time or even wait for a
synchronous response, which could provide an inadequate
performance for other applications. New applications may
be easily accommodated in the layered structure. Thus,
when a new functionality is built, there is no need to change
the middleware layer.
Figure 6 – Activity diagram modeling the general process
view.

Due to the systems characteristics and non-functional

requirements, such as efficiency, scalability and high-
performance demand, it was chosen to use Publish-
Subscribe middleware [24] for inter-process
communication. Publish-Subscribe middleware provides
higher levels of abstraction, hiding the complexity of
dealing with a variety of platforms, networks and low-level
processes communications. This is an important issue
according to modern Software Engineering. Application
developers may concentrate only on the current
requirements of the software to be developed, and use
lower-level services provided by the middleware when
necessary.

6.4 Implementation view

The layered architecture model of implementation is
depicted in Fig. 7. Layered models are ideally suited to
express important parts of the architecture, describing a
way to organize systems by separating similar and related
components in layers. Each layer accommodates related
semantic models, providing strong separation of concerns,
which is considered essential for distributed real-time
systems development.
Figure 7 – Layered Implementation view.
There are many advantages of using a layered architecture
for developing systems [25]. Layers allow showing diverse 6.5 Use Case view
levels of abstraction, from specific, top levels, towards SysML Use Cases offer the same syntax and elements of
general, lower levels, hiding details whenever convenient. UML Use Cases, but with a different, more generic

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

semantics. One SysML Use Case diagram can be further relationships types that describe traceability between
refined into several UML Use Case diagrams. Figure 8 models. The relationships are also useful to aid
shows the Use Case diagram for the list of requirements of requirements prioritization in order to decide which
subsection 6.1. Each Use Case can be described by a requirements should be included in a certain system release.
number of scenarios, and each scenario can be specified by Another advantage of using the SysML Requirements
a Sequence diagram. Within SysML, a Use Case may also diagram is to standardize the way of specifying
be related to a SysML Requirements diagram. requirements through a defined semantics. As a direct
consequence, SysML allows the representation of
requirements as model elements, which mean that
requirements are part of the system architecture.

Figure 8 – Use Case diagram.

7 Discussion
Experience shows that the 4+1 View Model of Architecture
is sufficient and efficient to most companies in many
projects [4]. A survey and interviews at Trinité also show
that all views are being used, and that they are sufficient for
their systems.

The research methodology was inspired by Action

Research, which supports that researchers should test their
theories with practitioners in real situations and real
organizations [26]. In order to introduce SysML in the 4+1
View Model, five main steps were followed (Fig. 9):
Figure 9 – Research steps.
Step 1: design an application using SysML jointly with
UML, using the company’s development environment The SysML Activity diagram is more powerful than the
(middleware, programming language, components). The UML version, as it can attach rates and probabilities to
final design was presented to the company’s managers. Part edges connecting the activities. Another change is the
of the design is show in section 6 of this article. possibility of representing continuous processes as well as
Steps 2 and 3: lecture a course on SysML, UML and discrete ones, as was usual with UML. The diagram was
software architecture to the company’s employees, and shown to be useful to describe general processes, and also
evaluate the possible changes in terms of suitability to later refine activities into more specific Activity
according to the company’s current development diagrams, in order to specify algorithms to be implemented.
environment.
Step 4: development of applications by the employees that In terms of Use Cases and Sequence diagrams, there is no
have attended the course and evaluated the language (steps real difference in practice, as the company already makes
2 and 3). intensive use of these diagrams when designing
Step 5: continuous improvements based on lessons learned applications, and there were no major changes from the
through steps 1 to 4. UML to the SysML version.
Considering the many proposed changes and In general, the fact that the introduced modifications are
recommendations, some of the most important ones are compatible with the current development process is
presented in this section. positive. Radical changes are too costly and risky, and
should be avoided in practice. An approach with few
Introducing a diagram to represent other types of changes, maintaining compatibility with the current
requirements, besides the functional type, was considered situation, is more likely to succeed. An important advantage
very useful. As usual in systems development, requirements cited by Trinité is that the basic development environment
changes are likely to happen, and using the SysML and document templates can still be used.
Requirements diagram is useful for developers to control
these changes. For instance, when a stakeholder asks for a 8 Conclusion
change in one specific requirement, the impact on other
models and subsystems can be shown, using the many This article presents the result of a research which main
purpose is to introduce a new language, the SysML, into an

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

existing model of architecture, the 4+1 View Model. The [11] Harel, D., Rumpe, B. (2004), “Modeling languages:
research methodology is based on Action Research, in Syntax, semantics and all that stuff (or, what's the semantics
which researchers work together with practitioners in order of "semantics"?)”, IEEE Software.
to apply the developed theories and test them in practice.
The proposed theory was applied in a pilot project and was [12] OMG, (2003b), "UML for Systems Engineering RFP",
shown to present many advantages. Currently further OMG: Request For Proposal, ad/03-03-41.
evaluation is being performed, and changes to the
company’s development process are being implemented. [13] OMG, (2007), Systems Modeling Language (OMG
Instead of performing radical changes, the advantage of the SysML) v1.0. OMG Available Specification. Document
approach is to use two similar languages, UML and SysML, number: formal/2007-09-01.
together, each one complementing the other. This approach
was shown to be feasible during the evaluation with the [14] OMG, (2006), "Meta Object Facility (MOF) v 2.0 ".
company’s employees. Further research will be concerned OMG Document: http://www.omg.org/spec/MOF/2.0.
with keep improving the current development process, until
a general accepted document template is approved for each [15] Clements, P., Garlan, D., Bass, L. Stafford, J., Nord,
phase of the development process. R., Ivers, J. Little, R. (2002), Documenting Software
Architectures: Views and Beyond, Pearson Education.
9 References
[16] Soni, D., Nord, R., Hofmeister, C. (1995), “Software
[1] ISO/IEC (2007), ISO/IEC 42010:2007, Systems and Architecture in Industrial Applications,” Proc. 17th Int’l
Software Engineering - Recommended practice for Conf. Software Eng. (ICSE 95), ACM Press, 196–207.
architectural description of software-intensive systems.
[17] Wisnosky, D.E., Vogel, J. (2004). DODAF Wizdom: a
[2] Booch, G. (2007), “The Economics of Architecture- Practical Guide to Planning, Managing and Executing
First” IEEE Software 24(5) 18-20. Projects to Build Enterprise Architectures using the
Department of Defense Architecture Framework, Wizdom
[3] Kruchten, P. (1995), "The 4+1 View Model of Systems, Inc.
Architecture", IEEE Software 12(6) 42-50, November.
[18] Booch, G. (1993). Object-oriented Analysis and
[4] Kruchten, P. (2003), The Rational Unified Process: An Design with Applications (2nd ed. ed.). Redwood City:
Introduction, Addison-Wesley Longman Publishing Co., Benjamin Cummings.
Inc., Boston, MA.
[19] Anda, B., Hansen, K., Gullesen, I., Thorsen, H.K.
[5] OMG (2003a), Unified Modeling Language: (2006), “Experiences from introducing UML-based
Superstructure (final adopted spec, version 2.0, 2003-01- development in a large safety-critical project”, Empirical
02). Object Management Group. Software Engineering 11(4), 555-581.

[6] Soares, M.S., Julia, S., Vrancken, J. (2008), “Real-time [20] Soares, M.S., Vrancken, J. (2008), “A Proposed
Scheduling of Batch Systems using Petri Nets and Linear Extension to the SysML Requirements diagram”. IASTED
Logic”, Journal of Systems and Software 81(11) 1983- International Conference on Software Engineering, Austria,
1996. pp. 220-225.

[7] André, C., Mallet, F., de Simone, R. (2007), Modeling [21] Soares, M.S., Vrancken, J. (2008), “Model Driven
Time(s), Proceedings of the ACM/IEEE International User Requirements Specification using SysML”, Journal of
Conference on Model Driven Engineering Languages and Software 3(6) 57-68.
Systems (MoDELS/UML), USA. Springer Verlag, LNCS
4735, pp. 559-573. [22] Tanenbaum, A.S. van Steen, M, (2006), Distributed
Systems: Principles and Paradigms (2nd Edition), Prentice-
[8] Simons, A.J.H. (1999), "Use cases considered harmful," Hall, Inc., Upper Saddle River, NJ.
Proceedings of Technology of Object-Oriented Languages
and Systems, pp.194-203. [23] Lea, D., Vinoski, S., Vogels, W. (2006), "Guest
Editors' Introduction: Asynchronous Middleware and
[9] Dobing, B., Parsons, J. (2006), “How UML is used”, Services," IEEE Internet Computing 10(1), 14-17.
Communications of the ACM 49(5), 109-113.
[24] Fiege, L., Cilia, M., Gero, M., Buchmann, A. (2006)
[10] Henderson-Sellers, B., Cook, S., Mellor, S., Miller, J., "Publish-Subscribe Grows Up: Support for Management,
Selic, B. (2005), “UML the Good, the Bad or the Ugly? Visibility Control, and Heterogeneity," IEEE Internet
Perspectives from a panel of experts”, Software and Computing 10(1), 48-55.
Systems Modeling 4(1) 4-13.

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

[25] Vrancken, J. (2006), "Layered Models in IT

Standardization," IEEE International Conference on
Systems, Man and Cybernetics, SMC '06, vol.5, pp. 3862-
3865.

[26] Avison, D.E., Lau, F., Myers, M.D., Nielsen, P.A.

(1999), “Action research”, Communications of the ACM
42(1), 94-97.

10 Acknowledgements
The authors would like to thank Trinité B.V.
(www.trinite.nl), a Dutch company that develops Road
Traffic Management Systems, where part of this research
was performed. This work was supported by the Next
Generation Infrastructures Foundation and the Research
Center Next Generation Infrastructures, both situated in
Delft, The Netherlands

Loughborough University – 20th - 23rd April 2009