Level of abstraction

Knowledge obtaining knowledge needs some level of abstraction. Many pieces of information are ordered in the framework of a model rules are derived from a sequence of observations predictions can be made by analogy. 

The observation that certain kinds of parallel-computing architectures best support only certain kinds of problems seems to be general. The further observation that interprocessor communication can be the primary impediment to parallel performance is also general. As of this writing, any hope of a truly general purpose parallel computer seems to be remote. The best hope may He in software efforts that describe problems at higher levels of abstraction, which can then be ported and optimized for different parallel architectures (22). 

Reverse engineering The process of analysing an existing system to identify its components and their interrelationships and create representations of the system in another form or at a higher level of abstraction . 

Operators, describing process operations, can be declared at any level of abstraction, but they should maintain consistent relations with each other, since they refer to the same process. For example, the top-level operator, (START UP PLANT), could be refined to the following sequence of operators (see also Fig. 5) (START UP RECOVERY), (START,UP REFINING), (START.UP FEED PREPARATION), and (START. UP. REACTION). Clearly, the preconditions of (START.UP.PLANT) are distributed and represent a subset of the preconditions for all four more detailed operations. Similarly, the postconditions, derived from the startup operation of the four sections, should be... 

To achieve these consistencies, MODEL.LA. provides a series of semantic relationships among its modeling elements, which are defined at different levels of abstraction. For example, the semantic relationship (see 21 1), is-disaggregated-in, triggers the generation of a series of relationships between the abstract entity (e.g., overall plant) and the entities (e.g., process sections) that it was decomposed to. The relationships establish the requisite consistency in the (1) topological structure and (2) the state (variables, terms, constraints) of the systems. For more detailed discussion on how MODEL.LA. maintains consistency among the various hierarchical descriptions of a plant, the reader should consult 21 1. 

User-specified, temporal ordering of operational goals at higher levels of abstraction is propagated downwards in the hierarchy goals and is ultimately expressed as temporal ordering of primitive operations (see Section III,B). 

Object-oriented descriptions of the Power-Forming-Plant at two levels of abstraction (a) in terms of processing units, and (c) in terms of processing sections. The descriptions of a proce.ssing unit (b) and a processing section (c). 

Stratification of operational tasks, shown in Fig. 2 (Stephanopoulos, 1990). At the lowest level of abstraction, process data at a scale of seconds or minute are used to carry out a variety of numerical and logical tasks. 

At the next level of abstraction are measurements performed at a thin film of fuel cell catalyst immobilized on the surface of an inert substrate, such as glassy carbon (GC) or gold (Fig. 15.2c). Essentially, three versions of this approach have been described in the fiterature. In the first case (a porous electrode ), an ink containing catalyst and Nafion ionomer is spread onto an inert nonporous substrate [Gloaguen et al., 1994 Gamez et al., 1996 Kabbabi et al., 1994]. In the second case (a thin-fihn electrode ), the ink does not contain Nafion , but the latter is... 

Figure 1.4 Level of abstraction of analytical tools on additives in polymers with delimitations adopted in the text (shaded)...

To tackle these problems successfully, new concepts will be required for developing systematic modeling techniques that can describe parts of the chemical supply chain at different levels of abstraction. A specific example is the integration of molecular thermodynamics in process simulation computations. This would fulfill the objective of predicting the properties of new chemical products when designing a new manufacturing plant. However, such computations remain unachievable at the present time and probably will remain so for the next decade. The challenge is how to abstract the details and description of a complex system into a reduced dimensional space. 

A collaboration abstracts object compositions. An object that is treated as a single entity at one level of abstraction may actually be composed of many entities. In doing the refinement, all participants need to know which constituent of their interlocutor they must deal with. For example, in the abstract you might say, I got some cash from the bank, but actually you got it from one of the bank s cash machines. Or in more detail, you inserted your card into the card reader of the cash machine. 

Part of the art of good documentation is to achieve a consistent level of abstraction What should be left in, and what deferred What tools can we use to leave things out Here are some tips. 

Therefore, invariants should always be quoted as part of a given type or collaboration. Before doing anything to correlate one level of abstraction with another, absorb the invariants into the pre- and postconditions. 

We prefer our state charts like this, because they are easier to reconcile with the actuality of the software compared with instantaneous event models and they tie in better with the actions. In some notations, they would have an event representing the start of an action and another for the end of it, and a state in between representing the transitional period. But at a given level of abstraction, we do not know enough to characterize the intermediate state, because that is defined only in the more-detailed layers of the model. 

Of course, when specifying an abstract action you should describe only those exceptions that have meaning at that level of abstraction, not every disk or networking failure ... 

