发信人: wjanry()
整理人: (2000-03-07 20:29:38), 站内信件
|
The 4+1 View Model of Architecture
Philippe Kruchten
Rational Software Corp.
Vancouver, B.C., Canada
[email protected]
Reprinted with permission from IEEE Software, November 1995, 12 (6), p
p.42-50
© 1995 IEEE. Personal use of this material is permitted. However,
permission to reprint/republish this material for advertising or prom
otional purposes or for creating new collective works for resale or re
distribution to servers or lists, or to reuse any copyrighted componen
t of this work in other works must be obtained from the IEEE.
Outline
4+1 View Model
Logical view
Process view
Development view
Physical view
Scenarios
Correspondence Among Views
From logical view to process view
From logical view to development view
General issues
Iterative Process
Scenario-driven approach
Timetable
Tailoring the model
Documentation
Acknowledgments
References
The 4+1 View Model organizes a description of a software architecture
using five concurrent views, each of which addresses a specific set of
concerns. Architects capture their design decisions in four views and
use the fifth view to illustrate and validate them.
We all have seen many books and articles in which a single diagram att
empts to capture the gist of a system architecture. But when you look
carefully at the diagram's boxes and arrows, it becomes clear that the
authors are struggling to represent more in one diagram than is pract
ical. Do the boxes represent running programs? Chunks of source code?
Physical computers? Or merely logical groupings of functionality? Do t
he arrows represent compilation dependencies? Control flows? Dataflows
? Usually the answer is that they represent a bit of everything.
Does an architecture need a single architectural style? Sometimes the
software architecture suffers from system designers who go too far, pr
ematurely partitioning the software or overemphasizing one aspect of d
evelopment (like data engineering or run-time efficiency), development
strategy, or team organization. Other software architectures fail to
address the concerns of all "customers."
Several authors have noted the problem of architectural representation
, including David Garlan and Mary Shaw, [1] Gregory Abowd and Robert A
llen, [2] and Paul Clements. [3]
The 4 + 1 View Model was developed to remedy the problem. The 4 + 1 mo
del describes software architecture using five concurrent views. As Fi
gure 1 shows, each addresses a specific set of concerns of interest to
different stakeholders in the system.
The logical view describes the design's object model when an object-or
iented design method is used. To design an application that is very da
ta-driven, you can use an alternative approach to develop some other f
orm of logical view, such as an entity-relationship diagram.
The process view describes the design's concurrency and synchronizatio
n aspects.
The physical view describes the mapping of the software onto the hardw
are and reflects its distributed aspect.
The development view describes the software's static organization in i
ts development environment.
Software designers can organize the description of their architectural
decisions around these four views, and then illustrate them with a fe
w selected use cases, or scenarios, which constitute a fifth view. The
architecture is partially evolved from these scenarios.
At Rational, we apply Dewayne Perry and Alexander Wolf's formula[4]
Software architecture = {Elements, Forms, Rationale/Constraints}
independently on each view. For each view we define the set of element
s to use (components, containers, and connectors), capture the forms a
nd patterns that work, and capture the rationale and constraints, conn
ecting the architecture to some of the requirements.
Each view is described by what we call a "blueprint" that uses its own
particular notation. The architects can also pick a certain architect
ural style for each view, thus allowing the coexistence of multiple st
yles in one system.
The 4+1 View Model is rather generic: You can use notations and tools
other than those we describe, as well as other design methods, especia
lly for the logical and process decompositions.
Figure 1 The 4+1 View Model is used to organize the description of the
architecture of a software-intensive system.
4+1 View Model
Software architecture deals with abstraction, decomposition and compos
ition, and style and aesthetics. It also deals with the design and imp
lementation of software's high-level structure.
Designers build architectures using several architectural elements in
well-chosen forms. These elements satisfy the major functionality and
performance requirements of the system as well as other, nonfunctional
requirements such as reliability, scalability, portability, and syste
m availability.
Logical view
The logical view primarily supports the functional requirements--the s
ervices the system should provide to its end users. Designers decompos
e the system into a set of key abstractions, taken mainly from the pro
blem domain. These abstractions are objects or object classes that exp
loit the principles of abstraction, encapsulation, and inheritance. In
addition to aiding functional analysis, decomposition identifies mech
anisms and design elements that are common across the system.
We use the Rational/Booch approach[5] to represent the logical view th
rough class diagrams and templates. A class diagram shows a set of cla
sses and their logical relationships: association, usage, composition,
inheritance, and so on. Designers can group sets of related classes i
nto class categories. Class templates focus on each individual class;
they emphasize the main class operations and identify key object chara
cteristics. If an object's internal behavior must be defined, we use s
tate-transition diagrams or state charts. Class utilities define commo
n mechanisms or services.
(A)
(B)
(C)
Figure 2 (A) Notation for the logical blueprint; (B) logical blueprint
for the Télic PBX; (C) blueprint for an air-traffic control system.
Notation. We derived the logical-view notation in Figure 2a from the B
ooch notation, which we simplified considerably to account for only th
ose items that are architecturally significant. The numerous adornment
s are not very useful at this level of design. We use Rational Rose to
support the logical-view design.
Style. For the logical view, we use an object-oriented style. The main
design guideline we follow is to keep a single, coherent object model
across the entire system, avoiding the premature specialization of cl
asses and mechanisms for each site or processor.
Examples. Figure 2b shows the main classes involved in a sample PBX ar
chitecture we developed at Alcatel. A PBX establishes communication am
ong terminals. A terminal might be a telephone, a trunk line (a line t
o the central office), a tie line (a private PBX-to-PBX line), or a fe
ature phone line.
Different lines are supported by different line-interface cards. The C
ontroller object decodes and injects all the signals on the line-inter
face card, translating card-specific signals to and from a small, unif
orm set of events, such as a "start," "stop," or "digit." The controll
er also bears all the hard real-time constraints. This class has many
subclasses that cater to different interfaces.
The Terminal object maintains the state of a terminal and negotiates s
ervices on behalf of that line. For example, it uses the services of t
he Numbering Plan object to interpret dialing.
The Conversation object represents a set of terminals engaged in a con
versation. It uses the Translation Services object (for accessing a di
rectory, mapping a logical address to a physical one, and routing) and
the Connection Services object to establish a voice path among the te
rminals.
Larger systems contain dozens of architecturally significant classes,
such as the top-level class diagram of an air-traffic control system[6
] in Figure 2c. The system, developed by Hughes Aircraft of Canada, co
ntains eight class categories.
(A)
(B)
Figure 3 (A) Notation for the process view; (B) partial process bluepr
int for the Télic PBX.
Process view
The process view takes into account some nonfunctional requirements, s
uch as performance and system availability. It addresses concurrency a
nd distribution, system integrity, and fault-tolerance. The process vi
ew also specifies which thread of control executes each operation of e
ach class identified in the logical view.
Designers describe the process view at several levels of abstraction,
each one addressing a different concern. At the highest level, the pro
cess view can be seen as a set of independently executing logical netw
orks of communicating programs ("processes") that are distributed acro
ss a set of hardware resources, which in turn are connected by a bus o
r local area network or wide area network. Multiple logical networks m
ay exist simultaneously, sharing the same physical resources. For exam
ple, you can use independent logical networks to separate on- and off-
line operational systems and to represent the coexistence of simulatio
n or test versions of the software.
A process is a group of tasks that form an executable unit. Processes
represent the level at which the process view can be tactically contro
lled (started, recovered, reconfigured, shut down, and so on). In addi
tion, processes can be replicated to distribute processing load or imp
rove system availability.
Partitioning. To develop the process view, designers partition the sof
tware into a set of independent tasks: separate threads of control tha
t can be individually scheduled on separate processing nodes.
We separate tasks into two groups:
Major tasks are the architectural elements that can be uniquely addres
sed (designated from another task). They communicate through a set of
well-defined intertask-communication mechanisms: synchronous and async
hronous message-based communication services, remote procedure calls,
event broadcasts, and so on. Major tasks should not make assumptions a
bout their collocation in the same process or processing node.
Minor tasks are additional tasks introduced locally for implementation
reasons such as cyclical activities, buffering, and time-outs. They c
an be implemented as Ada tasks or lightweight threads, for example, an
d communicate by rendezvous or shared memory.
We use the process blueprint to estimate message flow and process load
s. It is also possible to implement a "hollow" process view with dummy
process loads and measure its performance on a target system. [7]
Notation. Our process-view notation is expanded from Booch's original
notation for Ada tasking and focuses on architecturally significant el
ements, as Figure 3a shows.
We have used TRW's Universal Network Architecture Services to build an
d implement the processes and tasks (and their redundancies) into netw
orks of processes. UNAS contains a tool--the Software Architects Lifec
ycle Environment--that supports our notation. SALE lets us depict the
process view graphically, including specifications of the possible int
ertask-communication paths. It can then automatically generate the cor
responding Ada or C++ source code. Because it supports automatic code
generation, SALE makes it easier to change the process view.
Style. Several styles would fit the process view. For example, picking
from Garlan and Shaw's taxonomy, you can use pipes and filters or cli
ent/server, with variants of multiple-client/single-server and multipl
e-clients/multiple-servers. For more complex systems, you can use a st
yle similar to the ISIS system's process groups, as described by Kenne
th Birman using another notation and toolset. [8]
Example. Figure 3b shows a partial process view for the PBX introduced
in Figure 2b. All terminals are handled by a single terminal process
that is driven by messages in its input queues. The Controller objects
are executed on one of three tasks that comprise the controller proce
ss: a low cycle-rate task, which scans all inactive terminals (200 ms)
and puts any terminal becoming active in the scan list of the high cy
cle-rate task (10 ms), which detects any significant changes of state
and passes them to the main controller task, which interprets the chan
ges and communicates them by message to the corresponding terminal. Me
ssage passing within the controller process is done through shared mem
ory.
Development view
The development view focuses on the organization of the actual softwar
e modules in the software-development environment. The software is pac
kaged in small chunks--program libraries or subsystems--that can be de
veloped by one or more developers. The subsystems are organized in a h
ierarchy of layers, each layer providing a narrow and well-defined int
erface to the layers above it.
The development view takes into account internal requirements related
to ease of development, software management, reuse or commonality, and
constraints imposed by the toolset or the programming language. The d
evelopment view supports the allocation of requirements and work to te
ams, and supports cost evaluation, planning, monitoring of project pro
gress, and reasoning about software reuse, portability, and security.
It is the basis for establishing a line of product.
The development view is represented by module and subsystem diagrams t
hat show the system's export and import relationships. You can describ
e the complete development view only after you have identified all the
software elements. However, you can list the rules that govern the de
velopment view--partitioning, grouping, and visibility--before you kno
w every element.
Notation. As Figure 4 shows, we again use a variation of the Booch not
ation, limited to architecturally significant items. Rational's Apex d
evelopment environment supports the definition and implementation of t
he development view, the layering strategy described above, and design
-rule enforcement. Rational Rose can draw the development blueprints f
or Ada and C++ at the module and subsystem level, in forward engineeri
ng, and by reverse engineering from the development source code.
Figure 4 Notation for a development blueprint.
Style. We recommend you define four to six layers of subsystems in the
development view. One design rule we follow here is that a subsystem
can only depend on subsystems in the same or lower layers. This minimi
zes the development of very complex networks of dependencies between m
odules in favor of a simpler, layer-by-layer release strategy.
Examples. As Figure 5 shows, the Hughes Air Traffic System has five de
velopment layers. [6] Layers 1 and 2--utilities and support mechanisms
--constitute a domain-independent, distributed infrastructure that is
common across the line of products. These layers shield the applicatio
n from variations in hardware platforms, operating systems, or off-the
-shelf products such as database-management systems. To this infrastru
cture, layer 3 adds an air-traffic control framework to form a domain-
specific software architecture. Layer 4 adds a palette of functionalit
y, and layer 5 contains most of the user interface and the interfaces
to external systems. This top layer is customer-and product-dependent.
Spread across the five layers are some 72 subsystems, each containing
from 10 to 50 modules. We represent these subsystems on additional, m
ore detailed blueprints.
Figure 5 The five layers of Hughes' Air Traffic System.
Physical view
The physical view takes into account the system's nonfunctional requir
ements such as system availability, reliability (fault-tolerance), per
formance (throughput), and scalability. The software executes on a net
work of computers (the processing nodes). The various elements identif
ied in the logical, process, and development views--networks, processe
s, tasks, and objects--must be mapped onto the various nodes. Several
different physical configurations will be used--some for development a
nd testing, others for system deployment at various sites or for diffe
rent customers. The mapping of the software to the nodes must therefor
e be highly flexible and have a minimal impact on the source code itse
lf.
Notation. Because physical blueprints can become very messy in large s
ystems, we organize them in several forms, with or without the mapping
from the process view, as Figures 6 and 7 show.
(A)
(B)
Figure 6 (A) Notation for a physical blueprint; (B) a PBX physical blu
eprint.
UNAS provides us with a data-driven means of mapping the process view
onto the physical view. This lets us make many changes to the mapping
without modifying the source code.
Figure 6b shows a possible hardware configuration for a large PBX; Fig
ures 7a and 7b show mappings of the process view on two different phys
ical views, a small and a large PBX.
(A)
(B)
Figure 7. (A) A small PBX physical view with process allocation; (B) a
physical blueprint for a larger PBX; C, F, and K are three types of c
omputers that have different capacities and support three different ex
ecutables.
Scenarios
We use a small subset of important scenarios--instances of use cases--
to show that the elements of the four views work together seamlessly.
For each scenario, we describe the corresponding scripts (sequences of
interactions between objects and between processes) as described by K
en Rubin and Adele Goldberg.[9] The scenarios are in some sense an abs
traction of the most important requirements. Their design is expressed
using object-scenario and object-interaction diagrams. [5]
This view is redundant with the other ones (hence the "+1"), but it pl
ays two critical roles:
It acts as a driver to help designers discover architectural elements
during the architecture design
It validates and illustrates the architecture design, both on paper an
d as the starting point for the tests of an architectural prototype
Notation. The scenario notation is very similar to that used for the l
ogical view, except that it uses the connectors from the process view
to indicate object interactions. As for the logical view, we manage ob
ject-scenario diagrams using Rational Rose. Figure 8 shows a fragment
of a scenario for the small PBX. The corresponding script reads:
The controller of Joe's phone detects and validates the transition fro
m on-hook to off-hook and sends a message to wake the corresponding te
rminal object.
The terminal allocates some resources and tells the controller to emit
a dial tone.
The controller receives digits and transmits them to the terminal.
The terminal uses the numbering plan to analyze the digit flow.
When a valid sequence of digits has been entered, the terminal opens a
conversation.
Figure 8 A scenario example from a local-call selection phase.
Correspondence Among Views
The various views are not fully independent. Elements of one view are
connected to elements in other views, following certain design rules a
nd heuristics.
From logical view to process view
We identify several important characteristics of the logical view clas
ses: autonomy, persistence, subordination, and distribution.
Autonomy identifies whether objects are active, passive, or protected.
An active object invokes other objects' operations or its own operati
ons, and has full control over other objects invoking its operations.
A passive object never spontaneously invokes any operations, and has n
o control over other objects invoking its operations. A protected obje
ct never invokes spontaneously any operations but arbitrates the invoc
ation of its own operations.
Persistence identifies whether objects are transient or permanent. Do
they survive the failure of a process or processor? Subordination dete
rmines if the existence or persistence of an object depends upon anoth
er object. Distribution determines if the object's state or operations
are accessible from many nodes in the physical view and from several
processes in the process view.
In the logical view of the architecture, we could consider each object
as active and potentially concurrent; that is, behaving in parallel w
ith other objects and paying no more attention to the exact degree of
concurrency than it needs to achieve this effect. Hence the logical vi
ew takes into account only the requirements' functional aspects.
However, when we define the process view, it is not practical to imple
ment each object with its own thread of control (such as its own UNIX
process or Ada task) because of the huge overhead this imposes. More o
ver, if objects are concurrent, there must be some form of arbitration
for invoking their operations.
On the other hand, multiple threads of control are needed to:
React rapidly to certain classes of external stimuli, including time-r
elated events
Take advantage of multiple CPUs in a node or multiple nodes in a distr
ibuted system
Increase CPU utilization by allocating CPUs to other activities when a
thread of control is suspended during another activity (such as acces
s to some external device or access to some other active object)
Prioritize activities (and thus potentially improve responsiveness)
Support system scalability (by having additional processes sharing the
load)
Separate concerns between different areas of the software
Achieve a higher system availability (with backup processes)
Determining concurrency. We use two strategies simultaneously to deter
mine the "right" amount of concurrency and define the set of necessary
processes. Keeping in mind the set of potential physical target views
, we can proceed either from the inside out or the outside in.
Inside out. Starting from the logical view, we define agent tasks that
multiplex a single thread of control across multiple active objects o
f a given class. We execute subordinate objects on the same agent as t
heir parent. Classes that must be executed in mutual exclusion, or tha
t require a minimal amount of processing share a single agent. This cl
ustering proceeds until we have reduced the processes to a small numbe
r that still allows distribution and use of the physical resources.
Outside in. Starting with the physical view, we identify external stim
uli (requests) to the system, and then define client processes to hand
le the stimuli and server processes that provide (rather than initiate
) services. We use the problem's data integrity and serialization cons
traints to define the right set of servers and allocate objects to the
client and servers agents. We then identify which objects must be dis
tributed.
The result is a mapping of classes (and their objects) onto a set of t
asks and processes of the process view. Typically, there is an agent t
ask for an active class, with some variations, such as several agents
for a given class to increase throughput or several classes mapped ont
o a single agent either to assure sequential execution or because the
class operations are infrequently invoked.
Finally, this is not a linear, deterministic process leading to an opt
imal process view; it requires a few iterations to reach an acceptable
compromise. There are numerous other ways to proceed. [8, 10]
Example. The exact method used to construct the mapping is complex. Ho
wever, a brief example from a hypothetical air-traffic control system
can illustrate it. Figure 9 shows how a small set of classes from the
system can be mapped onto processes.
The flight class is mapped onto a set of flight agents that must quick
ly process many flights and spread the load across multiple CPUs while
contending with large numbers of external stimuli. The persistence an
d distribution aspects of the flight processing are deferred to a flig
ht server, which is duplicated to assure system availability. Flight p
rofile or flight clearance is always subordinate to a flight, and alth
ough there are complex classes, they share the processes of the flight
class. Flights are distributed to several other processes, notably fo
r display and external interfaces.
A sectorization class establishes a partitioning of airspace to assign
controller jurisdiction over flights. Because of its integrity constr
aints, this class must be handled by a single agent, but it can share
the server process with the flight, as updates are infrequent. Locatio
ns, airspace, and other static aeronautical information are protected
objects, shared among several classes. These are rarely updated and ma
pped on their own server and distributed to other processes.
Figure 9 Mapping from the (A) logical to the (B) process view.
From logical view to development view
A class is usually implemented as a module, and large classes are deco
mposed into multiple packages. Collections of closely related classes-
-class categories--are grouped into subsystems. To define subsystems,
we must consider additional constraints, such as team organization, ex
pected magnitude of code (typically 5,000 to 20,000 lines of code per
subsystem), degree of expected reuse and commonality, as well as stric
t layering principles (visibility issues), release policy, and configu
ration management. Thus, we usually end up with a view that does not h
ave a one-to-one correspondence with the logical view.
General issues
The logical and development views are very close, but address very dif
ferent concerns. We have found that the larger the project, the greate
r the distance between these views. This also holds for the process an
d physical views. For example, comparing Figure 2c with Figure 5, ther
e is no one-to-one mapping from the class categories to the layers. Th
e External Interface/Gateway category is spread across several layers:
communications protocols are in subsystems in or below layer 1, gener
al gateway mechanisms are in subsystems in layer 2, and the actual spe
cific gateways are in layer 5 subsystems.
Processes and process groups are mapped onto the available physical ha
rdware in various configurations for testing or deployment. Birman des
cribes some very elaborate schemes for this mapping in the ISIS projec
t. [8]
In terms of which classes are used, scenarios relate mainly to the log
ical view, or to the process view when interactions between objects in
volve more than one thread of control.
Iterative Process
Bernard Witt and his colleagues describe four phases for architectural
design--sketching, organizing, specifying, and optimizing--and subdiv
ide them into 12 steps. [10] Although they do indicate that some backt
racking may be needed, we think their approach is too linear for ambit
ious or unprecedented projects, because too little is known at the end
of the phases to validate the architecture. We advocate a more iterat
ive development, in which the architecture is actually prototyped, tes
ted, measured, and analyzed, and then refined in subsequent iterations
.
Our approach not only mitigates the risks associated with the architec
ture, it also helps build teams and improves training, architecture fa
miliarity, tool acquisition, the initial run-in period for procedures
and tools, and so on. (This holds for evolutionary, rather than throwa
way prototypes.) An iterative approach also helps you refine and bette
r understand the requirements.
Scenario-driven approach
Scenarios capture the system's critical functionality--functions that
are the most important, are used most frequently, or present significa
nt technical risk.
To begin, select a few scenarios on the basis of risk and criticality.
You may synthesize a scenario by abstracting several user requirement
s. Then create a strawman architecture and script the scenarios, ident
ifying major abstractions (such as classes, mechanisms, processes, sub
systems) [9] and decomposing them into sequences of pairs (object, ope
ration).
Next, organize the architectural elements into the four views, impleme
nt the architecture, test it, and measure it. This analysis helps you
detect flaws or potential enhancements. Finally, capture lessons learn
ed.
Begin the next iteration by reassessing the risks, extending the scena
rios to consider, and selecting a few additional scenarios on the basi
s of risk or extending architecture coverage. Then try to script those
scenarios in the preliminary architecture and discover additional arc
hitectural elements--or significant architectural changes--that must o
ccur to accommodate these scenarios. Update the four views and revise
the existing scenarios on the basis of these changes. Next, upgrade th
e implementation (the architectural prototype) to support the new exte
nded set of scenarios.
At this point, you should test the architecture by measuring under loa
d (in the target environment, if possible) and review all five views t
o detect potential simplifications, commonalities, and opportunities f
or reuse. Then update the design guidelines and rationale and capture
lessons learned. And then loop again.
Finally, the initial architectural prototype evolves to become the rea
l system. After two or three iterations, the architecture itself shoul
d become stable, and you should find no new major abstractions, subsys
tems, processes, or interfaces. The rest is in the realm of software d
esign--where you can continue development using very similar methods a
nd process.
Timetable
The duration of these iterations varies considerably, depending on the
size of the project, the number of people involved, and their experti
se in the domain and the development method. It also varies relative t
o the development organization. Hence the iteration may last two to th
ree weeks for a small project (10,000 lines of code), or from six to n
ine months for a large command-and-control system (700,000 lines of co
de or larger).
Tailoring the model
Not all software architectures need every view in the 4+1 View Model.
Views that are useless can be omitted. For example, you could eliminat
e the physical view if there is only one processor or the process view
if there is only one process or program. For very small systems, logi
cal and development views are sometimes so similar that they can be de
scribed together. The scenarios are useful in all circumstances.
Documentation
The documentation produced during the architectural design is captured
in two documents:
A software architecture document, organized by the 4+1 views
A software design guideline, which captures (among other things) impor
tant design decisions that must be respected to maintain the architect
ural integrity of the system
We have used the 4+1 View Model on several large projects, customizing
it and adjusting the terminology somewhat. We have found that the mod
el actually allows the various stakeholders to find what they need in
the software architecture. System engineers approach it first from the
physical view, then the process view; end users, customers, and data
specialists approach it from the logical view; and project managers an
d software-configuration staff members approach it from the developmen
t view.
Other sets of views have been proposed and discussed at our company an
d elsewhere, but we have found that proposed views can usually be fold
ed into one of the four existing views. A cost and schedule view, for
example, folds into the development view, a data view into the logical
view, and an execution view into a combination of the process and phy
sical view.
Acknowledgments
For their help in shaping or experimenting with the 4+1 View Model, I
thank my many colleagues at Rational, Hughes Aircraft of Canada, Celsi
usTech AB, Alcatel, and elsewhere, and in particular, Chris Thompson,
Alex Bell, Mike Devlin, Grady Booch, Walker Royce, Joe Marasco, Rich R
eitman, Viktor Ohnjec, Ulf Olson, and Ed Schonberg.
References
D. Garlan and M. Shaw, "An Introduction to Software Architecture," Adv
ances in Software Engineering and Knowledge Engineering, Vol. 1, World
Scientific Publishing Co., Singapore, 1993.
G. Abowd, R. Allen, and D. Garlan, "Using Style to Understand Descript
ions of Software Architecture," ACM Software Eng. Notes, Dec. 1993, pp
. 9-20.
Paul Clements, "From Domain Model to Architectures," A. Abd-Allah et a
l., eds., Focused Workshop on Software Architecture, 1994, pp. 404-420
.
D.E. Perry and A.L. Wolf, "Foundations for the Study of Software Archi
tecture," ACM Software Eng. Notes, Oct. 1992, pp. 40-52.
G. Booch, Object-Oriented Analysis and Design with Applications, 2nd.
ed., Benjamin-Cummings, Redwood City, Calif., 1993.
P. Kruchten and C. Thompson, "An Object-Oriented, Distributed Architec
ture for Large Scale Ada Systems," Proc. TRI-Ada '94, ACM Press, New Y
ork, 1994, pp. 262-271.
A. Filarey et al., "Software First: Applying Ada Megaprogramming Techn
ology to Target Platform Selection Trades," Proc. TRI-Ada '93, ACM Pre
ss, New York, 1993.
K.P. Birman and R. Van Renesse, Reliable Distributed Computing with th
e Isis Toolkit, IEEE CS Press, Los Alamitos, Calif. 1994.
K. Rubin and A. Goldberg, `Object Behavior Analysis," Comm. ACM, Sept.
1992, pp. 48-62.
B. I. Witt, F. T. Baker, and E.W. Merritt, Software Architecture and D
esign Principles, Models, and Methods, Van Nostrand Reinholt, New York
, 1994.
----------------------------------------------------------------------
----------
Philippe Kruchten is a senior technical consultant with Rational Soft
ware Corporation since 1987. He belongs to the corporate architecture
group, and consults on software architecture with major aerospace and
telecommunications around the world. He has been the lead software arc
hitect for the Canadian Automated Air Traffic Systems.
He has an engineering diploma from the Ecole Centrale de Lyon (France)
and a doctorate degree in computer science from the French Institute
of Telecommunications. He currently lives in Vancouver (Canada) with h
is wife Sylvie and his three children.
His office address is:
Rational Vancouver
240-10711 Cambie Rd.
Richmond, B.C. V6X 3G5
Canada
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.184.41]
|
|