Viewcharts(ID:7785/)Extension of statecharts to deal with complex and large systems Related languages
References: Introduction Large-scale real-time distributed systems can be complex to describe, construct, manage, understand, and maintain. Current research approaches to reducing this complexity separate software structural and behavioral descriptions. It is, therefore, important to identify and formally describe software behavioral views and structural patterns; these patterns and/or views, then, can be used in software systems analysis, specification, design, and configuration. Much research has been done on software structures and their patterns, characterizations, and classifications. Little or no attention, however, has been given to the identification and analysis of software behavioral views that can be used as a basis for software behavioral requirements engineering. This paper introduces a notation, called Viewcharts, which is based on David Harel?s Statecharts [7]. The Viewcharts notation extends Statecharts to include behavioral views and their compositions, limits the scope of broadcast communications, and consequently, reduces the complexity of scale that Statecharts faces in behavioral specifications of large systems. In the literature, the term behavioral view (in contrast to structural or functional views) generally refers to the behavioral aspect of a system. In this paper, however, we talk about different behavioral views of the same system. See Section 2 for our definition of the term. The Viewcharts formalism can be viewed as a high-level specification language that uses Statecharts; and Statecharts is designed for real-time event-driven reactive systems. Furthermore, Viewcharts extends Statecharts to include behavioral views and their composition; consequently, it describes ehavioral requirements of large-scale complex systems as ompositions of views. The domain of the Viewcharts formalism, herefore, is behavioral specification of large-scale omplex real-time event-driven reactive systems. Extract: Viewcharts Viewcharts A behavioral view of a software system is the behavior of the system observable from a specific point of view. A client?s view of a server, for example, is the behavior that the client expects from the server. This behavior, of course, may differ from the behavior that the server exhibits to another client. A server, therefore, may have several behavioral views. The caller view of a telephone set and the telephone set?s view of a switching system are also examples of behavioral views. The Viewcharts notation is based on Statecharts. Statecharts, however, has no concept of behavioral views. Viewcharts extends Statecharts to include views and their com- positions. is covered by the scope of the event. Statecharts is often criticized for not being practical for large-scale systems specifications. Specifically, the issue of scale in Statecharts leads to the following problems: An event may have multiple owners; in other words an event can be triggered by more than one view. An event may also have no owner, in which case the event can neveroccur. The Viewcharts notation allows this case, because of the possibility of further composition of the viewchart with additional views, which may affect the event. This is exactly analogous to the notion of free variables in program fragments, which can be be bound in a larger context. 1.Explosion of States: In conventional finite state machines the number of states grows exponentially as the scale of the system grows linearly. Statecharts reduces this blow-up, but for a large-scale system this is still a problem. 2. Global Name Space: All names in Statecharts are defined globally. A given event, for example, can be sensed throughout the system and, therefore, it must have a unique name. Managing the name space is difficult in large-scale systems. Viewcharts attempts to eliminate these problems. A viewchart consists of a hierarchical composition of views. The leaves of the hierarchy, described by independent statecharts, represent the behavioral views of the system or its components. The higher levels of the hierarchy are composed of the lower level views. Views are represented just like states, except that the arc-boxes representing views have thicker borders than those of states. Extract: Conclusion A large-scale software system may exhibit a combination of many different and identical behavioral views. The Viewcharts notation allows these views to be specified as stand-alone systems and provides a method of composing them to form the overall system behavior specification. It is important, however, to realize that composing behavioral views is different from integrating them. In a composition of views, the views keep their identities and are used as building blocks of the requirements specification; each requirement can be traced back to its originating view. In an integration of views, on the other hand, the views may lose their identities and be replaced by different mechanisms; the requirements cannot necessarily be traced back to their originating views. Integration requires making design decisions, while composition does not. Viewcharts leaves the integration of views to designers and implementers. Furthermore, a statechart describing a view, in a viewchart, describes only a behavioral view of the system or, more importantly, its component. In other words, the number of states and the size of such a statechart are affected only by the scale of the behavioral view. Consequently, considering that a large-scale system behavior can be described in terms of simple behavioral views, Viewcharts simplifies the specification and reduces the complexity of scale that the underlying Statecharts notation faces in behavioral specifications of large systems Others have also used the term ?view?, but not exactly for the same concept as we have. Embley and others [5], for example, introduce their notion of view, which is an abstraction mechanism for reducing complexity in large Object- Oriented Systems Analysis (OSA) models. Their notion of a view, however, is a grouping of some entities in the OSA models; it reduces the complexity of understanding a complex OSA model and communicating about it, but does not affect the complexity of specifying or building the model. Goldberg [6], Ayers [l], and Rumbaugh [17], also describe the notion of view &thin the Model-View-Controller (MVC) paradigm of Smalltalk community. A view, in MVC, refers to the method of presenting the information contained in the underlying model of an application. In regard to reducing the complexity of describing the model they neither make any claim nor offer any mechanism. |