Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
4Activity
0 of .
Results for:
No results containing your search query
P. 1
The 4+1 View Model of Architecture

The 4+1 View Model of Architecture

Ratings: (0)|Views: 601|Likes:
Published by moody_mannu

More info:

Published by: moody_mannu on Sep 11, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/11/2014

pdf

text

original

 
The
4+1
View
*The 4+1 V?ewModeladdressesa speczj% et of concerns.organizes a description of asojimare architecture usingjiveconcurrent views, each of which
Model ofArchitecture
PHILIPPE
B
. KRUCHTEN, Rational
Software
many books and articles in which ae all havesingle diagram attempts to capture theseengist of a system architecture. But whenyou look carefully at the diagram’sboxes and arrows, it becomes clear thatthe authors are struggling to representoveremphasizing one aspect of devel-opment (like data engineering or run-turely partitioning the software ortime efficiency), development strategy,or team organization. Other softwarearchitectures fail to address the con-cerns of all “customers.”
Architects capture their designdecisions n four- views and usethefiJZh view to illustrate andvalidate them.
more in one diagram than is practical.Do the boxes revpresent running pro-grams? Chunks of source code?Physical computers? Or merely logicalgroupings of functionality? Do thearrows represent compilation depen-dencies? Control flows? Dataflows?Usually the answer is that they repre-sent a bit of everything.Does an architecture need a singlearchitectural style? Sometimes thesoftware architecture suffers from sys-tem designers who go too far, prema-Several authors have noted theproblem of architectural representa-tion, including David Garlan andMary Shaw,’ Gregory Abowd andRobert Allen,’ and Paul C1ements.jThe 4 + I View Model was devel-oped to remedy the problem. The 4 +1 model describes software architec-ture using five concurrent views. AsFigure 1 shows, each addresses a spe-cific set of concerns of interest to dif-ferent stakeholders in the system.+ The logical view describes the
42
O/407459/94/$04
00 0 1994 WENOVEMBER 1995
 
design’s object model when an object-oriented design method is used. Todesign an application that is very data-driven, you can use an alternativeapproach to develop some other formof logical view, such as an entity-relationship diagram.+ The process view describes thedesign’s concurrency and synchroniza-tion aspects.+ The physical view describes themapping of the software onto thehardware and reflects its distributedaspect.+ The development view describesthe software’s static organization in itsdevelopment environment.Software designers can organize thedescription of their architectural deci-sions around these four views, andthen illustrate them with a few selecteduse cases, or scenarios, which constitutea fifth view. The architecture is partial-ly evolved from these scenarios.At Rational, we apply DewaynePerry and Alexander Wolfs formula’
Software architecture = [Elements,Forms, Rationale/Constraints}
independently on each view. For eachview we define the set of elements touse (components, containers, and con-nectors), capture the forms and pat-terns that work, and capture the ratio-nale and constraints, connecting thearchitecture to some of the require-ments.Each view is described by what wecall a “blueprint” that uses its own par-ticular notation. The architects canalso pick a certain ahitectural style foreach view, thus allowing the coexis-tence of multiple styles in one system.The 4+1 View Model is rathergeneric: You can use notations andtools other than those we describe, aswell as other design methods, especial-ly for the logical and process decom-positions.4tl VIEW MODELSoftware architecture deals withabstraction, decomposition and com-position, and style and aesthetics. Italso deals with the design and imple-mentation of software’s high-levelstructure.Designers build architectures usingseveral architectural elements in well-chosen forms. These elements satisfy
I ~~
EndusersProgrammers
l
functionality
l
softwaremanagementLogical iew. Development,~ew**.I)-=-. .< ?Scenarioshb*.e _/-Process iew -Physical iew. IIexe,_s_l . - ” .wi SystemntegratorsSystem ngineers
l
performance
l
system opology
l
scolobility
l
delivery
l
throughput
l
installation
l
telecommunication
Figure 1.
The 4+1 View Model isused to organize the description
of the
architecture
of
a software-intensivesystem.the major functionality and perfor-mance requirements of the system aswell as other, nonfunctional require-ments such as reliability, scalability,portability, and system availability.Logical view. The logical view pri-marily supports the functional require-ments - the services the systemshould provide to its end users.Designers decompose the system into
Simulation ndClass‘; Class tility~~~~~ AssotiotionContainment,oggregotionUsage-+ Inheritanceformalorgumentsporometerized -- -~---, kiStontiOtiOnclassClass ategoryDisplay nduser ~olerfoteExternal nterfores/Conversolion ~Translation :troiningservices.- xw&A-&1--.TerminalControllerConnection ,servicesr:.-+&JFlightAir troificmanogement monogement*- 9 YL. a,Aeronauticalmformotion
Figure
2.
(A)
Notation jh the logical blueprint; (B) logical blueprint for the Tt!lic PBX; (C) bluepht
for
an ail--trajcontrol system.
Best Copy Available
IEEE SOFTWARE---- ~~43
 
