China
Africa
Explore chapters and articles related to this topic
The Programming Aspect of Simulation
Published in William Delaney, Erminia Vaccari, Dynamic Models and Discrete Event Simulation, 2020
William Delaney, Erminia Vaccari
The design criteria listed in the preceding subsection leave a great deal of freedom for choosing just how to subdivide a module. “Information hiding” is a method that enforces these criteria; it enhances submodule independence and facilitates program modification. Its basic idea is to foresee modules that contain all the information relative to some program aspect (such as exactly how a certain abstract data type is defined in terms of more elementary ones); in particular, the module’s interface toward other modules evidences the minimum information necessary for correct communication. In this way modifications to the module’s inner workings do not propagate to other modules, which in no way depend on them.
Flow—Applying Industrial Insights to Software Production
Published in Peter Middleton, James Sutton, Lean Software Strategies, 2020
The Parnas criteria are based on Dr. Parnas’ principle of information hiding. Information hiding is the concealment of any information about what a software module does, that the users of the module (e.g., other modules that call it) don’t need to know about in order to use it. This concept may sound familiar: The literature of object orientation sometimes uses the phrase “information hiding.” But, as Dr. Parnas points out in his comments on object orientation, which we quoted in Chapter 10, few object-oriented projects ever actually use information hiding. There is still much untapped potential in the principle and much unrealized power in the Parnas criteria.
Agents, Objects, and Frames
Published in Adrian A. Hopgood, Intelligent Systems for Engineers and Scientists, 2021
Encapsulation, or information-hiding, is a term used to express the notion that the instance attributes and the methods that define an object belong to that object and to no other. The methods and attributes are therefore private and are said to be encapsulated within the object. The interface to each object reveals as little as possible of the inner workings of the object. The object has control over its own data, and those data cannot be directly altered by other objects. Class attributes are an exception, as they are not encapsulated within any one instance but are shared between all instances of the same class.
Digital-enabled Design for Manufacture and Assembly (DfMA) in offsite construction: A modularity perspective for the product and process integration
Published in Architectural Engineering and Design Management, 2023
Tan Tan, Grant Mills, Eleni Papadonikolaki, Baofeng Li, Jing Huang
Modularity, as a complexity-reduction strategy (Baldwin et al., 2000), has the potential to empower OSC techniques and impact various facets of DfMA. Baldwin and Clark (2006) indicated three purposes of modularisation in design: (1) to make complexity manageable; (2) to enable parallel work; and (3) to accommodate future uncertainty. In addition, modularity emphasises the interdependence within and independence across modules. Baldwin et al. (2000) captured the essence of modularity from three ideas: (1) abstraction; (2) information hiding; and (3) interface. The abstraction means to hide the elements’ complexity (Baldwin et al., 2000). Abstraction is usually used as a complexity mastering strategy by keeping essential features of an object without including background or inessential detail (Graham, 1994). Parnas (1972) introduced information hiding to devise modular structures in software design. This term is also applied to complex systems (Baldwin et al., 2000). Information hiding refers to the fact that all information about a module (including data and functionality) is encapsulated and hidden from other modules unless specifically declared public (Graham, 1994). Interface is a shared linkage between components (e.g. people, information) for open interchanges and a rule to control the flow of information (Voss and Hsuan, 2009). In essence, interface as part of the public information set is a pre-established way to resolve potential conflicts between the interactive parts of the design.
Mirror-breaking strategies to enable digital manufacturing in Silicon Valley construction firms: a comparative case study
Published in Construction Management and Economics, 2020
Daniel M. Hall, Jennifer K. Whyte, Jerker Lessing
If systemic innovation can be inhibited by industry structure, rational firms within construction should seek opportunities to restructure the industry and capturing value from systemic innovations. Why has this not happened to a greater degree? One emerging theory is the “mirroring trap” (Colfer and Baldwin 2016). We suggest that the institutionalization of the current industry structure (Henisz et al.2012) has deterred systemic innovation attempts and standardized the range of components that can fit within the dominant systems-level architecture. Individuals and firms are incentivized to focus on specialty knowledge aligned with their specific tasks in the fragmented construction supply chain. Given the challenges of coordinating complex interdependent tasks (Thompson 1967, Galbraith, 1974), the “mirroring” of technical dependencies and organizational ties is an organizational solution that allows firms to conserve scarce cognitive resources (Colfer and Baldwin 2016). The concept of information hiding is used to control complexity. Each module in a technical system is informationally isolated from other modules within a framework of system design rules (Baldwin and Clark 2000) so that “independent individuals, teams, or firms can work separately on different modules, yet the modules will work together as a whole” (Colfer and Baldwin 2016). Furthermore, mirroring is an economical way to set up complex technical systems because it places problem-solving resources in strategic places where these problems are likely to appear (Colfer and Baldwin 2016).
Semantic typing of linked geoprocessing workflows
Published in International Journal of Digital Earth, 2018
Simon Scheider, Andrea Ballatore
Data types generally increase the transparency and clarity of a program, helping developers express expected inputs and outputs of computational resources, for example specifying whether a function input is a string, an integer, a raster dataset, or another function. The success of types in object-oriented programming lies in information hiding, which is a way of abstracting from implementation details (Guttag and Horning 1978). More specifically, type constraints allow for modularity, that is, they guide the choice of a function, and open slots can be filled with particular data of a corresponding type to obtain a desired result. A second advantage is constructivity, the ability to construct a variety of types by combining primitive ones. And a third advantage is type inference, that is, the possibility to use inference rules to automatically guess the types of output and input when applying an operation. In practice, this greatly reduces a programmer's efforts of documenting code.