Workshop on MDSD and DSL Contest
Posted in: Abstraction Modeling
Wednesday, June 18th, 2008, ICT NoviQ organises a workshop around the topic “Model Driven Software Development” (MDSD). This workshop is associated with a contest, in which also non-participants can compete for a price for the best design of a domain-specific language (DSL) for an example case. All are kindly invited to participate in the workshop and/or the contest. For more information about the workshop and the contest see http://www.ictnoviq.nl.
Posted May 30, 02:36 PM by Angelo · Comment
Defining a language
Posted in: Modeling Abstraction
Martijn ‘s latest entry touches upon a really big issue. For most software developers it’s very hard to grasp the real problem domain of the customer or end user. This has been an issue in requirements engineering and architecture for years already.
When defining a DSM Language, this problem is close to deadly – stuck in the world of solutions, people tend to define their language in that domain. As a result, a lot of detailed properties and relations are defined, and the relation between code and language gets close to 1-on-1.
I’m currently thinking up an example case that I can use to put together a short web tutorial here – or even better, a blog workshop on DSM Language definition similar to the one Dratz is running on abstraction architectures.
Keep an eye out, it will be here soon!
Posted Oct 19, 08:26 AM by Angelo ·
Abstraction revisited - abstraction requires understanding of the details
Posted in: Abstraction
Our company, or at least our business unit, came into being about 5 months ago. Right now, we are selling initial consultancy and training services, but also working on marketing material.
Of course, abstraction is part of our architecture work and training, but I ran into it in a different context as well. Today I was having a discussion with a colleague on the presumed added value of what you could call a commercial writer, the person who writes texts for your leaflets based on your input.
In some of the texts written by our, externally hired writer we couldn’t find the big picture of what we wanted to be there. Instead, we found every detail of what we, technically trained, told him about architecture, requirements, software configuration management etc. The man explained to us that a text I wrote on architecture was really helping him understand the field, but somehow, the result was not as expected.
Thinking back on this – I think the reason is obvious. With all the details we provided on a field he is not familiar with it’s impossible for him to abstract to the level required to write a good leaflet text. At the same time, we were so anxious to get all our information into the leaflet that we didn’t provide him with a suitable level of abstraction in our explanation.
A tough lesson, but a valuable one.
Posted Sep 7, 11:22 AM by Angelo ·
Abstraction to end user concepts
Posted in: Abstraction
Through use of an abstraction architecture, BI keeps all the data tightly integrated, presents a common interface to all users, and allows immediate correlation of any two data points in the enterprise. All while leaving the source systems to focus on what they do best.
I’ll wait for Dratz" to publish his abstraction white paper before forming a final opinion on his model, but the paragraph above seems a good indication that we’re on the same track. Abstracting away the technical details from end users is much more useful from product perspective than abstracting the technology layers in software development. The latter only makes developer’s work easier, but will still result in applications that are considered ‘too technical’ by their users.
Posted Feb 26, 01:11 AM by Angelo ·
Musing on abstraction
Posted in: Architecture Abstraction
The following is a musing on the concept of abstraction – I’ll be refining it over time…
A short while ago, I was involved in the creation of a product roadmap, and budget discussions for the first year of implementing that roadmap. A discussion that kept recurring in different settings during this process focussed on a concept that been at the center of dicussions on software engineering for years:
Abstraction
In another discussion around the same time, on Operating System Abstraction Layers and Hardware Abstraction Layers (OSAL and HAL), the same topic popped up, showing another set of examples of how people talk about, think about and use abstraction. This triggered me to write the following short text about one of the most dangerous concepts in software engineering…
Abstraction is one of the tools of the software architect – next to generalisation, composition, and others. Within the architect’s toolbox, abstraction is one of the most dangerous tools. It’s about as dangerous as generalisation, but at least generalisation has some sort of negative sound to it that warns people to apply it with a bit of care. Abstraction doesn’t have that sound to it, instead it is mostly seen as a way to simplify things and make it easier to reason about certain problems.
As we know, dictionaries tend to describe the same word in different ways, but most definitions of abstraction in our context as software and system engineers can be translated into something like ‘removing unnecessary detail in order to create an understandable view of a problem’.
First of all, this way of regarding abstraction is correct, but while it is intended to be applied in design of an architecture, it is often applied in discussions around the design process. A good example of this I found in the roadmapping and budget discussions, where management wanted to get initial effort estimation for development of a new subsystem. The date set for that product was set about two years in the future and initial feasibility studies had not started at the time. As a result there were just as many opinions on how to design the system as there were people involved in the estimation discussions. The only way out in such a situation – given that management does not take ‘no estimation’ for an answer – is by involuntarily applying abstraction. The subsystem is subdivided into chunks, called hardware and software and rough estimations based on functionality implemented in each of these are made up and discussed.
A lot of things get lost in this process – including attention for the system architecture, and it’s spin-off, such as such as selection of a useable (embedded) operating system.
When estimating software development efforts, engineers assume an operating system to be present, so the selection and evaluation process – which does take time and money – is not made part of the estimation. Luckily we noticed this, but the risk of oversight is evident, given that an operating system was in use for existing products (hey, it’s there, so why bother selecting another one).
On reconsidering this – about a month after the initial posting, I must add that there’s another factor that is not helping us here. At estimation meetings in the organisation I’m talking about, there’s usually about 6 engineers involved in estimations, but often none of them brings or creates a few design figures as input for the meeting. Everything is done from the top of people’s heads.
Another example comes from an architecting assessment a longer while ago. A company developed a product consisting of two carts, both involving a number of electronical, mechanical and software parts. At some point, with cost reduction on the bill of materials in mind, the software architect came up with the idea to run all software, except for some communications related stuff, on one processor, in one of the carts. Effectively, this meant that one cart would get a better processor, and the other one would get a simple microcontroller – with a slight reduction of material cost as a result. Since the two carts were designed only for end user logistics purposes, and the two were only used in conjunction, this looked workable.
What was not taken into account, because it was abstracted away, was the fact that the product also had to be assembled and tested before delivery. This was done at the manufacturing site, where the following problem occurred: one cart was assembled in about half the time as the other one. Because only one of them ran all software, both carts were needed for delivery testing. Because of the difference in assembly time, a queue of carts developed at the test center. This resulted in costly changes to the assembly lines, and less manufacturing throughput.
Combined with the fact that the simple microcontroller was not powerful enough, the anticipated material cost reduction turned out to be an over-all cost increase. One could argue that this is not a matter of abstraction, but of not taking into account the full scale of the problem. In a way, I think this is still a form of abstraction, because abstraction leads to simplification, and in this case, oversimplification of the problem statement.
Because of these examples, and a few others, I more and more getting to the conclusion that we should be very careful when applying abstraction in our work. Abstraction introduces the risk of oversimplification, and oversimplification makes us miss the important details.
I will be extending on this shortly – since I found some interesting new inputs on the web site of Charles Simonyi. Have a look at this article for instance.
Posted Oct 23, 07:35 AM by Angelo ·
