A todo esto ¿Qué es una arquitectura?

11 de Junio 2008

Juan Carlos Barroux R.
jbarroux@leconseil.cl
http://www.linkedin.com/in/juancarlosbarrouxr

Agenda
¿Qué es una arquitectura?
¿Qué no es una arquitectura?
¿Para qué necesito una arquitectura?
¿Cómo se hace una arquitectura?
¿Y los arquitectos entonces?
¿Cómo los reconozco?
¿Qué hace un[a] arquitect{o,a}?
¿Cómo se crea un[a] arquitecto{o,a}?
¿Hacia dónde vamos con la arquitectura?
Reflexiones arquitectónicas finales.

¿Qué
es
una
arquitectura?


Architecti est scientia pluribus disciplinis et variis
eruditionibus ornata, cuius iudicio probantur omnia
quae ab ceteris artibus perficiuntur opera.
Vitruvius
ca. 80 - ca. 20 a.


Los
invariantes
de un
sistema.


Distribución
en el tiempo y
en el espacio
de los
objetos.


“Architectures are
hollistic bridges,
but also
processes”

James Baty


Un proceso que
genera una visión
compartida de las
relaciones entre los
componentes de un
sistema.

¿Qué no es una arquitectura?

• Un dibujo
• Algo estático
• Una imposición
• Un secreto

¿Qué es un[a] arquitect{o,a}?

“Tous imbéciles.
Oublient toujours
l’escalier des
maisons”

Gustave Flaubert

¿Para qué necesito una
arquitectura?
¡Para controlar la
complejidad!

Los sistemas son
complejos y
dinámicos.

¿Cómo piensa un arquitecto?
• Se hace preguntas:
•¿Dónde se me va a romper?
•¿Dónde me van a penetrar?
•¿Dónde no va a escalar?
•¿Dónde me estoy amarrando?
•¿Dónde es demasiado complejo?
•¿Cómo lo administro?
•¿Cómo le agrego nuevas funciones?
•¿Qué se me olvidó?


➔
No piensa en “features”
➔
Piensa en términos de interrelaciones
entre subsistemas.
➔
A nadie le importa el clockage de una
CPU como a nadie le importa el diámetro
de un cilindro.


• Piensa como un traductor.
• Le traduce al cliente lo que le dice el
ingeniero calculista, el constructor civil, el
estucador, el pintor, el albañil, etc.


• Piensa en terminos “vendedores”

Architecture : The integration in a single seductive speech of
the 4 Ss (Systems, Software, Storage and Services) into a single
S, the Solution.

¿Cómo se hace una
arquitectura?
• Definir metas, objetivos e hipótesis
• Especificar las métricas
• Generar la descomposición funcional
• Dimensionar la carga de cada función
• Colapsar funciones en sistemas
• Validar escalabilidad
• Validar disponibilidad
• Validar seguridad
• Generar vista física primera instancia

¡Gracias!

http://www.leconseil.cl/ Versión 1.1

Introduction
to Systems Application
Architecture
by E. F. Wheeler
A. G. Ganek

Systems Application Architecture Is a framework in ready been published, and more will follow as SAA
which applications are developed that they run con-
so evolves and expands over time. The specifications
sistently on major ISM computing systems. This paper
presents the motivation and requirements for this are open and available to encourage customer and
framework and describesthe main elementsof its software-vendor participation in the development of
structure. It also discusses effect on current proc-
the applications that adhere to SAA. In addition, a fourth
essing technologies and on application development. key element of the SAA strategy is IBM’S own com-
mitment to provide Common Applications that will
executeacross the SAA system environments. As
customer, software-vendor,and IBM SAA applications
become available,the new dimension of consistency
among them will augment the end user’s access to
I n March 1987, IBM introduced Systems Applica-
tion Architecture (SAA), a significant new direction
for IBM software which provides the framework for
applications of all kinds.

the development of consistent applications across SAA is a key strategic direction for IBM, analogous to
the major IBM computing environments-Sys- the System/360 announcement in 1964 that intro-
tem/370, A S / ~ O Oand, Personal System/2@.
~~ This an- duced a family of hardware systems. SAA defines a
nouncement is not about a specific product, but family of software operating systems whose goal is
rather a pervasive software architecture that under- to meet the following customer needs:
lies the commitment to provide, in an evolutionary
way, cross-systems consistency across a broad spec- Increased programmer and end-user productivity
trum of hardware, architecture, and operating sys- Enhanced ease of use and support by providing
tems environments. It is a software-based approach consistency among applications
to present the breadth of IBM’S product line to its Improved communications capability and usabil-
customers as a family of software systems-a family ity for enterprise-widesolutions
that will provide enterprise-wide solutions to busi- Increased return on customers’ information sys-
ness computing problems. tems investment via greater leverageof program-
mer resourcesand user experience
SAA is composed of three significantelements-
Common User Access, Common Communications Copyright 1988 by International Business Machines Corporation.
Support, and Common Programming Interface- Copying in printedformforprivateuse is permittedwithout
that govern software interfaces, protocols, and con- payment of royalty provided that ( 1 ) each reproduction is done
ventionsfor human interaction with applications without alteration and the Journal reference and IBM copyright
(2)
and systemservices, communication mechanisms notice are included on the first page. The title and abstract, butno
other portions, of this paper may be copied or distributed royalty
that interconnect SAA systems, and programming freewithoutfurtherpermission by computer-basedandother
interfaces for program development. Many of the information-servicesystems.Permission to republish anyother
specifications that describe these elements have al- portion of this paper must be obtained from the Editor.

250 WHEELER AND GANEK I M SYSTEMS JOURNAL, VOL 27, NO 3, 1988
B

These needs are to be met by providing consistent, During the mid- to late 196Os, the function of oper-
durable interfaces in IBM software products. ating system software increased as newer technology,
such as larger memory, became more available and
This paper is intended to illuminate the concept of as the complexity of the hardware increased. These
SAA, demonstrate the motivations for this direction, developments spawned the widespreaduseof the
and explain its overall structure. Subsequent papers class of software we now call application enablers,
in this issue will enlarge upon selected aspects and including the high-level languages and a variety of
components of SAA and highlight the technical chal- other programming services. This software was a big
lenges, trade-offs, and solutions involved in the im- step forward, since applications developed in high-
plementation of this architecture. level languagesdid not have to deal directly withthe
details of the hardware. But most largeapplications
Background required additional, machine-specific support out-
side these languages and so were still directly de-
Perhaps the easiest way to understand howcross- pendent on the underlying hardware. The advances
systems consistency Systems Application Archi-
and in application enablers, combined with the enhance-
ment of operating system software to provide so-
phisticated “batch processing”for automated job
scheduling, print spooling, and other aspects of
sharedresource management, comprised the first
major stage in the evolution of operating system
Use of application enablers technology.
became widespread. By the 1970s, the use of display terminals to access
computing resources and data stored on line had
become common, and technology had also made
communication possible between systems. To sup-
port thesechanges,systemsoftwareincreased in
scope and provided interconnect facilities to tie sys-
tecture will meet customer requirements and remove tems together. This, in turn, gave customers the
constraints to their growth isto present an historical opportunity to bring key aspects of their businesses
perspective on the evolution of IBM software. on line and interconnect processors throughout their
businesses. Databaseand data communication prod-
In the mid-l950s, the programs that existedwere ucts were the leading technology advances of this
primarily application programs, executing the func- second stage operating system evolution. Together
of
tions for which acomputer was acquired. The hard- with interactive support for program development,
ware manufacturer provided the hardware, and the this stage made the capabilities of computer systems
customer, with the aid of rudimentary operating directly available to terminal operators. Computer
systems and assemblers, wrote the software. Since resource sharing now had an on-line, interactive
the application programs ran on the hardware di- interface that was extended to non-data-processing
rectly, they were tiedto the instruction set or “archi- professionals as well as to industry personnel.
tecture” of the hardware. By the late 1950s and early
1960s, hardware-oriented system software began to Today, technology has progressed the point where
to
emerge. This software, which was code could be
that the need for application-enabling software is recog-
shared by allcustomers, consisted primarily input-
of nized and provisionhasbeen made forit.Such
output routines. The routines operated card readers, enabling capabilityincludes management of data in
punches, printers, tape devices, and, toward the end relational form, application-generation products,
of this period, disk storage. In addition, high-level and display management, to name just a few. The
languages, notably FORTRAN and COBOL, were intro- result is that application programshavebecome
duced and offered the potential to ease greatly the largely insulated from the underlying software and
task of programming. The net effect was to improve hardware. With the use of this application-enabling
the productivity of application developers. But, for technology, the effort expendedin creating an appli-
the most part, the applications of this periodre- cation is, by and large, directed at solving the prob-
mained directly related to the specific hardware sys- lem, rather than fitting the solution to a particular
tem on which they were running. hardware architecture or operating system.

