"Modern" Software Framework?
in [OOP]
|
Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: H. S. Lahman on 18 Aug 2007 11:13 Responding to Js... > But still, it is little tricky not to consider technology choices > available, esp technology that are proven and have longer shelf life > than others, for building such systems. This becomes more relevant > when we are talking of softwares with some specific requirement, like > distributed, heterogeneity, Realtime, longevity etc. I think it depends on where the observer is standing. B-) In a translation shop one can provide an OOA model that fully resolves all functional requirements and is fully testable for those requirements. Such a model will not even <directly> identify distributed boundaries, much less the technologies needed to communicate across them. That's because translation OOA models need to be independent of the computing environment to avoid the review team burning the designer at the stake. One can then turn that model over to an MDA transformation engine that will do full code generation for a particular computing environment and will optimize for the specific technologies available there. For example, probably the single most important architectural activity a Systems Engineer does for a large project is define logical partitioning of the system. That can be done at a very high level of abstraction during OOA in a UML Component Diagram that is completely devoid of technical detail. But that logical partitioning (subject matters, levels of abstraction, flows of requirements) will drive distributed boundaries and interface/communication strategies. Even if one is doing manual elaboration development, in the OOD one addresses nonfunctional requirements at the strategic level. So the architectural decisions are around things like caching, memory management, and distributed messaging strategies. One really doesn't get to tactical design decisions like DCOM vs. CORBA until one implements the OOD strategies during OOP. [An oversimplification because the Systems Engineer/Architect is likely to decree what technologies will be used much earlier in the development cycle based on other factors than just functional and nonfunctional requirements. Some would even argue that specifying a technology is a nonfunctional requirement driven by the development environment (e.g., existing developer skills, tool costs, existing hardware and software, etc.).] ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: xpyttl on 18 Aug 2007 12:05 "Phlip" <phlipcpp(a)yahoo.com> wrote in message news:srOdnU9-UM2cY1vbnZ2dnUVZ_umlnZ2d(a)adelphia.com... > Dmitry A. Kazakov wrote: > >> No, you can't sell TDD here. >> >> Let me try to explain why. > > I stopped reading here. as he covers his ears and sticks out his tongue -- nya, nya, nya ...
From: Johnny Willemsen on 19 Aug 2007 03:59 Hi, > Thanks for the suggestions so far - the only really new one is Ruby on > Rails, which I > I had not considered for this type of system. I know very little about > it, but the Ruby on Rails website > states "Rails is all about infrastructure so it's a great fit for > practically any type of web application Be it > software for collaboration, community, e-commerce, content management, > statistics, management." So > it never struck me as as relevant. I may be wrong. We as Remedy IT have a CORBA product available for Ruby, see www.theaceorb.nl With that solution we can also use and implement CORBA in Ruby. Johnny
From: Markus Elfring on 21 Aug 2007 08:39 > There's a couple of years detailed design yet to go. Would you like to look at recent design methodologies to avoid any pitfalls? http://en.wikipedia.org/wiki/Agile_software_development Regards, Markus
From: Phlip on 21 Aug 2007 21:12
Markus Elfring wrote: >> There's a couple of years detailed design yet to go. > > Would you like to look at recent design methodologies to avoid any > pitfalls? > http://en.wikipedia.org/wiki/Agile_software_development You total process zealot! Don't you know that one size doesn't fit all, and that many great _heroic_ projects have been delivered, on time and under budget, with pure Waterfall??! -- Phlip |