Advertisment

Will Models drive us?

author-image
CIOL Bureau
Updated On
New Update

By- V.K.Kripanand, Technical Manager, Telelogic



The invention of the microprocessor was a boon to the Electronic Industry as it brought computing to desks, creating new business dimensions. Coupled with the Internet boom, computing today has become an integral part of our lives and business. The last few years has seen convergence of features into devices like handheld computers, mobile phone, cars, washing machines and a host of other appliances. Advancements in processor architecture, invention of processors that consume less power, processors that accommodate millions of transistors in a smaller footprint, processors that run at gigahertz speeds, processors that can crunch numbers and other technical advancements has led to affordable small sized processors and met the needs of incorporating extensive features into devices.



Software has seen a similar revolution in the last 3 decades or so, but we tend to overlook and visualize the presence of software in the devices and services that we use. Software is used in each of the devices that we embrace, enabling a host of features in our day-to-day life, from cars to microwaves to mobile phones and smart cards. Most of the latest models of mobile phones that are flashed around by all of us, boast of features like Personal Information Managers, connectivity with wireless LAN, Bluetooth, Infrared support, digital cameras, storage and host of other features. Software is the key to get these features working as the interface; actions performed by the user are heavily dependent on the software applications residing on these devices.



Software development in the earlier days was mostly based on assembly language. This required us to learn the processor architecture, the number of registers it had, memory architecture, addressing capability and so on. Often, software written for one category of systems could not be directly adapted to a different system. High-level languages like Pascal, COBOL, Fortran, more recently, C and C++, helped move the level of abstraction above assembly language.



Desktop computing, user-friendly Operating systems, Networking and Internet also paved way for these high level languages find themselves housed in user-friendly compilers that helped code effectively with its editor, debugging and trace functionality. Developers had their choice of programming languages and every task that was assigned could be accomplished by coding using a favorite language, resulting in making themselves linguists of the software community.



What was not sure is that whether the code that is written would meet the needs of the user or a different developer? No, that is because languages that each of these developers speak is not uniform, that can be used to communicate what is intended of the system.



Model Driven Development



Model Driven Development (MDD) is a technique by which the software/system that is being built is expressed using visual constructs rather than expressing them using words or pages of descriptions. MDD is the technique with which developers would express what the system has to do and its behavior, using a modeling language. MDD is actually a part of the bigger framework for building applications called the Model Driven Architecture (MDA).



Early 80's till the late 90's saw a lot of momentum from different groups to arrive at a modeling language that could help developers visualize the software development activities, rather subscribing to be linguists of the software community. These efforts channeled and supported by the Object Management Group (OMG), gave birth to Unified Modeling Language (UML), which could bridge the linguistic differences in the software community and bring them together using a visual modeling language.



Did this momentum spread over 15 years do any good to software developers? When the transition from assembly language to high level languages was well accepted and gave birth a new age of developers who swear by programming languages, what is it that prevented a technique like UML being put to use, lest not swearing by it? Unfortunately, the transition was not something that was smooth enough or promising enough for the developers to switch loyalty from their programming languages.



UML till about version 1.4, was primarily a notation that was useful in expressing systems/software that need to explain what needs to be done, not how. This meant that developers had to write models that could express the architecture of the software/system being built and then generate code from these models. The generated code was not complete and had only signatures (as known in OOAD terminology), where developers had to build the behavior of the system using programming languages.



Tools built around UML1.4 supported reverse engineering of the existing code. This only resulted in developers writing applications in their favorite languages and using the reverse engineering to get the models. This is akin to constructing a building and then writing its blueprint! I would see this as the major reason for the developers not switching their loyalty from their favorite programming languages.



The benefits of Model Driven Development are quite a lot. Model Driven Development benefits the developers/architects build the architecture of the system, simulate them, verify whether they work and meet all functionality, test their reliability, performance issues and then adopt them. In other words, MDD can help software industry do what CAD/CAM did to the Design/Engineering/Manufacturing industry.



Consider this. You have a system to be built, let's take a coffee vending machine. Of course, we know the normal circumstances that the coffee machine would be used for and the various scenarios. The requirements and scenarios are taken and placed on a whiteboard and the analysis starts. In a normal development scenario, after this analysis, developers would get their designs in place and arrive at a design document. The developers who are involved in this development would meet an afternoon, lock themselves in a conference room, use the white board and thrash out all the issues on the design. The project manager would just arrive at the various tasks that are involved and then assign tasks to each team member. The software linguist force gets into action, choose their favorite language and start the implementation. As a rollout of the process, after a few days/weeks, the developers would integrate all the code that has been built. The testing team gets into action; arrive at the various test cases for all the scenarios and start testing. The system passes all the tests and the software is ready to be shipped. All of this activity is carried out with the assumption that the system would be finally adapted to a target device that is based on a specific processor that will be housed in the coffee machine.



