Integrating System and Software Engineering

Processes Using the Views and Viewpoints of a

New Discipline
Stephanie M. White
Computer Science & Management Engineering
Long Island University - Post Campus
Email: stephanie.white@liu.edu
Abstract-This paper presents the case that a new specialized
system engineering discipline is needed on complex software
intensive projects, in addition to the overall systems engineer, to
bridge the felds of systems engineering and the computer-related
downstream disciplines. Engineers in the new discipline are
specialists in computing aspects of a system including sofware,
computer, and communications engineering and work closely
with engineers who specialize in each of these disciplines. The
position presented in this paper is based on the author's project
experience and on discussions with members of the IEEE
Computer Society Technical Committee (TC) on the Engineering
of Computer Based Systems. The author was the founder and
served in many positions, including Chair of this TC.
Keywords-engineering, system, software, comuter,
computing, comlexit, ECBS, prcess, integration, views,
viewpoints
I. INTRODUCTION
Too many systems engineers do not have the background
required to adequately discuss, negotiate, and simulate a
complex distributed computer and communication system.
Sofware engineers may be able to develop the simulation, but
fequently lack the detailed understanding of the application to
know whether the simulation is a reliable representation of
conditions in the real-world system and its environment. A
new Computing and Communications Systems Engineering
discipline is needed. Engineers in this new discipline must
have a suffcient understanding of the domain and be able to
make intelligent decisions involving architecture and trade
offs in sofware, hardware, and communications.
Unfortunately, systems and sofware life cycle process
reference models are still not well integrated. Moore writes:
"the hard part <is> achieving a single process reference model
suitable for the life cycles of both systems and sofware" [ 1].
In 2005, the IEEE Computer Society submitted a proposal to
ISO System and Sofware Engineering Standards Committees
"to decouple the urgent problem of aligning the provisions of
the current models fom the longer-term problem of
integrating sofware and systems processes" [ 1]. Process
978-1-4799-2086-0/14/$31.00 2014 IEEE
integration is the eventual goal (see Fig. 1) and would result in
improved system architectures and integrated approaches to
quality objectives. Case studies are required to understand
what is needed to integrate the processes.
System
Engineering
Process
CURRENTLY
Sofare
Engineering
Process
Integrated System &
G
OAL. Sofare Engineering
Process
Fig. 1. The goal is process integration
It is important that the systems engineering and sofware
engineering process models be well understood and highly
integrated as inadequately considered system decisions can
affect sofware development in an adverse fashion. Yet, most
corporations and educational institutions are organized using a
discipline paradigm, which might work for building simple
components. Today, interdisciplinary knowledge and skills are
needed to develop most systems which are complex
distributed systems exhibiting holistic properties.
In the disciplinary paradigm, sofware engineering and
system engineering are not well integrated, and systems
engineers allocate sofware requirements to subsystems prior
to having a detailed understanding of the distributed system
requirements as a whole. Frequently, the system that results
has overly complex interfaces and poor performance. When
this occurs the architecture must be changed afer the system
is already built, resulting in an architecture that is diffcult to
maintain.
This paper explores an approach to improve integration of
system and sofware engineering processes. The approach
integrates two process related concepts. The frst concept
introduces a new discipline. Engineers in this discipline are
specialists in computing aspects of a system including
sofware, computer, and communications engineering and
work closely with engineers who specialize in each of these
disciplines. They also are suffciently knowledgeable in the
domain of interest and support systems engineers to defne
system requirements and architecture, and allocate
requirements to architectural components. This paper refers to
these engineers as Computing and Communications Systems
Engineers (CCSE), see Fig. 2.
Systems
Engineer
Systems
Engineer
Computing &
Communications
Systems
Sofare
Engineer
Systems
Engineer Sofare
Systems
Engineer
Current Levels of System Proposed Levels of System
Engineering Engineering
FIg. 2. Current and proposed levels of system engmeenng
The literature has called this interdisciplinary feld
Computer Based System Engineering (CBSE) and the
Engineering of Computer Based Systems (ECBS) [2], but
these terms are not widely used and are perhaps
misinterpreted. The second process concept relates to
viewpoints and views.
II. BACKGROUND
Views and viewpoints have their basis in the sofware
engineering principle of Separation of Concers, a term frst
used by Edsger W. Dijkstra in a 1974 paper [3]. Dijkstra
wrote: "Let me try to explain to you, what to my taste is
characteristic for all intelligent thinking. It is, that one is
willing to study in depth an aspect of one's subject matter in
isolation for the sake of its own consistency, all the time
knowing that one is occupying oneself only with one of the
aspects." Other authors wrote about the importance of
separating views. In 1979, David Paras discussed the value
of defning usable subsets and extensions (views) during
requirements engineering [4]. In 1992, Perry and Wolf wrote
about the worth of multiple views and styles for sofware
engineering [5].
Also in 1992, Ivar Jacobson frst used the tenn Use Case,
which is a task oriented system view. Use Cases identif user
tasks that a sofware system should support. Jacobson
promoted Use Cases as the basis for system development and
testing [6]. Stakeholders who interact with a system would be
most familiar with business, mission, and logistics use cases.
System engineers would be most familiar with use cases at the
level of system operation such as safe operation of a
manufacturing plant, and sofware engineers would be most
familiar with those use cases that are eventually implemented
in sofware.
In 2003 Clements and his co-authors wrote "We
discovered rapidly that architecture is not fat, but rather a
multidimensional reality, with several intertwined facets - or
views [7]. In 2009, Maier addressed system views, indicating
that systems architecting involves multiple views of the
system just as the architecture of a building involves
structural, electrical, and plumbing views [8]. Current methods
such as SysML address many views including context,
fnctional, behavioral, structural, information, deployment,
and operation [9], see Fig. 3.
SysMl Diagrams _ K|qU1|
'
|MI5
BOD
=

