130:
work influenced both architectural thinking about programming languages (e.g., Ada), and design and architecture notations (such as Buhr diagrams and use case maps and codified in architectural features of UML: packages, subsystems, dependences) and much of the work on architecture description languages. In addition to MILs, under the influence of mature work in the areas of
Requirements and Design within Software Engineering, various kinds of models were "lifted" from software engineering and design to be applied to the description of architectures. These included function and activity models from Structured Analysis
327:(University of L'Aquila, Italy). Early ADLs emphasized modeling systems in terms of their components, connectors and configurations. More recent ADLs (such as ArchiMate and SysML) have tended to be "wide-spectrum" languages capable of expressing not only components and connectors but a variety of concerns through multiple sub-languages. In addition to special-purpose languages, existing languages such as the
129:
Work on programming in the large, such as module interconnection languages (MILs) focused on the expression of the large-scale properties of software: modules (including programs, libraries, subroutines and subsystems) and module-relationships (dependencies and interconnections between modules). This
415:
Elaborating on the rationale aspect of Perry and Wolf's original formula, a third school of thought has emerged, documenting the decisions and reasons for decisions as an essential way of conceiving and expressing a software architecture. This approach treats decisions as first-class elements of the
112:
A common misunderstanding about architecture descriptions is that ADs only discuss "technical issues", but ADs need to address issues of relevance to many stakeholders. Some issues are technical; many issues are not: ADs are used to help architects, their clients and others manage cost, schedule and
125:
The earliest architecture descriptions used informal pictures and diagrams and associated text. Informal descriptions remain the most widely used representations in industry. Influences on architecture description came from the areas of
Software Engineering (such as data abstraction and programming
104:
The use of multiple views, while effective for communicating with diverse stakeholders and recording and analyzing diverse concerns, does raise potential problems: since views are typically not independent, the potential for overlap means there may be redundancy or inconsistency between views of a
398:
Second, reflected in work of CMU and elsewhere, the notion that architecture was the high level organization of a system at run-time and that architecture should be described in terms of their components and connectors: "the architecture of a software system defines that system in terms of
402:
During the 1990s-2000s, much of the academic work on ADLs took place within the paradigm of components and connectors. However, these ADLs have had very little impact in industry. Since the 1990s, there has been a convergence in approaches toward architecture description, with
488:
A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: A framework for integrating multiple perspectives in system development. International
Journal of Software Engineering and Knowledge Engineering, 2(1):31-58,
137:
Perry and Wolf cited the precedent of building architecture for the role of multiple views: "A building architect works with the customer by means of a number of different views in which some particular aspect of the building is emphasized."
235:). The viewpoint specifies not only the concerns framed (i.e., to be addressed) but the presentation, model kinds used, conventions used and any consistency (correspondence) rules to keep a view consistent with other views.
231:, where a viewpoint is a specification that describes the notations, modeling techniques to be used in a view to express the architecture in question from the perspective of a given set of stakeholders and their concerns (
55:
Architecture description defines the practices, techniques and types of representations used by software architects to record a software architecture. Architecture description is largely a modeling activity
97:). Each view in an architecture description should have a viewpoint documenting the concerns and stakeholders it is addressed to, and the model kinds, notations and modeling conventions it utilizes (
196:
There are several common mechanisms used for architecture description. These mechanisms facilitate reuse of successful styles of description so that they may be applied to many systems:
346:
captures the "conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders" (
568:
A. Jansen and J. Bosch, "Software
Architecture as a Set of Architectural Design Decisions" Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, 2005.
117:
aspects of a system. However, this rarely satisfies the stakeholders, whose concerns often include structural, behavioral, aesthetic, and other "extra-functional" concerns.
501:
P. C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting
Software Architectures: views and beyond. Addison Wesley, 2003.
467:
Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software
Engineering Notes 17 (4): 40. doi:10.1145/141874.141884
444:
to document architectural knowledge beyond the scope of individual projects (such as software product lines and product families, and reference architectures)
595:
324:
26:(also called architectural rendering), and the result of applying such practices through a work product expressing a software architecture (
350:). A framework is usually implemented in terms of one or more viewpoints or ADLs. Frameworks of interest in software architecture include:
312:
159:
Perry and Wolf identified four objectives or uses for architecture descriptions (called "architecture specifications" in their paper):
538:
F. DeRemer and H.H. Kron, "Programming-in-the-Large Versus
Programming-in-the-Small", IEEE Transactions on Software Engineering, 1976.
304:
610:
42:
333:"for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes."
89:
of the architecture such that "each addresses specific concerns of interest to different stakeholders of the system". An
76:(such as end users, system owners, software developers, system engineers, program managers) and a variety of architectural
581:
292:
60:). Architecture models can take various forms, including text, informal drawings, diagrams or other formalisms (
630:
479:
P. B. Kruchten, "The '4+1' view model of architecture," IEEE Software, vol. 12, no. 6, pp. 42–50, November 1995
387:
605:
57:
547:
M. Shaw and D. Garlan, Software
Architecture: perspectives on an emerging discipline, Prentice Hall, 1996.
176:
Following the Perry and Wolf paper, two schools of thought on software architecture description emerged:
599:
328:
98:
320:
283:
is used to refer to categories of similar views sharing a common set of elements and relations.
591:
586:
441:
to facilitate communication among system stakeholders regarding the architecture and the system
407:
in 2000 codifying best practices: supporting, but not requiring, multiple viewpoints in an AD.
343:
416:
architecture description, making explicit what was often implicit in earlier representations.
23:
557:
8:
77:
71:
65:
61:
447:
to capture reusable architectural idioms (such as architectural styles and patterns)
227:. Each view addresses a set of system concerns, following the conventions of its
141:
Perry and Wolf posited that the representation of architectures should include:
390:, this approach emphasized the varying stakeholders and concerns to be modeled.
109:
between views to share detail, to reduce redundancy and to enforce consistency.
514:
172:
conduct architecture analysis, particularly dependency and consistency analyses
145:, distinguishing three kinds of elements (and therefore three kinds of views):
624:
510:
425:
347:
300:
232:
134:, data modeling techniques (entity-relation) and object-oriented techniques.
27:
438:
to serve as a medium for analysis, evaluation or comparison of architectures
303:). Many special-purpose ADLs have been developed since the 1990s, including
556:
E. Woods and R. Hilliard, "Architecture
Description Languages in Practice"
316:
308:
224:
169:
express different aspects of the architecture each in an appropriate manner
615:
299:) is any means of expression used to describe a software architecture (
216:
404:
220:
82:(such as functionality, safety, delivery, reliability, scalability).
163:
prescribe architectural constraints without overspecifying solutions
85:
Often, the models of an architecture description are organized into
22:
is the set of practices for expressing, communicating and analysing
399:
computational components and interactions among those components".
105:
single system. Various mechanisms can be used to define and manage
64:). An architecture description will often employ several different
33:
Architecture descriptions (ADs) are also sometimes referred to as
424:
Architecture descriptions serve a variety of purposes including (
113:
process. A related misunderstanding is that ADs only address the
369:
215:
Software architecture descriptions are commonly organized into
94:
386:
Represented in
Kruchten's very influential 1995 paper on the
375:
529:
pprentice", IEEE Transactions of Software Engineering, 1986.
364:
131:
191:
410:
315:(developed by Carnegie Mellon), xADL (developed by UCI),
558:
http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
359:
263:
Concurrency/process/runtime/thread/execution viewpoint
354:
323:), DAOP-ADL (developed by University of Málaga), and
286:
155:
connecting: glue holding the other elements together;
126:
in the large) and from system design (such as SARA).
419:
70:to effectively address a variety of audiences, the
622:
372:(Reference Model of Open Distributed Processing)
219:, which are analogous to the different types of
152:data: information that is used and transformed;
16:Practices for analysing software architectures
435:to aid system planning, costing and evolution
432:to guide system construction and maintenance
337:
272:Physical/Deployment/Installation viewpoint
210:
149:processing: how the data is transformed;
192:Mechanisms for architecture description
623:
411:Architecture description via decisions
497:
495:
475:
473:
463:
461:
166:separate aesthetics from engineering
611:Software architecture documentation
44:software architecture documentation
13:
492:
470:
287:Architecture description languages
260:Developer/Implementation viewpoint
203:architecture description languages
14:
642:
582:Architecture description language
458:
420:Uses of architecture descriptions
381:
293:architecture description language
254:Component-and-connector viewpoint
238:Examples of viewpoints include:
93:is a way of looking at a system (
20:Software architecture description
393:
311:(developed by Carnegie Mellon),
143:{ elements, form and rationale }
562:
550:
541:
532:
504:
482:
275:User action/feedback viewpoint
1:
513:, R.S. Fenchel, R.R. Razouk,
451:
606:Software architectural model
58:Software architectural model
35:architecture representations
7:
575:
50:
39:architecture specifications
10:
647:
600:Concern (computer science)
248:Information/Data viewpoint
120:
338:Architecture frameworks
321:Imperial College London
211:Architecture viewpoints
206:architecture frameworks
200:architecture viewpoints
592:Separation of concerns
587:Architecture framework
344:architecture framework
257:Requirements viewpoint
91:architecture viewpoint
24:software architectures
631:Software architecture
266:Performance viewpoint
181:Multiple views school
331:can be used as ADLs
242:Functional viewpoint
186:Structuralist school
426:ISO/IEC/IEEE 42010
348:ISO/IEC/IEEE 42010
301:ISO/IEC/IEEE 42010
269:Security viewpoint
99:ISO/IEC/IEEE 42010
28:ISO/IEC/IEEE 42010
245:Logical viewpoint
223:made in building
62:modeling language
638:
569:
566:
560:
554:
548:
545:
539:
536:
530:
508:
502:
499:
490:
486:
480:
477:
468:
465:
388:"4+1 view model"
307:(SAE standard),
251:Module viewpoint
646:
645:
641:
640:
639:
637:
636:
635:
621:
620:
578:
573:
572:
567:
563:
555:
551:
546:
542:
537:
533:
509:
505:
500:
493:
487:
483:
478:
471:
466:
459:
454:
422:
413:
396:
384:
340:
289:
213:
194:
123:
107:correspondences
53:
17:
12:
11:
5:
644:
634:
633:
619:
618:
613:
608:
603:
589:
584:
577:
574:
571:
570:
561:
549:
540:
531:
503:
491:
481:
469:
456:
455:
453:
450:
449:
448:
445:
442:
439:
436:
433:
421:
418:
412:
409:
395:
392:
383:
382:Multiple Views
380:
379:
378:
373:
367:
362:
357:
339:
336:
319:(developed by
288:
285:
277:
276:
273:
270:
267:
264:
261:
258:
255:
252:
249:
246:
243:
212:
209:
208:
207:
204:
201:
193:
190:
189:
188:
183:
174:
173:
170:
167:
164:
157:
156:
153:
150:
122:
119:
87:multiple views
52:
49:
15:
9:
6:
4:
3:
2:
643:
632:
629:
628:
626:
617:
614:
612:
609:
607:
604:
601:
597:
593:
590:
588:
585:
583:
580:
579:
565:
559:
553:
544:
535:
528:
524:
520:
516:
512:
507:
498:
496:
485:
476:
474:
464:
462:
457:
446:
443:
440:
437:
434:
431:
430:
429:
427:
417:
408:
406:
400:
394:Structuralism
391:
389:
377:
374:
371:
368:
366:
363:
361:
358:
356:
353:
352:
351:
349:
345:
335:
334:
330:
326:
322:
318:
314:
310:
306:
302:
298:
294:
284:
282:
274:
271:
268:
265:
262:
259:
256:
253:
250:
247:
244:
241:
240:
239:
236:
234:
233:ISO/IEC 42010
230:
226:
222:
218:
205:
202:
199:
198:
197:
187:
184:
182:
179:
178:
177:
171:
168:
165:
162:
161:
160:
154:
151:
148:
147:
146:
144:
139:
135:
133:
127:
118:
116:
110:
108:
102:
100:
96:
92:
88:
83:
81:
80:
75:
74:
69:
68:
63:
59:
48:
46:
45:
40:
36:
31:
29:
25:
21:
596:Core concern
564:
552:
543:
534:
526:
522:
518:
506:
484:
423:
414:
401:
397:
385:
341:
332:
296:
290:
280:
278:
237:
228:
225:architecture
214:
195:
185:
180:
175:
158:
142:
140:
136:
128:
124:
114:
111:
106:
103:
90:
86:
84:
78:
73:stakeholders
72:
66:
54:
43:
38:
34:
32:
19:
18:
515:M.K. Vernon
67:model kinds
616:View model
525:chitect's
452:References
221:blueprints
115:structural
511:G. Estrin
405:IEEE 1471
279:The term
229:viewpoint
625:Category
576:See also
517:, "The
360:C4 model
281:viewtype
79:concerns
51:Concepts
121:History
521:ystem
370:RM-ODP
317:Darwin
309:Wright
95:RM ODP
489:1992.
376:TOGAF
355:Arc42
325:ByADL
217:views
598:and
313:Acme
305:AADL
132:SADT
41:or
428:):
365:4+1
342:An
329:UML
297:ADL
291:An
101:).
30:).
627::
523:AR
494:^
472:^
460:^
47:.
37:,
602:)
594:(
527:A
519:S
295:(
56:(
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.