-
Join 34 other subscribers
Modelling:
- Applications (relevance) (50)
- Abstract Thinking (11)
- Software_Engineering (40)
- Foundations (rigour) (42)
- Epistemology (20)
- Mathematics (19)
- Series (42)
- Herbert Stachowiak (6)
- Model Thinking (8)
- Reflections on Abstractions (14)
- Requirements (16)
- Uncategorized (3)
- Applications (relevance) (50)
Twitter
- RT @EgbertRijke: The univalent hydrocarbons are premiering today at the Category Theory Octoberfest richardblute.ca/octoberfest-20… Time: 15:45 U… - 4 months ago
Tag Archives: software engineering
Computational Artefacts and Software Requirements
What if the intention of a technical artefact is not at all physical, but solely logical? Continue reading
Posted in Epistemology, Requirements
Tagged analysis, computational artefact, computer science, design, Elements of Software RequirementsEngineering, engineering, epistemology, mind-body problem, Peter Kroes, Raymond Turner, Requirements, Requirements Engineering, software, software engineering, specification, Technical Artefact
5 Comments
Separation of Analysis & Design wrt. Abstraction
Summing up separation of concerns of analysis and design wrt. abstraction, inspired by: Turner (2018) Computational Artifacts. Continue reading
A New Account of Abstraction?
Software engineering could benefit from a more rigorous grounding in epistemology, e.g., for the account of abstraction. So, let’s see what we can learn from: Raymond Turner (2018) Computational Artifacts Continue reading
Posted in Epistemology
Tagged abstraction, Bernhard Ganter, Bob Hale, computational artifact, concept analysis, Crispin Wright, David Lewis, epistemology, epistemology of engineering, formal concept analysis, Gideon Rosen, John Burgess, Raymond Turner, software engineering, technical artifact, Turner
1 Comment
Technical Artefacts and Software Requirements
The epistemic concept of “Technical Artefact” may prove useful for studying requirements engineering. It brings together the notions of the world as physical objects with the world of intentionally acting agents. Continue reading
Posted in Epistemology, Requirements, Software_Engineering
Tagged computer science, Elements of Software RequirementsEngineering, engineering, epistemology, Herbert Simon, mind-body problem, Nicola Angius, Peter Kroes, Raymond Turner, Requirements, Requirements Engineering, software, software engineering, specification, Technical Artefact, Teleology
4 Comments
Software for Managing Chaos
Workers in highly volatile contexts are best supported by software that implements generic communication or selfmanagement functionality. Like ACM systems do. Continue reading
Posted in Software_Engineering
Tagged ACM, BPM, Case Management, chaos, chaotic, cynefin, cynefin framework, dave snowden, decision making, Deputy Chief Walter Gasior, informatics, information system, knowledge management, Mary Boone, Process Management, sense-making, software development, software engineering, software requirements
Leave a comment
1 + x = 3 as a Query
Strongly reduced recap of basic software engineering concepts: Query, Result Set, Requirement. Continue reading
What kind of Computer Science matters?
Just came across Why Computer Science Matters? by Vugranam Sreedhar. He observes a decline in real computer scientists in favour of ‘commodity programmers’. Basically, I have to (sad but true) agree here, and would like to take a closer look … Continue reading
Modelling with Classes: Square and Rectangle revisited
Classic problem in class-modelling: how to express that a square is a special kind of rectangle? In order to deepen understanding, let us scrutinize the situation a bit closer here, using logical/ structural foundations of modelling: Continue reading
Craftsman or Engineer?
A lot has been written on the differences between Craftsman and Engineer. Recently I came across a simple example by Hofstadter & Sander, that nicely shows the basic difference in thinking: Continue reading
Posted in Abstract Thinking, Software_Engineering
Tagged abstraction, analogy, craft, craftsman, craftsmanship, Douglas Hofstadter, Emmanuel Sander, engineer, engineering, Hofstadter, marking, model, Modelling, parallelogram, rectangle, rhombus, software engineering, square, surfaces and essences
4 Comments
Abstraction makes the Engineer
From my own experience I may say, what separates the engineer from the craftsman is clearly the ability to abstract. Continue reading
Posted in Abstract Thinking, Software_Engineering
Tagged abstraction, analogy, Douglas Hofstadter, education, Emmanuel Sander, engineer, engineering, Hofstadter, marking, model, Modelling, parallelogram, rectangle, rhombus, software engineering, square, surfaces and essences, thinking
Leave a comment
modelpractice 