Software Architecture - Technology-Independent Modelling

2011-07-16 12:09 by UWS PR

Risks of Technology-driven Software Systems

Very often planning of software systems and/or software architectures is subject to direct technological influences. Decisions, which are to be made during the planning process, are no longer made completely by the responsible people but by software vendors and/or standardisation organizations. It is fascinating that responsibilities are often deliberately delegated here. One has to assume that for example technology vendors solve custom problems of an organization, although the vendors cannot know about these problems at all.

Considering this one might wonder why software-projects can be sucessful at all. This is because of the high degree of abstraction provided by the technologies. This degree of abstraction is however not always adequate for each problem area. It forces project members to think in pre-defined concepts, which often turn out as inefficient and even leads to misunderstandings in collaboration.

In addition the high volatility of technology life-cycles has to be considered when planning software systems. Nobody can know whether a technology is still available, supported or can be used in a sufficient manner in the medium term. A software architecture, which is based directly on technologies, can only be migrated with heavy efforts or maybe not at all.

If one really considers the described problems the consequence can only be a critical perception of technology-driven software systems and architectures!

 

Moving forward to Technology-independent Modelling

However we don't want to pinpoint just problems but also offer solutions. These solutions provide both custom-made degrees of abstraction for a clear and natural project collaboration and just the independence of and flexibility between technologies as you need. We can supply this kind of service by a meaningful combination of concepts and tools of the model-driven software development (MDSD) approach. For getting a better understanding a sample project is described as follows:

For being able to accurately describe the target system we started by designing a language together with the customer for describing the system. This so-called "domain-specific language" (DSL) is tailor-made for specific requirements of the software system and also evolves with progressive understanding of it. Using this DSL we describe the software architecture interdepartmental and accurately.

Using this description program code can be generated at any time. The code itself can include proven best-practises and programming guidelines for the development team in order to work at least as efficient as before. With that a consistent project environment can always be supplied, which can be unrolled to distributed teams and be validated automaticly in the sense of a "continuous integration" according to definable rules at the model level. Using this generative programming approach other deliverables like variants of software product lines, test environments, prototypes and documentations can also generated in a scaleable manner. As the following diagram points out this approach also makes business and IT departments work much closer together since the artifacts are understood much better by both parties during the development process:

 

tl_files/news/mdsd_en.png

 

UWS brings the know-how, re-usable modelling components and tools into projects, in order to support fast and effectively. Gladly we answer questions regarding your project scenarios. In addition we happily take registrations for a subject-specific webcast.

Go back