Your UML Tutorial- UML, XML, ESL, MATLAB & Simulink, too
“On the hardware side of the world, it's been two decades now with the HDLs in place, but some people are still designing logic with gates. There will never come a time when UML completely replaces the HDLs, but UML will find its primary home where complexity drives the adoption of new techniques.”
“That's the primary reason that we saw higher levels of abstraction and newer approaches to designing hardware and software. There came a point where it was just too difficult to build systems in lower-level languages. So we moved to higher-level languages for [ease of] expression. Then, we built tools around those languages. In the industry now, there are two parallel paths for managing complexity. One is to raise the level of abstraction, yet again. The other is simply to improve the tools around the existing languages. It's not yet clear to me which one of these two approaches will win, maybe both will win.”
I suggested at this point in our conversation that if SystemC is a version of C constrained to meet the design needs of the users, is there a constrained version of UML that would meet similar needs?
John answered, “We can expect to see a continued proliferation of languages. Some of the profiles are simply tracking existing version of the languages up through graphics and UML implementations. Other approaches involve constraining and making extensions that attempt to provide that higher level of abstraction. Which of these will become dominant or prevalent, it's just too early to tell right now. But certainly, you will see some of what you have already recognized in SystemC - a constraining for the sake of hardware design and also some tailoring of the language for that purpose. I use the word 'tailor' as a combination of constraints and extensions, not just one or the other.”
So then, why not combine the ESL and UML tutorials at DAC?
Yves said, “I think definitely that would help. When we gave our UML tutorial at DATE in Munich, we tried to offer an overview and show how it also combines with other languages and design flows. Yes, going forward, the ESL and UML tutorials may be combined. But right now, most of STMicro's work, for instance, is being done by an advanced team from their research department, so it's still only being looked at from a research perspective.”
John added, “I think maybe one of the reasons the two tutorials haven't been combined yet is because the two movements have been proceeding in parallel. As Yves points out, UML and applications of UML to designing hardware has only been a piece of the overall ESL movement."
"If we look at that movement today, it's one of those things that's not yet fully defined by the industry. There's a demand from many of Mentor's customers for some sort of system-level approach for design and implementation of systems. And, by systems, I mean things that include microprocessors, some custom logic, and some custom software. This is where we're seeing the demand for ESL tools.”
“Currently, there are a number of different approaches and tools jockeying for position in this new landscape. UML and its application to system design are part of that - although it's probably a bit early to combine all of the different approaches into one language or a single forum. At this point, ESL needs to be understood from the perspective of the tool vendors and users. At this point, the vendor's need to understand what their customers want, and UML is only one piece in that possible flow.”
“Just to give you an idea of the spectrum. UML could be used for visualizing the big picture of your system, and then pushing it forward to use all of the various design and implementation techniques available today. And on the other end of the spectrum, you could use UML to model whole systems in a very unambiguous way, and you could synthesize directly from those models into an implementation. UML can be at those two ends of the spectrum. Today, ESL is only focusing on the system-level picture, not at the implementation level.”
Yves added, “As you mentioned, UML does not force a methodology. You can act from the beginning and structure the requirements in UML, or SysML, to get an understanding of a system and what it should eventually do. You can also examine 'Use Cases' - in other words, sunny-day and rainy-day scenarios of how the system should react. And then, people can decide which implementation language to use at that point and how to associate it with UML. Really, with UML there is complete freedom. At the workshop, people will discuss the advantages and disadvantages of the different possibilities."
I asked John and Yves who should, or would, be attending their workshop on July 23rd in San Francisco.
John said, “Primarily, people who are in the implementation companies will attend. We have not seen much participation from the tool vendors as yet, but that could change this year. The tool vendors are definitely taking an interest in the ESL space, but not necessarily taking it ahead a step to show interest in the UML space. At some point, however, we will begin to see a merging of the two movements. We will see a time when UML can be used for the design of a single logic block, or a group of chips. It's already being used by the industry in a big way for software design.”
“Having said that, I don't think UML is critical to ESL or vice versa. They're still relatively independent and may remain that way for quite a while.
Yves added a final note, “On top of considerations of designing hardware or just software with UML, there is the issue of having full support from the users. Up to now, you can find good experts coming from the software point of view. But, it's more difficult without tool support on the hardware side to see people with that type of background coming to understand what UML can offer. Trying to bring all of these people together in one place is one of our motivations for this workshop.”
“It will not really be a tutorial, but more of a forum. There will be tool demonstrations, so people can see concrete uses of UML from NEC, Philips, Fujitsu, and so on, as well as presentations and many opportunities to ask questions. At the end of the day, John and I will moderate a discussion that will bring to the table all of the various points of view that will have been expressed over the course of the day.”
John Wolfe and Yves Vanderperren will be co-chairing the tutorial on UML at DAC on July 23rd in San Francisco. It's going to be very interesting at many levels. You need to carve out some time to attend.
To help clarify a few things, I had a chance to speak by phone with Jim Tung, Fellow at The MathWorks, and Ken Karnofsky, Marketing Director at The MathWorks, following my conversation with John Wolfe and Yves Venderperren. This is a brief synopsis of our conversation, and all the more reason for you to be attending the UML Tutorial at DAC:
Q - UML & The MathWorks?
Jim - It's true that when you look at our products versus the entire definition of UML, there is some overlap.
But UML attempts to be many things. Today, there are over a dozen different diagrams that comprise UML 2. Some are useful and frequently used, but others are not used very often, but they are there for completeness. When we talk to the users and tool vendors, the usage falls into a couple of different categories. Most frequently, UML is used as a drawing tool to identify what the pieces of the system are, and what the interactions are, essentially for high-level analysis. The use-case diagrams in UML are frequently used, because that's something that system analysts understand.
Less often, but still pretty common, is the use of certain diagrams for architecting software - particularly using object-oriented approaches. Some diagrams in UML are useful for describing how the software application would break down into components. However, UML is not as appropriate for saying what functionality those components should perform, or how that functionality should be implemented - but it is very good at describing the software architecture.
Be the first to review this article