Not Signed-In
Which clippings match 'Software Modelling' keyword pg.1 of 1
23 OCTOBER 2014

Describing social and material interactions through formal methods

"To some extent, Formal Methods sit uneasily within interaction design. Human beings are rich, complex, nuanced, engaged in subtle and skilful social and material interactions; reducing this to any sort of formal description seems at best simplistic. And yet that is precisely what we have to do once we create any sort of digital system: whether an iPhone or an elevator, Angry Birds or Facebook, software is embedded in our lives. However much we design devices and products to meet users' needs or enrich their experiences of life, still the software inside is driven by the soulless, precise, and largely deterministic logic of code. If you work with computers, you necessarily work with formalism.

Formal Methods sit in this difficult nexus between logic and life, precision and passion, both highlighting the contradictions inherent in interaction design and offering tools and techniques to help understand and resolve them.

In fact, anyone engaged in interaction design is likely to have used some kind of formal representation, most commonly some sort of arrow and sketch diagram showing screens/pages in an application and the movements between them. While there are many more complex formal notations and methods, these simple networks of screens and links demonstrate the essence of a formal representation. Always, some things are reduced or ignored (the precise contents of screens), whilst others are captured more faithfully (the pattern of links between them). This enables us to focus on certain aspects and understand or analyse those aspects using the representation itself (for example notice that there are some very long interaction paths to quite critical screens)."

(Alan J. Dix, 2013)

Dix, Alan J. (2013): Formal Methods. In: Soegaard, Mads and Dam, Rikke Friis (eds.). "The Encyclopedia of Human–Computer Interaction, 2nd Ed.". Aarhus, Denmark: The Interaction Design Foundation. Available online at https://www.interaction–design.org/encyclopedia/formal_methods.html

TAGS

abstract system models • Alan Dix • arrow and sketch diagram • context awareness • context-aware interfaces • design methods • design products • deterministic logic • dialogue models • digital devices • digital interactions • digital system • executable models • formal abstraction • formal analysis • formal description • formal design methods • formal methods • formal notation • formal representations • formalised principleshuman-computer interactioninteraction designInteraction Design Foundation • material interactions • notation • physical context • physical interactionphysigrams • product design process • product development methodologyrepresentationrich descriptionsrich user experienceshaping our relationship to the material worldsocial interactionssoftware modellingspace syntax • specification language • state machines • state transition network • structured approach • system behaviour • tangible interfacestechnology affordancesusability testinguser experienceuser-based evaluationworld around us • world representations

CONTRIBUTOR

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.

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
21 FEBRUARY 2014

Video Tutorial of OOP Design Patterns

Fig.1 Java Video Tutorial by Derek Banas, 19 August 2012.

1

TAGS

data abstraction • Derek Banas • design patterns • encapsulation • inheritanceJavamodelling language • object class • object-oriented designOOP • OOP concepts • OOP design principles • programming fundamentals • requirements engineeringsoftware code • software design principles • software design problems • software developmentsoftware engineeringsoftware modellingsoftware programmingsoftware requirementssoftware tutorial • subclass • superclass • UML • UML diagram • Unified Modelling Languagevideo tutorial

CONTRIBUTOR

Simon Perkins
17 DECEMBER 2012

Jim Conallen: iterative web application design and development

"If you are looking for a cookie–cutter recipe to success, forget it. Developing applications is hard work and relies heavily on the skill and the ability of everyone involved. Even so, a strong process is important. Heroic efforts on the part of a development team can often bring a project to maturity; however, heroic efforts and strong process can do so repeatedly and reliably."

(Jim Conallen, 2002)

Jim Conallen (2002). "Building Web Applications with UML", (Addison–Wesley Object–Technology Series).

1

TAGS

2002 • application design • application developmentconceptual model • cookie-cutter • development life cyclediagramiterative design processiterative developmentiterative process • Jim Conallen • methods for design practicemodelling language • page based web applications • page-based web applications • Philippe Kruchten • requirements gathering • SDLC • software design • Software Development Life Cycle • software modellingUMLUnified Modelling Languageweb applicationweb application designweb application development

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.