Use Case Maps as Architectural Entities for Complex Systems R.J.A. Buhr Department of Systems and Computer Engineering, Carleton University, Ottawa, Canada. buhr@sce.carleton.ca ABSTRACT . This paper presents a novel, sce- network gateways, and web servers, to name but a few nario-based notation called Use Case Maps (UCMs) for possibilities. To avoid confusion, note that the use of the describing, in a high-level way, how the organizational term component here is both more and less restrictive structure of a complex system and the emergent behav- than the use of this term in an important software nota- ior of the system are intertwined. The notation is not a tional standard, UML [31]: It is more restrictive because behavior specification technique in the ordinary sense, it refers only to runtime entities of systems; it is less but a notation for helping a person to visualize, think restrictive because it does not apply only to software. A about, and explain the big picture. UCMs are presented different term would avoid confusion but the term is so as “architectural entities” that help a person stand back appropriate that it seems artificial to look for another. from the details during all phases of system develop- Systems have large scale units of emergent behav- ment. The notation has been thoroughly exercised on ior cutting across them, such as network transactions, systems of industrial scale and complexity and the dis- that are part of the way we think about systems but that tilled essence of what has been found to work in practice tend to be hard to see as coherent entities in the detailed is summarized in this paper. Examples are presented terms in which they emerge at runtime. Another side of that confront difficult complex-system issues directly: this coin is difficulty seeing how such entities arise from decentralized control, concurrency, failure, diversity, the collective efforts of components. elusiveness and fluidity of runtime views of software, The focus on behavior implies, for the software self modification of system makeup, difficulty of seeing parts of systems, that we shall be concerned with the large-scale units of emergent behavior cutting across runtime picture not the organization of source code. The systems as coherent entities (and of seeing how such runtime picture of software is often characterized by a entities arise from the collective efforts of components), certain elusiveness and fluidity, viewed from the per- and large scale. spective of a programming language. Elusiveness results from the fact that many types of runtime components 1 Introduction may not be explicitly identified as such in the program- ming language (e.g., processes supported by separate This paper presents a scenario-based notation for operating systems, components defined by grouping describing, in a high-level way, how the organizational source code elements into a file, container objects iden- structure of a complex system and the emergent behav- tified as such by the fact that they store identifiers for ior of the system are intertwined. The notation is not a objects of other classes). Fluidity results from the fact behavior specification technique in the ordinary sense, that practical software systems may be self-modifying but a notation for helping a person to visualize , think as they run, meaning they dynamically change their about, and explain the overall behavior of a complex makeup as a routine part of normal operation (e.g., system. The focus is on the big picture, not on details. objects, processes, and threads are created and To be practically useful for this purpose, the notation destroyed; visibility relations among them are changed; must be capable of dealing with the following complex- intercomponent protocols are changed; applets are ity factors in an integrated and manageable way. moved from one network node to another; network The behavior of the kind of system that interests transactions take different forms under different system us emerges from the self-coordinated individual efforts conditions). of semi-independent components, which operate (often This mix of complexity factors presents a strong concurrently) without the explicit help of any central challenge to notations, with respect to showing the kind algorithm or plan. The components must cope with the of big picture we seek. Notations may have two prob- possibility of failures of both other components and lems in this respect: 1) System-representation notations intercomponent communication. The components may that require commitment to a lot of detail will produce be software or hardware, may be distributed in a net- descriptions that hide the big picture we seek behind work, and may be quite diverse, such as objects, pro- clouds of details as the scale of the system increases. cesses, threads, interrupt service routines, monitors, The current generation of software design notations, modules, packages, communication chips, workstations, exemplified by UML, tends to have this problem. August 31, 1998/1
Recommend
More recommend