a set of key abstractions, taken mainlyfrom the problem domain. Theseabstractions are objects or object classesthat exploit the principles of abstrac-tion, encapsulation, and inheritance. Inaddition to aiding functional analysis,decomposition identifies mechanismsand design elements that are commonacross the system.We use the RationaUBoochapproach’ to represent the logical viewthrough class diagrams and templates.A class diagram shows a set of classesand their logical relationships: associa-tion, usage, composition, inheritance,and so on. Designers can group sets ofrelated classes into class categories. Classtemplates focus on each individual class;they emphasize the main class opera-tions and identify key object character-istics. If an object’s internal behaviormust be defined, we use state-transi-tion diagrams or state charts. Class util-ities define common mechanisms orservices.NOM~OII. e derived the logical-viewnotation in Figure 2a from the Boothnotation, which we simplified consid-erably to account for only those itemsthat are architecturally significant. Thenumerous adornments are not veryuseful at this level of design. We useRational Rose to support the logical-view design.Style.For the logical view, we use anobject-oriented style. The main designguideline we follow is to keep a single,coherent object model across theentire system, avoiding the prematurespecialization of classes and mecha-nisms for each site or processor.Examples. igure 2b shows the mainclasses involved in a sample PBX archi-tecture we developed at Alcatel. A PBXestablishes communication among ter-minals. A terminal might be a tele-phone, a trunk line (a line to the cen-tral of&e), a tie line (a private PBX-to-PBX line), or a feature phone line.Different lines are supported by dif-ferent line-interface cards. TheController object decodes and injectsall the signals on the line-interfacecard, translating card-specific signals toand from a small, uniform set ofevents, such as a “start,” “stop,” or“digit.” The controller also bears allthe hard real-time constraints. Thisclass has many subclasses that cater todifferent interfaces.The Terminal object maintains thestate of a terminal and negotiates ser-vices on behalf of that line. For exam-ple, it uses the services of theNumbering Plan object to interpretdialing.The Conversation object representsa set of terminals engaged in a conver-sation. It uses the Translation Servicesobject (for accessing a directory, map-ping a logical address to a physical one,and routing) and the ConnectionServices object to establish a voice pathamong the terminals.Larger systems contain dozens ofarchitecturally significant classes, suchas the top-level class diagram of an air-traffic control system’ in Figure 2c.The system, developed by HughesAircraft of Canada, contains eight classcategories.Processview. The process view takesinto account some nonfunctional
ComponentConnectors~~ UnspecifiedController rocessProcessTerminal rocess
-- .
Best Copy Available
NOVEMBER 1995
tontroller tosk(low rote)
-wA.r.
(ontroller task“...S[high rate).&‘ YS.
&we 3. (A) Notation
for the
process view; (B) partial process blueprint
for
the Tt!lic PBX.

Activity (4)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
elsmahy1 liked this
ggn1 liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->