IBM SYSTEMS JOURNAL,
VOL 27, NO 3, 198B WHEELER AND GANEK 251

The structural changes just described occurred In contrast, because the application enablers for each
throughout IBM’S product line. In the mid-l970s, system have evolved independently and have been
each computer family and its operating system as a optimized for the system on which they run, appli-
pair, alongwith the associatedset of application cations that use the enablers have also become seg-
enablers, were optimized to a particular purpose, in mented by operating system. This condition limits
terms of criteria such as performance, capacity, and the utility and increases the complexity of intercon-
application environment (i.e., batch, interactive, or necting heterogeneous systems because dispar-
of the
transaction processing). Each was designedand built ity of the application environments across systems.
to be the best-of-breed for its intended goals. Collec- If the needs of an installation grow beyond the
tively, they allowed to move forwardto compete
IBM capacity of a particular system, this segmentation
across a broad range of markets by satisfying cus- makes it difficult to migrate up the product line. The
tomer requirements at each point in the range. This same barrier applies to the migration of applications
strategyproved to besuccessful and waswell-ac- that run on large systems when the need arises to
cepted in the marketplace. replicate them on smaller, departmental systems.
The result is that the IBM product line appears as a
By the early 1980s, the span of computing power number of independent systems, each one offering
from the smallest to largest machine in the IBM advantages withinits domain.
product line had grown drastically.To provide com-
petitive solutions across this increased range, several As we look forward to the end of this decade, hard-
new environments were added. Today, in all of the ware technologyis expected to continue to improve
major environments except the two smallest, per- at its historical rate of 20 to 25 percent per year.
sonal systems and the System/36, the power of the Clearly, it is IBM’S goal to continue to position the
hardware and the structure of the softwarehave product line to exploit fully this enormous range of
progressed to the point where application enablers computing capability. As a result of this growth, we
provide levels of function that are roughly equal and havearrived at a key point in the evolution of
that have, by and large, insulated the applications systems software,one that affords the opportunity to
from the hardware, although theyremain tied to the integrate key systems across the entire spectrum of
operating system on which they run. processor power.

In the case of the System/36, the structure of the Technology has progressed to the point where we
software has reachedthe same point of evolution as can provide a full-function system, Operating Sys-
the others, but the small size the system hasmeant
of tem/2’” (os/zTM) Extended Edition, on the current
that the depth of function has certain limitations. As line of intelligent workstations. This development
an example, a relational database management sys- will enable the graphicspower of the intelligent
tem is not available. In the IBM Personal Computer workstation to be combined on one system with the
Disk Operating System (PC DOS), neither the struc- full set of operating system functions such as data-
ture of the software nor the depth of function is base and communication facilities. The System/36
equivalent to what is found in the larger systems. and System/38 are replaced a new, unified system,
by
Applications on PC DOS are still largely tied to the the os/4ooTM operating system and ~ ~ 1 4 0 0
hardware,
hardware, and some advanced application enablers that has the capability to support from four worksta-
are either not available or limited in function. tions to more than four hundred, depending, of
course, on the workload and configuration. This
During the latter part of this evolution, the emer- system combines the ease of use of the System/36
gence of Systems Network Architecture (SNA) per- and the advanced software technology of the Sys-
mitted the interconnection of any combination of tem/38, together with state-of-the-art hardware for
these systems and communication with a variety of enhanced performance and capacity.
third-party equipment. SNA also brought the capa-
bility to more easilymanageextremelylarge net- These developments are undeniably important for
works of interconnected systems. The benefits of the small and intermediate computing environ-
interactive computing, coupled withthe connectivity ments. But it is equally important that, for the first
of these networks, provide significant capability for time, there will be a full set of application enablers
customers to bring together diverse aspects of their on all of our systems. By using the application ena-
businesses for access a single terminal anywhere
from blers to mask the underlying hardware operating
and
within the enterprise. system, the product line can be presented to cus-

252 WHEELER AND
GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988

tomers in a single coherent way from the smallest erating system environment on a personal computer
intelligent workstation the largest System/370 ma-
to today also offer a full realization of the potential of
chines asa single family. Application developers
can cooperativeprocessing. In cooperativeprocessing,
begin to develop common applications that run on intelligent workstations used in conjunction with
are
host systemsin an integrated way to provide the end
user with the advantages of both personal and host-
based computing. Cooperative processing allows the
user to have a single, seamless view of the function
of an application, whereas, in fact,the implementa-
SAA defines a consistent set tion is split between the workstation and the host.
This implementation model is of key importance to
of application enablers. SAA and will be addressed more depth later in this
in
article.

Requirements
To support a product line that spans an ever-increas-
each system ofthe family, rather than being limited ing capacity range, more than one hardware archi-
to a particular operating system or hardware architecture and operating system will be required. Ex-
tecture, thereby minimizing the effort required to actly how many are required and what part of the
build such applications and to migrate users from range each can span may change over time as tech-
one system to another. nology changes. Built on each of thesearchitectures
and operating systems willbe a set of application
To make this happen, SAA defines a consistent setof enablers matched to its system. When one considers
application enablers that span the systems and min- the IBM product line, the broadest in the industry,
imize the historical differences, making these appli- ranging from the IBM PC to the 3090 (which repre-
cation enablers the unifying force for future.
the sents a factor of about 1000 in performance), it is
evident that multiple hardware architectures and
The establishment of consistent application enablers operating systems are necessary. They are necessary
across a family ofoperating systemsgoes wellbeyond today to allow customers to exploit this wide range
the goal of portability of applications from one en- of capacity, and they will continue to be needed to
vironment to another. When this consistency is com- exploit the expanded capacity of the future-capac-
bined witha rich setof communications capabilities ity driven by technology improvements that, as in-
and protocols for the interchange of data and for dicatedearlier, continue at rates in excess of 20
process synchronization, the family-of-operating- percent per year. Hardware architectures and oper-
systems concept extends to a global environment in ating systems have natural limits, both upward and
which interconnected systems concurrently partici- downward, and when forcedto operate beyond those
pate in addressing the needs of the enterprise. The limits, do so either poorly or with difficulty.
result is called an Enterprise Information System,
which represents the third major stage of operating In IBM, the multiple hardware architectures and op-
system evolution. Such an environment is a distrib- erating systems are well-positioned take advantage
to
uted system, and the programming functions that of the progress of technology. We face a different
enable it are referred to as distributed services. The problem: how to present that technology in a con-
implication of such a capability is that any system sistent way. Consistency acrossthe product line can
in the family can interact with any other system by be achievedby making the interfaces of the software
using the range of distributed services. Distributed consistentacrosshowever many implementations
applications are thosewritten to exploit multiple are required to span the range. This mechanism
system configurationsto satisfy a variety of require- works because software technology is now advanced
ments, including specializedprocessingneeds and enough to have the interfaces for application ena-
those motivated by geography,security,capacity, bling independent of the hardware,even on the
availability, and organizational considerations. smallest and largest systems.
Within this context, the technological advances in
power and improvements in price/performance of The guidance necessary for defining an architecture
personal computers that enable a full-function op- that meets the challenge of consistency across the

IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988 WHEELER AND GANEK 253

I Figure 1 General software structure

254 WHEELER AND GANEK BM SYSTEMS JOURNAL, VOL 27. NO 3. 1988

product line can be obtained by identifying the key facturing automation, health-care systems, thou-
and
requirements for productive useof heterogeneous sands of others that deliver the solutions to problems
data processing systems.Numerous IBM studies, cus- for which computers are used.
tomer advisory councils, and user group meetings,
as well as discussions with software vendors, have This software model, which began as an organiza-
repeatedly determined three leading requirements in tional tool for high-end systems, has been mapped
this area: against each of IBM’S major operating systems: Mul-
tiple Virtual Storage (MVS), Virtual Machine/System
Usability-the need for applications to be easier Product (VM/SP), os/400, and os/2 Extended Edition,
and simpler to use and to learn and found to be generally applicable. The host sys-
Productivity-the need for a straightforward and tem environments of MVS, VM, os/400support all
and
productive way to develop applications that op- of the key functions of the model, although in many
erate across a variety of operating systems and cases with different interfaces.os12 supports most of
thereby ensure a wider range of usefulness, ob- these functions; however,some either are not yet
viating the necessity of rewriting applications to supported at this time or are not applicable, such as
meet the demands of different environments Job Entry or Data Center Systems Management.
Connectivity-the ability to connect systems and Despite these omissions, the model still applies to
peripheral equipment in an easy and consistent os/2 Extended Edition, since the majority of func-
way, supported with the tools necessary to manage tions are present, and the components it does have
the interconnected environment simply and effi- can be structured according to the blue-, green-,and
ciently yellow-layerapproach. The model not only simplifies
the classification of products within the various sys-
Structure tems, but provides a basisfordefining common
elements across these operating systems to yield a
Systems Application Architecture provides consis- common set of interfaces for application programs.
tency across dissimilar operating systems. The cor- The idea of cross-systems consistency was developed
nerstone of the definition of such an architecture is from this concept of a common framework giving
a conceptual model that describes softwarestructure rise to common interfaces.
in a generic way and provides a coherent organiza-
tion of function. This model,shown in Figure 1, SAA uses the generic software structure model as a
consists of four layers, each of which representsset
a basic building block address the three key require-
to
or category of related functions. This structure pro- ments for cross-systems consistency. It does this by
vides a foundation for understanding the strategic controlling three new specificationsthat relate to the
elements of IBM software and how they fit together. requirements for consistency on a one-to-one basis
The blue, or bottom, layer in the figure is software
the and also by building directlyon the system structure
uniquely related to the hardware. This software is model, as shown in Figure 2. As can be seen in the
geared to manage and exploit the capabilities of the figure, the SAA components surround the software
specifichardware and architecture forwhich it is structure in such a way as to provide consistent user,
designed. Included in this layer are functions that programming, and communications access to the
manage physical system resources such as memory, operating systems functions of each system-Mvs,
disk storage, printers, and processor dispatching.
The VM/SP, ospoo, and os12 Extended Edition.
yellowlayerrepresents communications software,
which provides the connectivity to allow communi- SAA is controlled by the specifications ofthe follow-
cation among systems and applications and the abil- ing three elements: Common User Access,Common
ity to manage the interconnection of systems. This Communications Support, and Common Program-
software entails communication protocols and net- ming Interface. They are discussed below.
work management. The green layer represents the
products directly related to writing and executing Common User Access. The first component governs
applications, also called the application-enabling the end-user interface and is called Common User
products. Included in this category are services such Access (CUA). This interface controls how the system,
as database, query and report writing, and transac- including the applications, interacts with a person at
tion management, along with languages such FOR-
as a workstation or terminal. It is this interface that
TRAN and COBOL. At the top, the red layer represents ensures that the way things look to the user and the
application software such as office systems, manu- actions required of the person by the system are

IBM SYSTEMSJOURNAL, VOL 27, NO 3, 1988 WHEELER AND GANEK 255

Figure 2 model
Consistent interfaces built on system structure

PROGRAMMERS

MVS

VMlSP

END USERS

o1
s2

256 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988

familiar no matter whattasksareperformed. By
providing a well-designed end-user interface for ap-
plication programs, applications are made easier to portions of SNA and international standards.
learn and easier to use. By making the end-user
interface consistent across applications and across Included in ccs are the following facilities:
systems, skill acquired with one application or on
one system is usually transferable to other systems Data streams-Data streams govern the way in
and applications. CUA provides the window through which data are handled and formatted whentrans-
which the user views and accesses applications.The mittedovera communications link.They are
enhanced ease of use the consistency it provides
and provided in SAA for support of display devices,
will augment the number of applicationsreadily document text, and printers.
available to theuser. Application services-These services relate to
services that enhance the function of the network.
CUA is defined for the interaction between humans Examples includedistribution services that enable
and computers. In dealing with how the machine asynchronous distribution of data throughout the
communicates withpeople, it addresseswhat the network, protocols that define common office
computer presents to the workstation operator, in- functions such as document interchange, and net-
cluding screen layout, of color and highlighting,
use work management.
messages, and help information. Also important to Sessionservices-Theseservicesreflect the SNA
CUA is how the user communicateswith the machine, Logical Unit (LU) Type 6.2 Advanced Program-
which involves the keyboard layout and usage, the to-Program Communications protocol, which de-
use of a mouse, scrolling, selection mechanisms.
and fines a rich set of communications services along
CUA is intended to provide a consistent and highly with a consistent programming interface on each
usable framework forthe dialog betweenthe person of the SAA systems.
and the machine that will result in continuity among Network-Thenetworkfacilityapplies to Low
different applications and across the four SAA sys- Entry Networking Nodes (Type Nodes), which
2.1
tems. The guidelines and rules are developed to support peer-to-peer communication across nodes
enhance ease of use,and the continuity achieved by in the network.
pervasive application of these conventions will en- Data link controls-These controls provide link
hance ease of learning. CUA is designed to take full usage and management disciplines such as Syn-
advantage of the capabilities of the intelligent work- chronous Data Link Control (SDLC) for teleproc-
station, which has the greatest capacity for a highly essing links, Token-Ring for local area networks,
interactive user interface. Dependent workstations and x.25 for packet-switched networks.
are also supported in the specification; however,the
limitations of this technology will restrictthe use of The subject of Common Communications Support
some of the dynamic features available intelligent
on is explored in detail in the paper by Ahuja in this
of
workstations.CUA allows a framework consistency issue.’
to exist between these different kinds of workstations,
while still encouraging full utilization of
the potential Common Programming Interface.The third element
of the intelligent workstation. with which cross-systems consistency is concerned is
application enabling, addressed SAA by the Com-
in
Common User Access is discussed in greater depth mon Programming Interface(CPI). It specifies how a
in the paper in this issue by Berry.’ programmer is write and attach a new application
to
to IBM’Sfamily of SAA systems. The application writer
Common Communications Support. The second SAA uses this interface exploit the power ofthe system.
to
element controls the interconnect protocols and is Having such an interface allows applications to be
called Common Communications Support (ccs). independent of the underlying system therefore,
and,
This interface deals with how systems work together to run on any system of the IBM SAA family, maxi-
to accomplish a job. For example, it controls how mizing the return on investment in application code.
systems communicate with one another to store, It is also valuable because an application program-
retrieve, and move information through the com- mer can apply skill using theCPI across the whole
at
munications network. With consistent interconnect IBM SAA family-not just asinglesystem-vastly
implementations provided by ccs, customerscan increasing productivity.This component of SAA de-
build networks of systems with vastly differing ca- fines a set of application building blocks consisting

