A todo esto ¿Qué es una arquitectura?

2,806 views

Published on

Serie de semiarios DCC8090. Charla: "A todo esto, ¿Qué es una arquitectura?". Autor: Juan Carlos Barroux. 2008.

Published in: Business
  • Be the first to comment

A todo esto ¿Qué es una arquitectura?

  1. 1. 11 de Junio 2008 Juan Carlos Barroux R. jbarroux@leconseil.cl http://www.linkedin.com/in/juancarlosbarrouxr
  2. 2. 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.
  3. 3. ¿Qué es una arquitectura?
  4. 4. ¿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.
  5. 5. ¿Qué es una arquitectura? Los invariantes de un sistema.
  6. 6. ¿Qué es una arquitectura? Distribución en el tiempo y en el espacio de los objetos.
  7. 7. ¿Qué es una arquitectura? “Architectures are hollistic bridges, but also processes” James Baty
  8. 8. ¿Qué es una arquitectura? Un proceso que genera una visión compartida de las relaciones entre los componentes de un sistema.
  9. 9. ¿Qué no es una arquitectura? • Un dibujo • Algo estático • Una imposición • Un secreto
  10. 10. ¿Qué es un[a] arquitect{o,a}? “Tous imbéciles. Oublient toujours l’escalier des maisons” Gustave Flaubert
  11. 11. ¿Para qué necesito una arquitectura? ¡Para controlar la complejidad! Los sistemas son complejos y dinámicos.
  12. 12. ¿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ó?
  13. 13. ¿Cómo piensa un arquitecto? ➔ 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.
  14. 14. ¿Cómo piensa un arquitecto? • 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.
  15. 15. ¿Cómo piensa un arquitecto? • 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.
  16. 16. ¿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
  17. 17. ¡Gracias! http://www.leconseil.cl/ Versión 1.1
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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 archi- tecture 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
  22. 22. I Figure 1 General software structure 254 WHEELER AND GANEK BM SYSTEMS JOURNAL, VOL 27. NO 3. 1988
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. Figure 3 Cooperativeprocessing HOST SYSTEMS IBM SYSTEMS JOURNAL, VOL 27. NO 3, 1983 WHEELER AND GANEK 259
  28. 28. 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
  29. 29. 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
  30. 30. Figure 4 Enterprise Information System MID-RANGE LARGE 262 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988
  31. 31. 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
  32. 32. 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/˜awg) 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
  33. 33. 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
  34. 34. 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
  35. 35.   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.
  36. 36. 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.
  37. 37. 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.
  38. 38. 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.
  39. 39. 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

×