Not Signed-In
Which clippings match 'Design Model' keyword pg.1 of 1
18 APRIL 2014

Design conceptualisation through reverse engineering abstraction

"2.1 Abstraction Levels: An abstraction for a software artifact is a succinct description that suppresses the details that are unimportant to software developer and emphasizes the information that is important. For example, the abstraction provided by high level programming language allows a programmer to construct the algorithms without having to worry about the details of hardware register allocation. Software typically consists of several layers of abstraction built on top of raw hardware; the lowest–level software abstraction is object code, or machine code. Implementation is a common terminology for the lowest level of detail in an abstraction. When abstraction is applied to computer programming, program behavior is emphasized and implementation details are suppressed. The knowledge of a software product at various levels of abstraction undoubtedly underlies operations regarding the maintenance and reuses the existing software components. It is, therefore natural that there is a steadying growing interest in reverse engineering, as a capable of extracting information and documents from a software product to present in higher levels of abstraction than that of code. The abstraction as the process of ignoring certain details in order to simplify the problem and so facilitates the specification, design and implementation of a system to proceed in step–wise fashion. In the context of software maintenance [3], four levels of reverse engineering abstraction are defined: implementation abstraction, structural abstraction, functional abstraction and domain abstraction.

Implementation abstraction is a lowest level of abstraction and at this level the abstraction of the knowledge of the language in which the system is written, the syntax and semantics of language and the hierarchy of system components (program or module tree) rather then data structures and algorithms is abstracted. Structural abstraction level is a further abstraction of system components (program or modules) to extract the program structures, how the components are related and control to each other. Functional abstraction level is a higher abstraction level, it usually achieve by further abstraction of components or sub–components (programs or modules or class) to reveal the relations and logic, which perform certain tasks. Domain Abstraction further abstracts the functions by replacing its algorithmic nature with concepts and specific to the application domain."

(Nadim Asif, 2003)

Nadim Asif (2003). "Reverse Engineering Methodology to Recover the Design Artifacts: A Case Study". International Conference on Software Engineering Research and Practice, SERP '03 Las Vegas, Nevada, USA. Volume 2.

TAGS

2003abstract representation • abstraction layers • abstractions for problem solving • application domain • appropriately complex representation • conceptual hierarchy • conceptual organisation • conceptualisationdesign abstractiondesign conceptualisationdesign methodologydesign modeldesign problem • domain abstraction • functional abstractionhigh-level design • implementation abstraction • layers of abstraction • problem abstractionproblem-solvingrequirements engineeringreverse engineeringreverse engineering abstraction • Reverse Engineering Abstraction Methodology (REAM) • software abstraction • software artefact • software designsoftware engineeringsoftware modellingstructural abstraction • system components • system processes • systems theory

CONTRIBUTOR

Simon Perkins
18 NOVEMBER 2013

Affordance, Conventions and Design

"Physical constraints are closely related to real affordances: For example, it is not possible to move the cursor outside the screen: this is a physical constraint. Locking the mouse button when clicking is not desired would be a physical constraint. Restricting the cursor to exist only in screen locations where its position is meaningful is a physical constraint.

Logical constraints use reasoning to determine the alternatives. Thus, if we ask the user to click on five locations and only four are immediately visible, the person knows, logically, that there is one location off the screen. Logical constraints are valuable in guiding behavior. It is how the user knows to scroll down and see the rest of the page. It is how users know when they have finished a task. By making the fundamental design model visible, users can readily (logically) deduce what actions are required. Logical constraints go hand–in–hand with a good conceptual model.

Cultural constraints are conventions shared by a cultural group. The fact that the graphic on the right–hand side of a display is a 'scroll bar' and that one should move the cursor to it, hold down a mouse button, and 'drag' it downward in order to see objects located below the current visible set (thus causing the image itself to appear to move upwards) is a cultural, learned convention. The choice of action is arbitrary: there is nothing inherent in the devices or design that requires the system to act in this way. The word 'arbitrary' does not mean that any random depiction would do equally well: the current choice is an intelligent fit to human cognition, but there are alternative methods that work equally well.

A convention is a constraint in that it prohibits some activities and encourages others. Physical constraints make some actions impossible: there is no way to ignore them. Logical and cultural constraints are weaker in the sense that they can be violated or ignored, but they act as valuable aids to navigating the unknowns and complexities of everyday life. As a result, they are powerful tools for the designer. A convention is a cultural constraint, one that has evolved over time. Conventions are not arbitrary: they evolve, they require a community of practice. They are slow to be adopted, and once adopted, slow to go away. So although the word implies voluntary choice, the reality is that they are real constraints upon our behavior. Use them with respect. Violate them only with great risk."

(Donald Norman)

1

TAGS

affordancesconceptual modelconstraintsconventionscultural concept of technology • cultural constraints • cultural conventions • cultural group • design modelDonald Norman • guiding behaviour • human behaviourlearned behaviour • learned convention • logical constraints • perceived affordance • physical constraint • physical constraints • real affordancesreasoningshared practices • voluntary choice
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.