Not Signed-In
Which clippings match 'Design Problem' keyword pg.1 of 1
19 DECEMBER 2015

A History of the Studio-based Learning Model

"Studio-based instruction and learning has become a hot topic in K-12 education today. Knowing the origins of studio-based learning in education, as well as in art and architectural education can provide us with a deeper understanding of the purposes and goals of studio-based methods. Much can be gained by educators to the turn of the century for guidance in translating the new popular studio-based learning model developed in architectural education."

(Jeffery A. Lackney, 2 August 1999)





19th century20th centuryactive learning • aesthetic training • apprentice system • architectural education • art and architectural education • art and design educationatelier modelBauhaus School • charrette • child-centred approach • Columbia University • David Hoff • design problemdesign studio education • design studio model • Donald Schon • Ecole des Beaux Arts • Ernest Boyer • Francis Parker • Friedrich Frobel • history of ideas and learning • Horace Mann • Horace Mann High School • Indiana • integrated curriculum • Jeffery Lackney • John DeweyK-12 • Laboratory School in Chicago • learner-centredlearning by doing • Lee Mitgang • Massachusetts • mastery • Mississippi State University • Parker School in Quincy • pedagogical model • platoon system • Quincy System • studio approach • studio-based instruction • studio-based learning • studio-based learning model • studio-based methods • studio-based model of learning • University of Oregon • William Wirt


Simon Perkins
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.


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


Simon Perkins
21 JULY 2012

Reflection-in-action: framing, naming, moving and reflecting

"Reflection–in–action proceeds by a construction cycle of framing, naming, moving and reflecting. Framing and naming concern the problem–setting in that the designer constructs a problem out of a situation by naming the things to which she will pay attention whilst at the same time framing the way that the problem is viewed (Schön 1991). Framing in this sense imposes an order onto the problem; moves are made towards a solution in relation to how the situation is framed. However, the situation 'talks back'; surprise at the outcomes of moves leads to reflecting. Reflecting on outcomes may trigger either further moves or a new framing (Schön 1996). Reflection–inaction is not an interruption to fluid action; it is always embedded within action."

(Simone Stumpf and Janet McDonnell, CiteSeerX)

1). Simone Stumpf and Janet McDonnell, "Individual Learning Styles and Perceptions of Experiential Learning in Design Teams"


CiteSeerX • conceptualisation cycle • construction cycle • cycle of learningdesign educationdesign problemdesign solutiondesign teamsDonald Schonexperiential learningframingindividual learning styles • Janet McDonnell • knowledge cycle • learning styles • moving and reflecting • naming • naming activities • naming processpedagogy • Pennsylvania State University • problem-setting • reflecting • reflectionreflection-in-action • Simone Stumpf • talk back


Simon Perkins

to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.