Now for the good and bad news. The good news is that the system is well accepted and a repeat order is placed. The bad news is that the customer decides to change the processor for the new set of coffee machines and wants performance issues to be resolved. This means though a lot of code can be reused, there are architectural changes to be made and extensive re-testing to trap and fix the performance issues.



This is exactly where model driven development plays a crucial role. If model driven development had been adopted, this situation would have been a simpler. The level of abstraction being higher, the code need not be re-written, but adapted to the new processor architecture. This would have given a lot of time to simulate the performance problem and meet the project deadline.



Model driven development relies heavily on the underlying models, which are the building blocks for development. In the above scenario, the project team would have got together, used a modeling language to build the constructs of the system, integrated the same, simulated the environment, executed various test cases, scenarios and finally generated code from these models. This is what happens when you program using a language as well, but the level of abstraction is a level higher. Had the project team programmed in assembly, could they have just tweaked the code to get it working on a different processor?



In fact, Model driven development, has been around for quite sometime and just that it is time now that we start looking up at this seriously and see if we can move software developers to a higher level of abstraction. Obviously, this does not mean the death of programming languages, as we see assembly language is not dead yet, but not prevalent as much as the high level languages.



UML 2.0



In the last 2 years, a lot of stalwarts in the modeling paradigm have joined hands to come with a major revision to the UML called as the UML2.0. For over 2 decades, in the telecom industry, a model based descriptive language has been used to describe the behavior of the system being built completely and successfully helped model driven development. This is called as the Specification and Description Language (SDL). Tools based on this language have delivered most of the promise of model driven development to the telecom industry, way ahead. UML2.0 has been a major revision to the language that has taken the best of both these worlds (UML1.4 and SDL) and converged them to benefit the community working towards a model driven development.



UML 2.0 has been accepted by the OMG voting last month, to recommend the adoption of the UML 2.0, completing the upgrade of the modeling language to version 2.0.



With this new version, tools built around this language are delivering the promise of model driven development, where developers write models, instead of code, execute models, instead of code and generate all the code, instead of writing the code. As the level of abstraction is higher, it is possible to adopt the generated code easily, to a new processor architecture or target device.



A current day tool that supports UML2.0 has capabilities of simulating the complete system; check functionality, performance, reliability and other issues, without writing any code. These tools also support the features that developers are used to like an integrated development environment, debugging and execution trace among others. In fact, the environment is very similar to compiler environments, except that the level of abstraction is higher and UML2.0 is used as a programming language.



 



What's in store?



Model driven development is here to stay and deliver the promises. Models will drive the way software is written in the future. With new features, new software being written for more devices, it is imperative that software developers take the level of abstraction, a level higher and utilize this chance to drive software development using models.



Not convinced? Here are some of the promises of UML2.0 that would deliver the vision of model driven development.



  • Model driven development takes away the pains that the developer faces in maintaining code that is written by others, instead the developer maintains the models, which is much easier to read, understand and is not language centric. Thus a developer, who knows the modeling language, could be doing enhancements, fixing bugs with the models and generating code in C, without learning C. This is nothing new, as the current day programmers do not know assembly, though every piece of C/C++ code ultimately transforms to assembly and machine code.


  • Testers need not wait till the code is developed to test the various scenarios that the system would work with. They have access to the model that executes helping them test every possible scenario and trap the errors that are likely.


  • The level of abstraction is high, so that a lot can be reused thus leading to opportunities to develop systems faster that are more reliable and proven.


  • Developers do not have to dig deep into code that is written by others (most of you know how painful it is, to do this). Instead they use the models, simulate, test where there could be problems and write enhancements, fixes to the models.

With a lot of efforts in the last 2 decades by stalwarts to promote the model driven development and the proof that we have now with cutting edge tools that support these features, it is all about educating ourselves, what these new methodologies promise and deliver.



I think it is time we start looking at model driven development to facilitate a migration from the current level of abstraction to a higher level, rather than considering them as a replacement or competition to programming languages.



 



 



 



tech-news