'

Fig. 3. SysML Collage, fom Wikimedia Commons,
http://commons. wikimedia.orgiwiki/File:Sysml_ diagrams_col
lage.jpg)
Many but not all system views are inextricably linked to
sofware views when aspects of the system are allocated to
sofware. Viewpoints depend on the point of view of the
stakeholder and can be domain oriented (vehicle, power,
health, entertainment), quality oriented (performance, security,
maintainability) and phase oriented (requirements, design,
development). Engineers trace business and system views and
viewpoints to views and viewpoints relevant to the
downstream disciplines. Providing a stakeholder with
models of his system viewpoint, rather than showing him
models of the whole system, allows him to focus on views
about which he is knowledgeable and informed. Viewing the
entire system architecture is confsing as the size and
complexity is too great. Hilliard writes "Although the use of
multiple views is a virtual holy grail of sofware and systems
engineering, its status appears less secure in the feld known
as Sofware Architecture. Yet, practicing architects need
views to manage the inherent complexity of the large,
sofware-intensive systems they specif and build" [ 10].
In November 2001, White, Melhart and Lawson edited an
IEEE Computer issue titled "Engineering Computer-Based
Systems-Meeting the Challenge". The issue was conceived
to address the need and potential approaches for a special
system engineering discipline focusing on the view of the
computing and communication system. The view of the CBS
engineer included sofware, hardware, humans, data, and
communications. The authors stated that "engineers face
increasing pressure to resolve the challenges of disparate
architectures, long interdisciplinary system life cycles, method
and tool incompatibility, and spiraling complexity". They
discussed the importance of an ECBS discipline (herein called
CCSE) for developing well-structured and consistent system
architectures and for addressing the challenges in building
complex sofware-intensive systems. They wrote: "CBS
engineers must understand the importance of achieving an
appropriate relationship between system architecture and the
life-cycle processes applied in conceptualizing, developing,
producing, operating, and maintaining computer-related
system content" [ 11]. Other academics and engineers have
agreed that a special system engineering discipline is needed
for addressing a system's computing and communication
aspects, including the eleven authors of the ECBS
Architecture Working Group Report [ 12], the fve authors of
the ECBS Proposed Curriculum at the Bachelors Level [ 13],
as well as the many members of the IEEE Computer Society
Technical Committee on the Engineering of Computer Based
Systems.
III. WHY THE CCSE DISCIPLINE IS NEEDED
The CCSE develops a system within a system; the
properties of which have pervasive effects throughout the
larger system. The Computing and Communications System
(CCS) consists of all components necessary to capture,
process, store, display, communicate, and manage
information. Components include sofware, processors,
networks, buses, frmware, application specifc integrated
circuits (A SICS), storage devices, and humans (who also
process information). Embedded CCS(s) interact with the
physical environment through sensors and actuators, and also
interact with exteral CCS(s). The CCSE has to have a good
understanding of the system in which the CCS is embedded,
for example an automobile, medical diagnostic system, or
stock exchange, and works closely with the project systems
engineer to understand normal and exceptional user scenarios,
defne architecture and detailed design, and develop
integration and acceptance tests.
CCS resources are fequently geographically dispersed
and under the control of different organizations. System level
engineering is needed to defme a holistic architectural
approach and avoid system level disasters. Systems
engineering of CCS(s) requires knowledge of distributed
computer system design and development, including in-depth
knowledge concering computer hardware, sofware, and
communication disciplines. Unfortunately, many systems
engineers of large physical systems do not have this
knowledge, and communication engineers and sofware
engineers perform their tasks without an integrated system
level approach to computer system requirements defnition
and allocation, architecture, security, reliability, safety, and
fault tolerance.
"Systems Engineering of CCS(s) is analogous to
traditional systems engineering, but the focus and necessary
skills are different. The concers of CCS engineering include
the following:

Defnition of CCS requirements,

Decisions concering processes and methods,

Design decisions concerning the distributed CCS
architecture,

Allocation of resources to component developers and
management of the coordinated process,

Allocation of fnctions and data to CCS resources
(processors, sofware, data stores, displays, human
computer interface),

CCS strategies with respect to safety, security, and
fault tolerance,

Global system management strategy,

Defnition of system services,

Performance allocations (timing, sizing, availability),

Testing (component, integration, interoperability with
the external environment),

Logistics support (maintenance, training),

Implementation of the CCS within the existing
environment" [ 14].
(A CCS was called a Computer Based System (CBS) in the
referenced paper.)
IV. THE DIFFERENCE BETWEEN SYSTEMS, CCS, AND
SOFTW ARE ENGINEERING
CCS engineering is an interdisciplinary discipline that
includes system engineering, electrical engineering, sofware
engineering, communications and human factors. To better
understand the differences between system engineering,
sofware engineering, and CCS engineering, consider how
these disciplines work together to develop a sophisticated
vehicle. The systems engineer has primary responsibility for
specifing and allocating requirements for the vehicle's
system. From the start of the program, the CCSE works with
the system engineer on system level requirements that relate to
the distributed processing system. One such requirement is:
"the vehicle operator shall be able to navigate." The systems
engineer and the CCSE make decisions concering the system
boundary. They decide which navigation functions the system
automates and which navigation fnctions the vehicle operator
performs. They also make design decisions. They decide that
the system will include maps and that a global positioning
system will provide location coordinates. To architect the
computer-based system, the CCSE must understand the global
positioning system and how the operator will use it, together
with the maps, to navigate. A second requirement is: "the
system must control speed to avoid hitting another vehicle."
To satisf this requirement, the systems engineer and CCSE
must perform tradeoffs and decide on various vehicle
components. They decide that a proximity sensor is needed to
provide data on nearby vehicles, see Fig. 4.
I Maps I
I
proXimitY
I
Sensor
E
I
Signal
r

rocessor
Navigation Collision Avoidance
Fig. 4. System components (a subset)
The CCSE must also determine what is done in sofware,
hardware, and frmware. These decisions affect performance
and maintainability as hardware can provide quicker
performance, but sofware is changeable. The CCSE must
make decisions with respect to resources and allocation.
These decisions determine the types of processors,
communication links and storage devices that are needed such
as signal processors for processing data fom the proximity
sensor and a CD ROM for storing the map database. Based on
dependability needs, the CCSE chooses fault tolerance
features such as dual buses, standby processors, fault tolerant
operating systems, and sofware recovery blocks. The CCSE
also optimizes the number of standard CCS parts as the use of
common components increases affordability. Standard
sofware and hardware parts and standard interfaces reduce
development and maintenance costs.
Afer considering various trades including processing
allocation, the systems engineer and CCSE defne the
subsystems and interfaces. Interfaces should be minimal for
ease of change and good maintainability. Vehicle subsystems
include Environment Sensing, Vehicle Sensing, Guidance and
Control, Online Connectivity, Security and Privacy, Integrated
Processing, and the Human Computer Interface, see Fig.5.
The sofware systems engineer works with the systems
engineer and CCSE on processing allocation, and has the
primary responsibility for sofware requirements and their
implementation. Each of these system engineers has a specifc
viewpoint that addresses a different level of systems
engineering, but together they address processing aspects
holistically. In our example, some sofware will be allocated
to the signal processor, and other sofware will be allocated to
data processors. Such allocation decisions can be difcult to
make and can seriously affect performance. Tools that
simulate sofware functionality running dynamically on
different hardware confgurations support these tradeoffs.
V. CCSE(S) ADD VALUABLE VIEWPOINTS & VIEWS
The example in the previous section is now extended to
show how views and viewpoints are used in the CCSE
discipline to support system development. In the previous
section we identifed two system level decisions in which the
CCSE participated. We shall further investigate the decision
that the vehicle shall avoid collisions through the use of a
proximity sensor, throttle control, and braking and steering
control. To support the design, expertise, simulation and
experimentation in a number of disciplines is needed:

