＋设为首页 ＋添加到收藏夹
its a pleasure to be writing this article in the beautiful, high-tech, mediterranean city of netanya, israel. its the evening after the first day of the workweek here - sunday, of course - in my current consulting engagement. but working sundays isnt the only thing ive had to get used to here.
although ive driven a car in at least 12 different countries on several continents, ive never had a greater potential for roadway dyslexia than i have here. not only is the hebrew language foreign to my ears, the script found on street signs is written right-to-left (at least thats what ive been told) and doesnt even remotely resemble the roman-based characters ive grown quite fond of. oh, and the hebrew text is generally followed by a second line of text in arabic. hebrew with arabic - my guess is that its the highway departments answer to 128-bit encryption.
what do my language deficiencies have to do with representing enterprise javabeans in the unified modeling language (uml)? everyone needs a common method to communicate thoughts and ideas. in israel the international language is, thankfully, english, which in many cases is the third line of text hosted on road signs here.
but it doesnt end there. as i present java 2 enterprise edition course instruction and discuss project strategies for migrating existing proprietary application server components to the j2ee architecture, i speak freely in english as those who speak native hebrew, russian, and french listen and participate. it works because we have english in common. but when it comes to communicating software architectures and designs in general, and ejb specifically, why do so many often resort to "foreign" methodologies and syntaxes or even choose to "grunt" instead?
why not uml?
from my vantage point, theres been an explosion in the use of uml. when we all come from differing software development backgrounds, we can make architecture and design work for us because we have uml in common. but why do some hesitate or even fail with uml?frankly, i believe that many start off with good intentions to learn and use uml. but because of work environments that lack a reliable software process, capable engineers end up abandoning a standards-based modeling approach for the "code by the seat of your pants" antimethodology. generally ive found this is due to a lack of understanding and/or commitment at the top. because theyve never used or understood a software process themselves, many managers are all too willing to let their development staff live with the pain. so for those of you who think you need to be good looking to be hired for an "object modeler" position and that "senior" is completely out of context, youd better visit your favorite online bookstore and order a copy of martin fowlers uml distilled (addison-wesley) immediately following your plastic surgery.
on the other hand, many of you are completely sold on using a
software development process with uml, but may find the cost
prohibitive. true, the cost of uml tools can be out of the
stratosphere, but there are options. at least one of the leading uml
vendors has expressed willingness to configure its product to fit
... 下一页