On Aug 18, 2006, at 1:19 PM, Anne Thomas Manes wrote: > Stefan summarized his point with: > > Which is exactly my point - the fault is not in UML, nor OO, > but in > using it wrongly. > > I agree that UML is not at fault, but I think current tooling is,
+1. In fact, I don't think there has ever been a "good" UML tool - in the sense of "good for automated software development". > because it focuses too strongly on OO design, leading people to use it > wrongly. I'd very much like to see someone define a standard SO > profile for UML. > > Anne > There's numerous proprietary SOA UML profiles I'm aware of; one example is this one: http://www-128.ibm.com/developerworks/rational/library/05/419_soa/ A UML profile is a poor man's metamodel, so this could conceptually be used with MOF or EMF, too. The problem is that one has to define what the exact SOA metamodel is :-) Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ > On 8/18/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: >> On Aug 18, 2006, at 10:42 AM, Lukas Barton wrote: >> >>> Hello, >>> I wrote a thesis about MDA (only in Czech, see abstract athttp:// >>> www.archaebacteria.net/?p=5). >>> I mean that MDA as described by MDA Guide V1.0.1 and MDA >>> Foundation Modelfrom OMG forces OOAD (Object Oriented Analysis and >>> Design). MDA is now too object oriented. >>> The main problem is in tools (and you cannot do MDA without >>> tools). I learned that majority of tools support OOAD (Object >>> oriented analysis and design). Most of them only transforms class >>> models into static object structure. That's useful. It could save >>> time during developmnet phase. Etc… but does not help with SOA. >> I don't understand this statement. First of all, lots of tools >> support generation from other models; e.g. it's easily possible to >> use UML activity diagrams to describe a business process and generate >> e.g. BPEL from it. Secondly, I don't see how generating WSDLs from >> UML class models "does not help with SOA". >>> OOAD is not enough for SOA. The world is not composed only from >>> objects (object model). There could be another views - service >>> oriented, event oriented,hirearachical or data (document) oriented >>> (mixture possible). Detailed example of OOAD inadequacies for SOA >>> were described at Elements of Service-Oriented Analysis and Design. >> The key piece from this article regarding OO seems to be this: >> >> "The main issue with current OO design practices in relation to SO is >> that its level of granularity is focused at the class level, which >> resides at too low of a level of abstraction for business service >> modeling. Strong associations such as inheritance, create a rather >> tight coupling (and, consequently, a dependency) between the involved >> parties. In contrast, the SO paradigm attempts to promote flexibility >> and agility through loose coupling. There, currently, is no cross- >> platform inheritance support and first-class notion of a service >> instance in SOA in order to avoid having to deal with service >> lifecycle housekeeping issues such as remote garbage collection." >> >> Which sounds like Eric's argument to me. To which I say: Don't use >> inheritance (even though WSDL 2.0 supports it, see http://www.w3.org/ >> TR/2006/CR-wsdl20-20060327/#Interface_extends_attribute), and don't >> model your services as "stateless classes" (or rather interfaces). >> >> As the authors write "current design practices", which is emphasized >> in the next paragraph: >> >> "These considerations make OO difficult to align with the SO >> architectural style straightaway. However, OO still is a valuable >> approach for design of the underlying class and component structure >> within a defined service. Furthermore, many OOAD techniques such as >> classes, responsibilities, and collaborations (CRC) cards can be >> leveraged for service modeling, if elevated up to a higher level of >> abstraction." >> >> Which is exactly my point - the fault is not in UML, nor OO, but in >> using it wrongly. >> >> Stefan >>> But there is no Rational for SOA, if you want to do SOA you have to >>> use at least five different tools. I dont know whether does this >>> mean that is too hard to make homogenous tools supporting SOA? >>> >>> My two cents, >>> >>> Lukas >>> >>> >> >> >> >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> >> > > > > > > > Yahoo! Groups Links > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