Collision avoidance

Reliability and sensitivity of proximity sensors

Time to stop a car related to speed and mass

Impact of hard braking on vehicle occupants

Use of air bags to protect occupants in critical
situations
At the highest level, this seems like a job for vehicle and
system engineers. What value does the CCSE add to the
process? Let's look at different subsystem architectures. Each
component is normally supplied by a different corporation or
vendor. Components include a proximity sensor, ABS brakes,
steering, air bags, and a diagnostic system to detect problems.
Today, these components include computers and
sofwareirmware, and communicate over a local network. In
the near future, a vehicle will communicate with nearby
vehicles and other exteral sources to maintain safe operation.
To determine a reliable and maintainable architecture,
engineers should consider coupling and cohesion. If the
proximity sensor and the gradient sensor i the Sensing
Components do not require control but only supply periodic
data, they might be coupled via Integrated Processing.
However the CCSE might discover based on simulation and
experimentation, that this architecture would slow response
time in an emergency, and the Sensing Components should be
coupled directly to Braking and Steering in the Guidance &
Control component for fast response. Components should also
communicate via Integrated Processing for Diagnostics which
are included in the HCI component, see Fig. 5. Such decisions
are best made by a CCSE working with system, control, and
vehicle engineers as well as communication, computer and
sofware engineers.
Fig. 5. View of vehicle system architecture
Consider the views and viewpoints that were used in the
above decisions. Viewpoints include collision avoidance,
braking speed, impact on occupants, reliability,
maintainability, safety, diagnostics, component coupling and
cohesion, communication speed, the communication
algorithm, communication bandwidth, sofware, and
computing hardware. Views include information, fnctional,
behavioral, and structural requirements and design related to
each viewpoint. Redundant and inconsistent requirements
have to be merged, negotiated or eliminated. Design
inconsistencies have to be negotiated and made consistent and
affordable. The computing and communication system
requirements and design are critical in this application and the
CCSE adds value in negotiating and making decisions based
on his expertise in the feld, in modeling and simulation, and
because he speaks the domain engineering language as well as
the languages of the sofware, hardware, and communication
engineers.
VI. CCSE EMPLOYED ON FOLLOW-ON EARLY
WARNING SYSTEM (FEWS)
The author worked on a large complex system called
Follow-On Early Waring System (FEWS), formerly Boost
Surveillance Tracking System (BSTS). The Program
developed advanced sensor, computing, and tracking
technology in the late 80's and was terminated in the early 90's
due to duplication of main functions by FEWS and Brilliant
Eyes and the end of the cold war. The main engineering
solutions obtained in the course of the work were preserved in
subsequent projects including the Space-Based Infared
System (SBIRS). In 1995, the Air Force announced the new
SBIRS follow-on program [ 15].
The FEWS system included satellites and a ground system
and was in the demonstration / validation phase at the time the
author participated. The author's company was the prime
contractor and integrator. System engineers included an
overall system engineer, a communication system engineer
and a sofware system engineer. The highest level system
engineer worked with subcontractors including the ground
system and satellite contractors. The communication system
engineer was responsible for the space/ground communication
link, and together with the sofware system engineer was
responsible for tradeoffs as to what sofware would be in
space and what sofware would be executed on computers in
the ground station. The sofware systems engineer was
responsible for simulation of the tracking sofware. All three
levels of systems engineers worked together to demonstrate,
validate, and further defne the system concept.
The system engineers did not have the background
required to adequately discuss, negotiate, and simulate the
complex distributed computing and communication system.
The sofware engineers did not have the background to
understand whether the simulation was a reliable
representation of conditions in the real-world system and its
environment. For this, they needed the overall system engineer
and the communications system engineer. The CCSE(s) in this
case were a communication system engineer and a sofware
system engineer due to the complexity of the project. Working
together, they bridged understanding to ensure a reliable
system would be developed.
We need CCSE(s) on such large complex projects as it is
extremely difcult for one person to comprehend at a detailed
level the knowledge required of a systems engineer, a CCSE,
and a sofware systems engineer.
VII. THE FUTURE
As systems get more complex, the need for Model Driven
Engineering (MDE) will increase. Researchers at the
University of Texas, Austin, describe research in MDE as the
development of languages and tools to express complex
systems by describing their essential properties, ofen within a
restricted domain, while automating or providing automated
assistance to generate or synthesize an efcient
implementation of the system [ 16].
When made practical, MDE will allow the three types of
system level engineers to work at a higher level of abstraction.
The use of MDE will result in systems that meet their
requirements, and are more reliable, fexible, maintainable,
and cost effective. It will, as with other technologies, remove
the need for some personnel. The industry has been predicting
the need for fewer sofware programmers, but so far that has
not come to pass. When MDE languages and tools are
perfected, the need for programmers will fnally diminish. To
accomplish this, MDE environments would need the following
capabilities:

Incorporate Domain Specifc Modeling Languages
(DSMLs) and graphics so that engineers who are not
skilled in developing sofware can build models
using syntax and semantics familiar to their
discipline

Support concurrent teams of engineers and
integration of their models

Support modeling at various levels of abstraction
including system, hardware, and sofware, and
analyze downstream models for consistency and
correctness

Address the complexity of target platforms so that
sofware can be allocated and executed appropriately,
even in the complex situation where there is
distributed hardware with distributed control

Support integration with other languages and
platforms, as subcontractors and vendors may be
using a different MDE environment

Include transformations and generators that perform
model analysis and build simulations, code, test
cases, and alterate model representations

Include libraries of domain specifc models

Provide support for model description, maintenance,
and evolution

Provide support for model transformation to meet
specifc criteria such as high performance and precise
accuracy.
Modeling has been the basis for sofware and chip design
for many years, and more recently is the basis for system
architecture and design. This is design at a higher level than
sofware, where the system may encompass humans, sofware,
hardware, and communication. MDE is an active research
area. OMG's Model-Driven Architecture (MDA) promises
defnition of machine readable application and data models
that can be validated against requirements and provide long
term fexibility of implementation, integration, maintenance,
testing, and simulation [ 17]. At the system engineering level,
Vanderbilt's Model Integrated Computing (MIC) is an
example of MDE which "elevates the abstraction level of
sofware development and bridges the gap between
technology domains by allowing domain experts (who may
not be experts in sofware development) to design and build
systems" [ 18]. Vanderbilt's MIC has been used to develop a
large number of systems using a variety of DSMLs. Models
are built using the Generic Modeling Environment (GME),
"an open source, metaprogrammable, domain-specifc design
environment that developers use to create both DSMLs and
models that conform to these DSMLs" [ 18]. Using model
integration, developers integrate design and development
across disciplines.
Having an adequate MDE environment involves more than
just the environment. To achieve the goal of MDE,
goverment and academia must encourage and support the
development and use of DSMLs and model libraries, where
models are at various levels of abstraction. As with
development of sofware libraries, it is more expensive to
build a model for a library of engineering models, than an
engineering model for a specifc job. A library model and its
implementation must be well documented and extensively
tested, reliable, and extendible. It should be designed knowing
that it may be used in a manner that was not the intent, and the
implementation should inform users of errors.
How long will it take for us to see MDE environments with
DSMLs and model libraries in engineering frms? The
development and success of sofware "class libraries"
depended on the development of other technologies such as
dynamic linking and object oriented programming. The
earliest concept similar to class libraries was the separation of
data defmitions and program implementation developed for
the Air Force language JOVIAL in 1959 which allowed the
sharing of system data [ 19]. The concept of sofware libraries
was a hot research topic fom the time the author started in
industry in the late 70(s) until she lef industry in the late
90(s). Altogether it took at least 30 years for class libraries to
go fom a seminal idea of shared data to mainstream.
The earliest concept related to MDE was the development
of sofware analysis and design methods and tools including
Higher Order Sofware, the Army's IDEF language, and
Sofech's SADT. The latter was developed in the 1969 - 1973
time fame [20]. Today, the use of sofware modeling tools is
mainstream. What is stopping MDE fom becoming
mainstream? One factor is the complexity of MDE
environments. Another is the advanced technology required to
support the needed MDE capabilities as bulleted above. A
third is difculty of use, both in modeling and proper use of
the MDE environment. A fourth is the difculty in having
innovation adopted. Rogers in Diffsion of Innovations writes
"One reason why there is so much interest in the diffusion of
innovations is because getting a new idea adopted , even when
it has obvious advantages, is ofen very difcult" [21].
Funding agencies have tried to speed this practice by fnding
transfer of their previously funded research to industry. What
is needed is a well advertised success.
So how long will it take to see MDE environments in the
mainstream? Unfortunately, there are just too many variables
involved to provide an accurate guess. But one thing is certain
-it will happen!
VIII. REFERENCES
[1] J.W. Moore, "Converging Sofware and System Engineering Stadards,"
IEEE Computer, Sept. 2006.
[2] IEEE Computer Society Technical Commitee on the Engineering of
Computer Based Systems (TC-ECBS) website. Accessed Jan. 2014 at
htp://tab.computer.orglecbs
[3] E. W Dijkstra, "On the Role of Scientifc Thought," in Selected Writings
on Computing: A Personal Perspective, Springer-Verlag, 1982.
[4] D.L. Pam as, "Designing Sofware for Ease of Extension and Con
traction" IEEE Transactions On Sofware Engineering, IEEE, 1979.
[5] D.E. Perry and A.L. Wolf, "Foundations for the Study of Sofware
Architecture," Sofware Engineering Notes, Vo. 17, No. 4, ACM, 1992.
[6] 1. H. Jacobson, Object Oriented Sofware Engineering: A Use Case
Driven Approach, Addison-Wesley, 1992.
[7] P. Clements el aI. , Documenting Sofware Architectures, Views and
Beyond, Pearson Educators, Boston MA, 2003.
[8] M.W. Maier The A of Systems Architecting, 3rd edition, CRC Press,
2009.
[9] Object Management Group (OMG), OMG Systems Modeling Language
(OMG SysML) Version 1.3, June 2012.
[10] R. Hilliard, "Views and Viewpoints in Sofware Systems Architecture,"
Position paper for First Working IFIP Conference on Sofware
Architecture (WICSA), 1999.
[II] S.M. White, B.E. Melhart, and H.W. Lawson, "Engineering Computer
Based Systems-Meeting the Challenge", IEEE Computer, Nov. 2001.
[12] T. O'Neill et aI., "[EEE ECBS '99 TC Architecture Working Group
(AWG) Report," Proc. of IEEE In!'1. Conf on Engineering of Computer
Based Systems, IEEE Computer Society Press, 1999.
[13] D. Dalcher, M. Mannion, J.Z. Lavi, R. Gallant, B.E. Melhart, and R.
Gonzales, "Engineering of Computer-Based Systems - A Proposed
Curriculum for a Degree Program at Bachelor Level, Proc. of IEEE
Int'1. Conf on Engineering of Computer Based Systems, IEEE
Computer Society Press, 1998.
[14] S.M. White, et aI., "Systems Engineering of Computer-Based Systems",
IEEE Computer, Nov. 1993.
[IS] "Space-Based Early Warning: From MIDAS to DSP to SBIRS,"
National Security Archive Electronic Briefng Book No. 235, 1.T.
Richelson, Ed., Nov. 2007, posted Jan. 2013. Accessed Ja. 2014 at
htp://www2.gwu. edu/-nsarchivINSAEBBINSAEBB235/20130I08.htm
[16] Website for Model Driven Engineering, Computer Science Department,
University of Texas, Austin. Accessed Jan. 2014 at
htps://www.cs.utexas. edu/research/areas/model-driven-engineering
[17] 1. Miller and 1. Mukerji, MDA Guide Version 1.0.1, Object Management
Group (OMG), 2003.
[18] K. Balasubramanian, A. Gokhale, G. Karsai, 1. Sztipanovits, and S.
Neema, "Developing Applications Using Model-Driven Design
Environments," IEEE Computer, Feb. 2006.
[19] J.L. Schwartz, "The Development of Jovial," ACM SIGPLAN, Aug.
[978.
[20] D.T. Ross, "Structured Analysis (SA): A Language for Communicating
Ideas," IEEE Transactions on Sofware Engineering, Jan. [977.
[2[] E. M. Rogers, Difusion ofTnnovations, 3rd ed., The Free Press, 1983.