IBM SYSTEMS JOURNAL,
VOL 27, NO 3, 1988 WHEELER AND GANEK 257

of languages and programming services for applica- face for Communications (CI) provides a consistent,
tion programmers. It already contains a rich set of high-level programming interface for the LU Type
published interfaces that will expand over time to 6.2 protocol for program-to-program communica-
include an even broader spectrum of interfaces for tion.
application enabling.
The role played by the Common Programming In-
The CPI language set provides consistentimplemen- terface in SAA is elaborated upon in the paper by
tations of the most widely used languages that are Wolford in this issue.3
applicableacross the SAA system spectrum. The
Cooperative processing
As indicated earlier, the advance of technology has
now permitted the cooperative processing modelto
be employed cost-effectively for a wide variety of
applications. Use of this model has many benefits
Cooperative processing can now and is a key aspect of the SAA direction. The use of
an intelligent workstation as an integral part of an
be employed cost-eff ectively. application makes it possible to provide the appli-
cation user with the most advanced and usable hu-
man-to-machine interaction available in informa-
tion systemstechnology. This capability includes
advancedscreen-display techniques and windows,
keystroke-initiated processing interactions, and high-
performance use of graphics. By using these capabil-
scope of the languagesetencompasseshigh-level ities in conjunction with host-system services, the
languages, procedures languages, application gener- application can afford to offer the useraccess to
ators, and expert systems. The number of products shared files, databases, transaction services, special-
in this category is increasing as SAA requirements
the ized computing functions, and peripheral equipment
broaden. Included at this time are the COBOL, C, such as printers and plotters. Because the user per-
FORTRAN, and RPG high-level programming lan- spective of the workstation/host interaction is made
guages; the REXX procedures language; the Cross
and transparent, the image of asingle application is
System Product (CSP) application generator. Al- preserved, as depicted in Figure 3. Advanced com-
though not supported at this time, expert systems munication support, the Common Programming In-
technology is planned for inclusion in SAA in the terfacefor Communications, and multitasking in
future. 0s/2 Extended Edition allow workstation users to
concurrently utilize local applications that are writ-
The services of the CPI provide key enablers for the ten for the personal computer and cooperative ap-
development of portable and integrated applications. plications that exploit host-system services a con-
in
Central to the SAA direction is the relational database sistent way, with easy transitions from application
accessed via the Structured Query Language (SQL) to application.
standard database language. Complementary to the
relational database is the QueryInterface that is Distributed processing
usable by end users and programs to access relational
data. The DialogInterfaceprovidesahigh-level, Aswe have seen, cooperative processing makes it
programmable capability for defining displaying
and possible to present an integrated and seamless view
terminal screens that conform to the Common User of intelligent workstation and host-system capabili-
Access specification. Mechanisms are provided that ties.AdvancedProgram-to-Program Communica-
control the relationship betweenvariables in the tion (APPC) capabilities, as defined by the SNA L 6.2
u
program and fields and selections as portrayed on protocol and accessed via CI, provide aconsistent
the
the screen.Navigation among multiple panelsis way to interconnect all of the SAA systems. This
supported. The Presentation Interface enablesa interconnection allows application function to be
lower-level control of screens and printers for text split acrossintelligent nodes in the network in a
and graphic format display as well as multiple-win- general way, providing for the distribution of func-
dow support; it is used in the implementation of the tion across multiple host systems well as intelligent
as
Dialog Interface.The Common Programming Inter- workstations. Consistent implementations of CI per-

258 WHEELER AND GANEK IBM SYSTEMS JOURNAL.
VOL 27. NO 3, 1988

Figure 3 Cooperativeprocessing

HOST SYSTEMS

IBM SYSTEMS JOURNAL, VOL 27. NO 3, 1983 WHEELER AND GANEK 259

mit distributed application functions to be written an application program; it is the entire life cycle from
independently of the system on whichtheywill conception and definition of the requirements to
execute, allowing function to be distributed accord- production usage and ongoing maintenance. Major
ing to the requirements of an enterprise and redis- improvements in productivity necessitate not only
tributed asnecessary those
when requirements enhancements to each phaseof the process, but also
change to accommodate growth, reorganization,and a more comprehensive approach to the problem as
consolidation. a whole. This approach in SAA will emphasize an
integrated family of tools which providean applica-
Built on the APPC base and the additional capabilities tion development environment to share program-
of the Distributed Data Management (DDM) archi- ming objects throughout the life cycle.A key element
tecture, generalized distribution of data throughout in such an approach is a common data repository
a networkof heterogeneous systems be achieved.
can affordingadvanced features for storing and retrieving
Distributed data means that files and databases can such objects, for describing their attributes, and for
be dispersed throughout the network, yet are acces- defining relationships among them. These capabili-
sible by any program as if located on the local system. ties would allow information related to an applica-
The remote location of the data is thus transparent tion to be created once and be shared throughout
to the application program. The application program the product life cycle.
invokes the same interfacefor SQL or high-level
language record I/O operation regardless ofthe loca- The application development environment is an ex-
tion of the data, and the appropriate communica- cellent candidate for utilizing cooperative processing
tions processing is implicitly generated the case of
in to achieve the best possible ease of use toexploit
and
remote data. The communications processing takes the value of local processing powerin an intelligent
advantage of the ccs data formats, session protocols, workstationwhereverapplicable. Host facilities
network management, and data link control facili- would be likewise used where appropriate, such as
ties. for the data repository.

Distributed relational data and distributed files are
discussed in more depth in this issue in the papers Common applications
by Reinsch4and Demers.’ The manifestation of the SAA concept is the set of
Application development applications that exploit its principles to achieve its
objectives. The characteristics of these applications,
The value of applications that comply with SAA is called Common Applications, are directly derived
enhanced because those applications from the principles of cross-systems consistency that
we have explored in this paper. Such applications
Are easier to learn and use as a result of the CUA execute on all the SAA operating systems, providing
Execute in a broader range of processingenviron- consistent function across a vast range computing
of
ments as enabledby the CPI power. They adhere to the CUA specification to in-
Interconnect that range of systems as needed via teract with people in a highly usable and consistent
the ccs way. Similarly, where applicable, they utilize ccs
the
Utilize advanced technologies such as relational to effect interactions from system to system. They
data and cooperative and distributed processing are also based on the CPI, which enables consistent
function and implementation. Foremost design con-
Attainment of these benefits depends on the creation siderations are integration and extensibility across
of applications that take advantage of these features. the breadth of the enterprise they serve. Cooperative
A critical aspect of the strategy to support SAA is to processing is emphasized wherever applicable en-to
provide a set of tools that will greatly improve pro- hance the function, usability, and integration of the
ductivity in the development process for such appli- application.
cations.
IBM is committed to deliver many such Common
The program development process normally consists Applicationstargeted to support specific industry
of a sequenceof stages,including requirements gath- requirements as well as cross-industryneeds. An
ering, analysis design, code
and development, system example of the latter is Office and Decision Support,
integration and test, and maintenance. This se- which is analyzed in a case study in this issue by
quence reflects more than just the construction of Dunfee et a L 6