Let s not forget that components and connectors (see Chapter 10) provide yet another level of abstraction in building and plugging together components. Different, possibly customized, forms of connectors can make it much simpler to describe and implement the component configurations you need. 

Catalysis models have clear semantic relationships to one another. At any level of abstraction, they form an important part of the inspection criteria for those models. Across levels of refinement, these rules, together with the rules for refinement, provide a concrete basis for design reviews. 

Refinement Different levels of abstraction are supported by refinement. Giving an overall view helps everyone gain a better understanding of the problem. Sometimes the abstraction is written before the detail. In other cases, an abstraction is made after an initially detailed view—for example, to clarify issues after interviewing end users or to revise an external specification after a cycle of prototyping. 

It may be useful to reiterate this to several levels of abstraction. Each abstraction generally represents a goal or goals of a part of the process or organization. 

Determine a consistent level of abstraction in relation to actions Are you going to worry about individual keystrokes or talk only about broad transactions The highest-level action that could be useful should accomplish a business task or objective or should abstract a group of such actions. The lowest-level action that could be useful should constitute an indivisible interaction if the interaction fails to complete successfully or otherwise is aborted, there should be no effect that would be useful at the business level. 

Summarise the interactions with the system as collaborations between the system being specified and other objects, building scenarios to validate the collaboration, and modeling actions at a consistent level of abstraction. Show all external roles as types — also called actors — that participate in these actions. Also, document those actions that can proceed concurrently on a single system, including constraints on concurrency. For example ... 

Individual user interface windows and the flow between them can be captured as a storyboard. Each window is often associated with a particular task, at some level of abstraction a flow sequence will refine a more abstract use case. Once again, users should be very actively involved in the actual design of the interface, even if that means teaching them a bit about what is achievable with the target system. 

We are uncomfortable with the treatment of use cases as objects and have found much confusion among practitioners about what this means. Just because there are commonality and variation across use cases does not mean that they should be modeled as objects to do so confuses the separation of actions (interactions that cause changes of state) and attributes (the states that affect, and are affected by, actions). In Catalysis, what is modeled as an action at one level of abstraction (for example, buy product) can easily be reified into a model object in a refinement (for example, place order and deliver and pay actions revolving around an order model object). 

At the highest level of abstraction, hydrogen fuel is one of the options being considered in the World s quest for sustainable mobility. This, as discussed for instance in a recent report of the World Business Council for Sustainable Development, is a multifaceted subject, encompassing everything from future fuels to future vehicle technology and transportation infrastructure, in all of which major strides forward are needed [1], In what follows we restrict ourselves to fuels. But the fact that a sustainable fuel is just an element of the complex issue of sustainable mobility makes clear that such a fuel must meet a complex and sometimes contradictory set of demands. The following three requirements stand out a sustainable fuel should, in a cost effective way, contribute to... 

Finally, this was a school that defined theoretical chemistry as a kind of chemistry (and a kind of science) that aimed at abstract knowledge in the purest sense. This science could not yet achieve the level of abstraction, or the level of prestige, of mathematics, but it was more free than other kinds of chemistry from practical ends and applications. 

Arthur D. Little has carried out cost structure studies for a variety of fuel cell technologies for a wide range of applications, including SOFC tubular, planar and PEM technologies. Because phenomena at many levels of abstraction have a significant impact on performance and cost, they have developed a multi-level system performance and cost modeling approach (see Figure 1-15). At the most elementary level, it includes fundamental chemical reachon/reactor models for the fuel processor and fuel cell as one-dimensional systems. 

Most branches of theoretical science can be expounded at various levels of abstraction. The most elegant and formal approach to thermodynamics, that of Caratheodory [1], depends on a familiarity with a special type of differential equation (Pfaff equation) with which the usual student of chemistry is unacquainted. However, an introductory presentation of thermodynamics follows best along historical lines of development, for which only the elementary principles of calculus are necessary. We follow this approach here. Nevertheless, we also discuss exact differentials and Euler s theorem, because many concepts and derivations can be presented in a more satisfying and precise manner with their use. 

This becomes particularly clear to the student of Quantum Mechanics. His previous experience was probably that functions specified an action on some specified number to produce another number. This notion was quickly replaced by regarding (wave-)functions as objects, to be acted upon by operators to produce other functions. After a while it becomes clear that it is often much more profitable to regard the operators as objects, to be combined by composition and commutation rules and perhaps mapped onto each other by functions. Any of these levels of abstraction can be found also in computer programs. 

The Layered Architectural Pattern This helps to structure applications that can be decomposed into groups of subtasks, in which each group of subtasks is at a particular level of abstraction. 

These conceptual objects are not necessarily software objects that will be in the design model, although many of them may become software objects in the design model. Usually the design model has more objects than in the analysis model when software design principles are applied to introduce more levels of abstractions and in-directions. 

---