260 WHEELER AND GANEK I M SYSTEMS X)(JRNAL. VOL 27, NO 3. 1988
B

The objectives and value of Common Applications Flexible connectivity of heterogeneous systems as
are as suitable for IBM’S customers and independent provided by ccs to allow the concurrent use ofthe
software vendors as they are for IBM. The emphasis variety of computing capabilities inthe enterprise
in an integrated and complementary way
Consistent programming interfaces as provided by
the CPI to allow application development to be
independent of the system selection, programsto
be portable from system to system, and program-
As SAA evolves, the support of the ming skill expanded to be applicable across the
systems in the enterprise
Enterprise Information System will
continue to expand. The Enterprise Information System support will be
further enhanced by the advances in distributed
processing that will facilitate transparency of location
for data and function across the enterprise. This
capability will help mask the complexity of the in-
terconnected environment and will permit applica-
on an open, published set of interfaces, protocols, tion programmers to focus more on the problem to
and conventions is designed to encourage customer be solved. Continued emphasis on network and sys-
and vendor participation. tem management tools as well as consistent security
mechanisms across the scope of the Enterprise In-
formation System will be required to minimize the
Enterprise Information System effort to support and control the diverse systems in
Cooperativeprocessing,advanced communication the enterprise.
facilities, distributed data, and Common Applica- Conclusion
tions permit an end user, through the window of the
intelligent workstation, to access all of the capabili- In summary, Systems Application Architecture de-
ties available in the network to which that worksta- fines I B M S solution to achieve cross-systems consis-
tion is attached. Notonlyarediversecapabilities tency. It provides an architectural framework for a
accessible, but the complexity of the interconnec- familyof operating systems that spans the three
tions is not apparent. This environment, concep- orders of magnitude in the range of power of com-
tually depicted in Figure 4, i; the Enterprise Infor- puting hardware now offered in IBM’S product line.
mation System, a central theme in SAA. The objective SAA achieves the framework via an extensive set of
is to provide enterprise-wide solutions to business published protocols, interfaces, conventions that
and
problems by extending the scope of applications to give rise to Common Applications, which are port-
span multiple systems, from workstations to mid- ableacrossdiverse environments; this setmakes
range systems mainframes, that may be geograph-
to possible the interconnection and integration of these
ically dispersed. This objective allows an enterprise environments. SAA provides a consistent, state-of-
to install and configure information processing sys- the-art userinterface to achieve the bestpossible
tems according to the needs of the business, includ- usability.
ing organizational,geographic, and historical factors,
while still achieving the integration so vital to pro- SAA is evolving,continually encompassing a broader
ductivity and effectiveness. scopeover time in order to keeppacewith the
advances of technology in both hardware and soft-
As SAA evolves, the support of the Enterprise Infor- ware. Its goal, however, remains the same-to pro-
mation System will continue to expand. The key to vide the base of usability, consistency, and connec-
the success of this direction is the cross-systems tivityrequired to makeuse of programming re-
consistency foundation: sources and user experience most effectively, thereby
increasing productivity and protecting software in-
Consistent userinterface as defined by CUA to vestment. SAA brings a comprehensive unificationto
allow consistent human interaction with infor- IBM’S family of systems, providing access an enor-
to
mation processing facilities across entire scope
the mous spectrum of processing power via architec-
an
of the enterprise, enhancing ease of use knowl-
and ture that is available now and is the base for expan-
edge transfer sion in the future.

IEM SYSTEMS JOURNAL,
VOL 27, NO 3. 1988 WHEELER AND GANEK 261

Figure 4 Enterprise Information System

MID-RANGE LARGE

262 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988

Personal System/2 is a registered trademark, and AS/400, Oper- ESA/370. In June 1983, Mr. Ganek was named development
ating System/2, OS/2, and OS/400 are trademarks, of Interna- manager of the MVS System DesignDepartment, involving work
tional Business Machines Corporation. on a variety of advanced technology activities. In 1985, he was
appointed manager of MVS Design and Performance Analysis,
where he was responsible for technical plan and content of the
the
Cited references MVSbase control program future releases and, in1986, was
promoted to program manager.Later that year, Mr.Ganek joined
1. R. E. Berry, “Common User Access-A consistent and usable the Information Systems and Storage Group staff as a technical
human-computer interface for the SAA environments,” IBM assistant. In 1987, he went to the Corporate Programming Staff,
Systems Journal 27, No. 3, 281-300 (1988, this issue). where he contributed to a number of efforts concerning IBM’s
2. V. Ahuja, “Common Communications Support in Systems programming strategy and Systems Application Architecture. He
Application Architecture,” IBM Systems Journal 27, No. 3, began his current assignment in June 1988 and is responsible for
264-280 (1988, this issue). VM/XA Advanced Systems direction, design, planning, and prod-
3. D. E. Wolford, “Application enabling in SAA,” IBM Systems uct introduction support.
Journal27, No. 3, 301-305 (1988, this issue).
4.R. Reinsch, “Distributed database for SAA,” IBM Systems
Journal 27, No. 3, 362-369 (1988, this issue).
5. R. A. Demers, “Distributed files forSAA,” IBM Systems Reprint Order No. G321-5323.
Journal 27, No. 3, 348-361 (1988, this issue).
6. W. P. Dunfee, J. D. McGehe, R. C. Rauf, and K. 0. Shipp,
“Designing SAA applications and user interfaces,” IBM Sys-
tems Journal 27, No. 3, 325-347 (1988, this issue).

Earl F. Wheeler IBM United States, 2000 Purchase Street, Pur-
chase, New York 10577. Mr. Wheeler is IBM Vice President and
General Manager, Programming Systems. He joined IBM as a
junior engineer in 1957 in Endicott, New York. Throughout his
career, he has played a significant role the development of IBM’s
in
products. During the late 1960s, he was responsible the systems
for
management of intermediate processors suchas the Model 40and
Model 50 of the IBM System/360 and the emerging System/370
Model155. During his assignment as Laboratory Director in
Kingston, New York,in the early1970s,he directed the early
formulation of Systems NetworkArchitecture. As Systems Devel-
opment Division Vice President of Industry Systems, and Vice
President, Communications Systems Division, in the mid-I970s,
Mr. Wheeler directed product management for all of IBM’s com-
munication products, including the 3270 displays, 370X multi-
plexors, and industry terminals. During this period, he was instru-
mental in managing the convergence of the IBM communications
product line to support SNA. As Assistant Group Executive,
Systems Development, Information Systems and Technology
Group, in the early1980s,hewasresponsible for the product
strategy for all System/370 systems software. Mr. Wheeler came
to Corporate Headquarters as IBM Director of Programming in
1984 and was elected IBM Vice President, Programming, in 1985.
In his current position, he is responsible directing the worldwide
for
development of IBM’s application-enabling software product of-
ferings and is the chief architect of SystemsApplication Architec-
ture.

Alan G. Ganek IBM Data Systems Division, P.O. Box 100,
Kingston, New York 12401. Mr. Ganek is manager of VM/XA
Advanced Systems. received hisMS. in computer science from
He
Rutgers University in 1981. He joined IBM as an associate pro-
grammer in 1978 in Poughkeepsie, New York. Hisfirstassign-
ments involved the implementation of the MVS operating system
software support for the cross-memory and 370/XA architectures.
In 1981 he joined the MVS System Structure Technology depart-
ment, wherehe contributed to the definition of the Enterprise
System Architecture/370 leading to a first patent award. He later
became team leaderfor the MVSsoftware support design for

IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988 WHEELER AND GANEK 263

IEEE Std 1471 and Beyond∗
Rich Hilliard
ConsentCache, Inc.
rh@ConsentCache.com
January 1, 2001

Overview It achieves this by being based upon a conceptual
framework for architectural description (see figure 1).
I describe the key contributions of IEEE Std 1471 to the The breadth of this framework is worth appreciating
discipline of software architecture representation. After relative to current work in architectural research and
reviewing the contributions of IEEE 1471, I discuss how practice. To my mind, much of this work has focused on
we (the community interested in Software Architecture) what are portrayed as Models in the conceptual frame-
may build upon the foundation provided by IEEE 1471 work, including architecture description languages, and
to continue to improve and disseminate techniques for related tools. While important, much of this work lacks
architectural description. a larger context needed in most practical, industrial-
(Although three pages is insufficient to give a strength applications. By reifying notions like Stake-
useful example of an IEEE 1471-conformant archi- holders and Concerns, the IEEE 1471 framework sug-
tectural description, there are a number of ap- gests a basis for dealing with these wider issues in a
plications of IEEE 1471 in the literature. Visit theory of architectural description.
the IEEE Architecture Working Group web site
(http://www.pithecanthropus.com/ãwg) for links.)
Content Requirements on ADs
The content requirements of IEEE 1471 are stated in
IEEE Std 1471 ... the terminology of the conceptual framework. These
requirements define what it means for an architectural
IEEE Std 1471–2000 is IEEE’s Recommended Practice description (AD) to conform to the Standard. The prin-
for Architectural Description of Software-Intensive Sys- ciples underlying these requirements are briefly summa-
tems [7]. To my knowledge, this is the first formal rized here.
standard to address what is an architectural descrip- ADs are interest-relative: The audiences for an AD
tion (AD). It was developed by the IEEE Architec- are the various stakeholders of the system, each with
ture Working Group with representation from industry, specific concerns (such as security, performance, or con-
other standards bodies and academe, and was subject structability) for the architecture. An AD should be
to intensive reviews by over 150 international reviewers, explicit in addressing these stakeholders. Therefore, an
before its publication this past Fall. AD must explicitly identify the system’s stakeholders
IEEE 1471 establishes a set of content requirements and their concerns for the system.
on an architectural description (AD) – a collection of Concerns form the basis for completeness: An
products to document an architecture. As such, the AD must addresses all stakeholders’ concerns. If it does
Standard plants a stake on how ADs should be orga- not, it is by definition, incomplete.
nized, and their information content, while: (i) ab- Multiple views: An AD is organized into one or more
stracting away from specific media (text, HTML, XML); views. Each view is a representation of the entire sys-
(ii) being method-neutral (it is being used with a vari- tem of interest intended to address a particular set of
ety of existing and new architectural methods and tech- stakeholder concerns.
niques); and (iii) being notation-independent, recogniz-
Although the use of views is hardly new with
ing that many diverse notations are needed for recording
IEEE 1471, its contribution is to motivate the use of
various aspects of architectures.
views (the source of much hand-waving in the Software
∗ Position paper for SEI’s First Architecture Representation Architecture literature) with respect to addressing spe-
Workshop, 16–17 January 2001. cific concerns of specific stakeholders.

1

Figure 1: IEEE 1471 Conceptual Framework

Views are modular: A view may consist of one or fied stakeholder concern must be addressed by one of
more architectural models. the selected viewpoints.
To satisfy the concerns to be addressed by a partic- Viewpoints are first-class: Each viewpoint used in
ular view, multiple notations may be used. This is one an AD is “declared” before use (either “in line” or
of the several places where IEEE 1471 is “parameter- by reference). A viewpoint declaration establishes the
ized” to accommodate the wide range of best practices stakeholders addressed by the viewpoint; the stake-
in Software Architecture modeling. holder concerns to be addressed by the viewpoint; the
Inter-view consistency: An AD must document any viewpoint language, modeling techniques, or analytical
known inconsistencies among the views it contains. methods used therein; and the source, if any, of the
This is a fairly weak requirement – based on current viewpoint (“prior art”). A viewpoint may also include:
consensus; I imagine as a community we can do much any consistency or completeness checks associated with
better in the future (see below). the underlying method to be applied to models within
the view; any evaluation or analysis techniques to be
Views are well-formed: Each view has an underlying
applied to models within the view; and any heuristics,
viewpoint identifying a set of architectural concerns and
patterns, or other guidelines which aid in the synthesis
specifying how the architectural description meets those
of an associated view or its models.
concerns, using languages and notations, models, ana-
This principle is perhaps the primary contribution of
lytical techniques and methods. A viewpoint is a set of
IEEE 1471 – to provide a means by which the many
conventions for constructing, interpreting and analyzing
architectual techniques in use today may be uniformly
a view.
described so that they may be used by others, compared
This is another “parameter” in IEEE 1471. Orga- and combined.
nizations may define and select their own set of useful
viewpoints. In fact, IEEE 1471 does not even specify
a fixed set of viewpoints; the Standard is “agnostic” ... And Beyond
about where viewpoints come from. Instead, the fol-
lowing principle is employed: In addition to codifying best current practices in archi-
Concerns drive viewpoint selection: Each identi- tectural description, a goal of the IEEE for the develop-

2

ment of IEEE 1471 was to provide a foundation for the Formalization. The conceptual framework of
continuing evolution of the discipline of Software Archi- IEEE 1471 is an informal, qualitative model. If it
tecture. To conclude this position paper, I briefly note is useful, which appears to be the case, it may be
a few opportunities of this kind. insightful to attempt to formalize the concepts therein.
Such a formalization could have benefits in several
of the topics just mentioned: viewpoint reuse, view
Reuse. Viewpoints, being system-independent, are
checking, view integration, and inter-view analysis.
highly reusable. The viewpoint construct is intended
Finally, there are another set of advanced topics in
to facilitate capture of one important kind of architec-
architectural description barely addressed by today lan-
tural knowledge: when to apply given representational
guages and tools. See [6] for discussion.
mechanisms to address particular stakeholder concerns
[5]. However, very little of present architectural knowl-
edge is captured in this fashion. For example, there is References
much work in the academic literature on modeling archi-
tectures via components, ports, connectors, roles, and [1] Alexander Egyed and Rich Hilliard. Architectural
their configurations which might be termed a “Struc- integration and evolution in a model world. In
tural Viewpoint.” By having a clear viewpoint declara- Bob Balzer and Henk Obbink, editors, Proceedings
tion, it would be easier to apply this knowledge more Fourth International Software Architecture Work-
uniformly. One useful role for organizations like SEI shop (ISAW-4), 4 and 5 June 2000, Limerick, Ire-
would be to serve as a repository for reusable view- land, pages 37–40, 2000.
points.
[2] Rich Hilliard. Using the UML for architectural de-
scription. In Robert France and Bernhard Rumpe,
View Checking. IEEE 1471 is essentially silent on editors, UML ’99 The Unified Modeling Lan-
the issue of checking or analysis of individual views, guage, Second International Conference, volume
except to say that a view must be well-formed with 1723 of Lecture Notes in Computer Science, pages
respect to its viewpoint – delegating the checking to 32–48. Springer, 1999.
any technique associated with the viewpoint.
Viewpoints will vary in their rigor, associated ana- [3] Rich Hilliard. Views and viewpoints in software sys-
lytic techniques, etc., which may be brought to bear on tems architecture. Position paper from the First
checking a view. By having uniform declarations it may Working IFIP Conference on Software Architecture,
be possible to “lift” techniques developed for one nota- San Antonio, 1999.
tion to use with others. See [2] for a discussion of this [4] Rich Hilliard. Views as modules. In Bob Balzer
in the context of use of the various notations of UML. and Henk Obbink, editors, Proceedings Fourth Inter-
national Software Architecture Workshop (ISAW-4),
View Integration and Inter-view Consistency. 4 and 5 June 2000, Limerick, Ireland, pages 7–10,
It has been long recognized that introducing multiple 2000.
views into architectural descriptions leads to an inte- [5] Rich Hilliard. Three models for the description of ar-
gration problem – how does one keep views consistent, chitectural knowledge: Viewpoints, styles, and pat-
non-overlapping? terns. Submission to WICSA-2, January 2001.
Complex specifications require structure, such [6] Rich Hilliard and Timothy B. Rice. Expressiveness
as different segments for different concerns. in architecture description languages. In Jeff N.
However, different concerns also lead to dif- Magee and Dewayne E. Perry, editors, Proceedings
ferent notations. ... [T]his leads to a multiple- of the 3rd International Software Architecture Work-
view problem: different specifications describe shop, pages 65–68. ACM Press, 1998. 1 and 2
different, but overlapping issues. [8] [my em- November 1998, Orlando FL.
phasis]
[7] IEEE. Recommended Practice for Architectural De-
The introduction of viewpoint declarations, while not scription of Software-Intensive Systems, October
solving the problem, gives us a tool for detecting over- 2000.
laps and inconsistencies, and potentially a substrate for [8] Mary Shaw and David Garlan. Software Architec-
solving the integration problem. See [3], [4], [1] for three ture: Perspectives on an emerging discipline. Pren-
different suggestions for tackling the view integration tice Hall, 1996.
problem.

3

Architecture = Abstractions over Software

Eyðun Eli Jacobsen Bent Bruun Kristensen Palle Nowack
The Maersk Mc-Kinney Moller Institute for Production Technology
University of Southern Denmark/Odense University, DK-5230 Odense M, Denmark
e-mail: {jacobsen, bbkristensen, nowack}@mip.ou.dk

Abstract

Design of software architecture is seen as abstraction over the software domain, and describing architecture
is considered to be a modeling process. A general view of a modeling process is presented and illustrated
in the context of application domain modeling and of software domain modeling. The implications of this
perspective are investigated in order to capture objectives and concrete forms of architectural descriptions.
The consequences of this perspective on architecture are characterized.

1: Introduction

In every software system, some architecture is present. The problem is that architecture is only implicitly
available. The architecture did exist for developers during the design phase, but because it was not expressed
explicitly, the architecture either has been lost, or has only been reproduced to some extent in software
documentation. The consequences of the architecture are present in terms of the properties and qualities of
the software.

Software Architecture. Software architecture is defined in various different ways.
[9]: “Abstractly, software architecture involves the description of elements from which systems are built,
interactions among those elements, patterns that guide their composition, and constraints on these patterns.
In general, a particular system is defined in terms of a collection of components and interactions among those
components. Such a system may in turn be used as a (composite) element in a larger system design.”
[3]: “A software architecture is a description of the subsystems and components of a software system and the
relationships between them. Subsystems and components are typically specified in different views to show
the relevant functional and non-functional properties of a software system. The software architecture of a
system is an artifact. It is the result of the software design activity.”
[10]: “An architecture integrates separate but interfering issues of a system, such as provisions for inde-
pendent evolution and openness combined with overall reliability and performance requirements. An archi-
tecture defines guidelines that together help to achieve the overall targets without having to invent ad hoc
compromises during system composition.”
[1]: “The software architecture of a program or computing system is the structure or structures, which
comprise software components, the externally visible properties of those components, and the relationships
among them.”
[8]: “Architecture means style or manner of building”. For a software system we interpret software architec-
ture to mean the actual choice of architectural abstractions and language mechanisms, especially abstraction
mechanisms, and the actual use of the elements chosen, i.e. how they are combined, their iterations, varia-
tions etc.”
In a brief characterization of these definitions of software architecture we claim that these describe orga-
nization only, not abstraction. We distinguish between organizing and abstracting: If we organize a certain
¡

This research was supported in part by Danish National Centre for IT Research, Project No. 74.

domain, we only put some kind of order in the domain, among the elements in the given domain. The result
is that the elements are grouped, sorted, or otherwise related to each other according to different possibly
overlapping organization principles. If we abstract from a certain domain, (may be in general for abstrac-
tion and not only conceptual abstraction) we create new quot;conceptsquot;/elements in another domain, an abstract
domain. The elements in the new domain describe the elements in the former domain, and the relations
among elements in the former domain. By moving to another domain we create knowledge about the former
domain, and not just order. The concepts/elements of the new domain carry information about the former
domain.
The architecture of some software is a model of the software. In this article we focus on conceptual models
of software. A model is conceptual in the sense that it forms a conceptual understanding of something, and
that it is based on concept formation in terms of classification, generalization and aggregation.

Consequences: Abstractions over Software. Our thesis is that software architecture is abstractions over
the software domain. Some immediate consequences of this thesis include that
(1) The software must have been produced or at least be anticipated, i.e. the software domain must exist in
some form. The software domain is given by descriptions — focus during architecture design is on these
descriptions. The result of design are concrete/abstract descriptions (notation/diagrams) in addition to the
software domain. But there is no given sequence — architecture may be created as a prescription of some
anticipated software.
(2) Architecture descriptions appears to be redundant descriptions. Because the software domain is available
architecture design seems to be an additional and even redundant description. The challenge is to clarify why
it is necessary to elaborate on the software description, to make an understanding / a mental model explicit,
and to create abstractions over the software domain.
(3) Architecture design requires abstraction. Abstraction implies, in addition to organization and delimita-
tion, formation of concepts at another abstraction level together with use of the concepts at that level. We
abstract from irrelevant details and concrete matters, given selected perspectives. But we have to find, in-
troduce, and motivate the abstractions (and the perspectives). Enough experience in architecture design and
insight in the given application is necessary to be able to come up with suggestions for the right abstractions,
and to decide which are the correct and promising ones.
(4) The nature of abstractions over the software domain is still partially unexplored and unfamiliar. In
our abstractions in object-oriented modeling the descriptions are concrete — abstract matters are related
to problem and the usage domains. Abstractions over the software domain are different — probably more
abstract and unreal. The challenge is to clarify the essence of software abstractions, and specify the quality
measure for abstractions.
(5) The architecture design process must be covered by software development methodologies. Architecture
is only superficially introduced, usually only mentally, because of lack of support of this in methodologies.
Architecture design is difficult, and because architecture design is not covered by methodologies the general
situation is that we have little experience, no very good examples or prototypical cases. Methodologies do
not promote (acceptance of) reuse of design — reuse of code is still the rule.

Article Organization. In section 2 we establish the necessary background for the perspective on soft-
ware architecture to be discussed in section 3. In subsection 2.1 we briefly discuss a model of the domains
and views in the design phase in the software development process. In subsection 2.2 we elaborate on an
underlying model of abstraction processes in relation to software development processes. In section 3 we
discuss consequences of architecture seen as abstractions over the software domain. We characterize the
process-related and the notation-related aspects, and we propose principles governing architectural design.
In section 4 we summarize the contributions of this article.

Problem Domain Model System Domain Model
Development Domain Model

Usage Domain Model

System
User Developer

Problem Domain Usage Domain Development Domain System Domain

Figure 1. Domains and Models

2: Abstraction

2.1: Domains and Views

In Figure 1 we illustrate the domains and models from an abstract generalized model of the software
development process (the domains and models discussed in the following are a revised and more complete
model than the model from [5]). In the analysis phase the problem domain model and usage domain model
are constructed from the problem domain and usage domain through a cooperation between user and devel-
oper. In the design phase the developer in the development domain uses the usage domain model to refine
the problem domain model into a system domain model.
The domains and models illustrate the vision during the system development process — as such they
reflect the understanding according to the current iteration. The focus point in the illustration is the system
to be developed. The system illustrates the concrete system — the actual, real system.
The system is going to be used by some user. As such the system is part of the usage domain. The system
takes care of some tasks in relation to the problem domain. The user has an understanding of the problem and
usage domains — namely the models of these domains. When the user operates the system these models form
the universe of the operations, their state and their results. The concrete form of the problem domain model
and the usage domain model can be respectively [2]: object diagrams, class diagrams, use case diagrams,
interaction (sequence and collaboration) diagrams, state chart diagrams, and activity diagrams.
The system is going to be developed by some developer. As such the system is part of the development
domain. The developer is part of the development domain — the model of this domain is implicitly given
only (that is why the model has dotted lines). The system domain is the actual resulting software that
comprises the system at the very concrete level. The system domain is the actual software. The system
illustrates the software and everything else that is needed to make it a running system. The system domain
model forms the developer’s conception of the integration of the problem and usage domain models at an
abstract level. It is a refined, transformed and enriched problem domain model. The concrete form of the
system domain model can be [2]: object diagrams, class diagrams, interaction (sequence and collaboration)
diagrams, state chart diagrams, activity diagrams, component diagrams, deployment diagrams. Most of
the diagramming techniques are the ones known from object-oriented analysis. When applying them to
describe the system domain model we apply them differently: the objects and classes are of a more technical
nature (not necessarily representing problem or usage domain phenomena and concepts); they belong to the
software domain; they have more rigorously defined properties. As a result of the changed perspective on the
objects and classes, the applications of diagrams in the description of a system domain model also has a more
technical nature. In addition to these diagrams we can also specify or sketch designs in an object-oriented
programming language. Depending on the goal of the description, the described code can act as a vehicle for
communicating ideas or as a basis for a prototype implementation. The system domain model also supports
the usage of the system, and not only the conception of the problem domain. The usage of the system is seen
from two different points of view — the user’s and the developer’s.

Problem Domain Model System Domain Model
Development Domain Model

Usage Domain Model

Interface Components
Functions &
Model System Connectors
User Developer
User’s System View Developer’s System View

Figure 2. System Views

Figure 2 elaborates further on the distinct views on the system from the user and developer. The user view
supports the understanding in terms of the problem and usage domains. The system operates on a model
of the problem domain, based on some functions that support the identified usage patterns captured by the
usage model, through an interface that exposes the functions according to the user’s capabilities etc. The
developers view supports the understanding in terms of the system domain model. This understanding is
controlled and supported by the development domain (model). The system is organized as a collection of
components and connectors of very general nature. The actual organization of these reflects the functional
and non-functional requirements to the system1 .
The architecture model (Figure 3) is an abstraction over the system domain model. The architecture
model forms the developer’s conception of the architecture of the system, i.e. the overall structures and
their relations and interactions. The model focuses for example on structure and interaction embedded in
the system domain model. The purpose of the architecture model is to understand the system domain model
given a various selected perspectives on that model, to allow us to reason about and expose the support of
non-functional requirements in the software, and to map the system domain model onto the logical platform.
The system domain model includes descriptions, partial or complete, of software. Various kinds of design
notations are used.

Architecture Model Components & Connectors:
Components
Interface
Logical &
Connectors
Functions
Abstraction
Components Model
&
Physical
Connectors
System Model
Developer’s System View

Figure 3. Abstraction and Components/Connectors

In Figure 3 the architecture model is shown as a logical model — an abstraction over the system domain
model. We call the system domain model a physical model because this is how the model of the system
1
The functional requirements is a set of requirements concerning the capabilities of a system — what the system
should be able to support. The non-functional requirements is a set of requirements concerning qualities not related
to the functionality of the system — for example usability, security, efficiency, correctness, reliability, maintainability,
testability, flexibility, understandability, reusability, portability, adaptability. The logical platform is a description of the
platform on which the system is going to be executed but at a logical level — i.e. requirements in terms of user interface,
distribution, persistence and concurrency.

domain is represented. The physical model is the basis for various additional models — logical models,
because they express various understandings of the system domain model. The logical models together form
the architecture model. In Figure 3 the models at both levels are illustrated as collections of components
and connectors. Components and connectors should not be seen literally. The idea is only that at a certain
level any description of a model can be seen as some specialized kinds of components and connectors. Also
we have indicated that both components and connectors can be seen as structures with three ingredients,
namely interface, functions and model, where each of these are recursively collections of components and
connectors.
The result of the design phase is not a model of some existing domain similar to the problem domain or the
usage domain — the system domain is non- or only partial existing during the development process. Rather,
the system domain model is a unique design, something constructed and created by the developer based on
his skills and knowledge (the development domain), and from the problem and usage domain models. After
its construction the system domain architecture models both works as models in addition to the problem and
usage domain models, but from specific design perspectives.
The problem and system domain models are the foundation for creating the architecture. The usage model
is used during the design for controlling the transformation of the problem domain model into the system
domain model. The usage model, together with the functional requirements, supply the information for
adding and distributing the functionality to the problem domain model to the extent that this information is
not already there. The architecture model is a constructive solution for how the non-functional requirements
and the organization of the logical platform can be combined.

2.2: Abstraction and Modeling.

The Nature of Abstraction. We discuss nature and purpose of abstraction — both in general, abstract
terms and in terms specific to abstraction over the software domain.
We distinguish between referent system and model system. The referent system is the domain we observe
— the quot;realquot; world (even though it may be imaginary). The model system is the product we construct in the
form of some explicit representation of the abstract model. We observe phenomena in the referent system,
and we classify these by concepts also in the referent system. Figure 4 illustrates the referent and model
systems. It includes the modeler and the perspective applied on the real world. The connections between the
elements in the domains in the referent system and the model system are indicated by means of dotted lines.
A number of more or less well defined notions within abstraction exist for concept formation in the
referent system. These include among others classification, generalization and aggregation (and dual or
inverse notions of these). When we observe phenomena in the referent system we always apply a perspective.
The perspective determines which properties we choose to include in our abstract model — properties form
concepts.

Figure 4. Worlds, Perspectives & Models

The purpose of abstraction is to understand. If we do not abstract, we only see a wilderness of different

A todo esto ¿Qué es una arquitectura?

A todo esto ¿Qué es una arquitectura?

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (7)

Similar to A todo esto ¿Qué es una arquitectura?

Similar to A todo esto ¿Qué es una arquitectura? (20)

Recently uploaded

Recently uploaded (20)

A todo esto ¿Qué es una arquitectura?