Arthur Fuller
artful at rogers.com
Mon Jan 19 09:03:48 CST 2004
Whew, a bundle of questions! In a previous job, I used Rational Rose about half my workday. I did all sorts of UML diagrams. The software in point consisted of hundreds of modules, written in a variety of languages including MS C++, VB, PowerBuilder, Access and Java. Everything talked to a SQL database, and lots of components in different languages had to interact. Access was used only for the most trivial components, such as setup utilities and so on. In this kind of situation, UML is an absolute necessity, IMO. There were approximately a dozen developers plus a software architect plus a data modeling expert plus a SQL DBA expert. Nobody but the DBA had the right to create a sproc or a view. No code was written without being vetted by several people in several design meetings. The interfaces were all worked out long in advance to the actual code being written. (Example: a given NT service might talk to a conveyer belt, a bar-code scanner and a weigh-scale, with the ability to recognize a bad scan then send an instruction to the belt to roll the object back so it could be rescanned and/or reweighed.) For this sort of project, woe to the team that tries to develop it without a design-tool like UML. Currently, I'm working pretty much in Access and SQL 2000, with a little here and there in .NET. So far as Access projects go, I think UML is overkill. Perhaps not the right word.... UML is designed for OOP languages, and Access is far from an OOP language, so the constructs don't make a lot of sense there. However, I am a big fan of ER design tools such as ERwin, PowerDesigner and so on. I would not consider doing a serious Access project without such a tool. What such tools let me do is concentrate on the database design without ever creating a table, and then when I'm satisfied, to click a button and generate ALL the tables, constraints, RI rules, indexes, etc.. If I want, I can Save As and create a new version of the diagram that in turn creates a new version of the database. Even when I inherit a database, the first thing I do is run it through PowerDesigner (my fave) so I can get a decent diagram and then study the big picture. Frequently I find major flaws just by looking at the diagram. One of my fave features of such a tool is called Domains. A Domain is defined as a meta-field, thoroughly specified (i.e. label, input mask, format, validation rules, etc.). Then when you're designing tables you can use these Domains instead of describing a new field each time. Let's say you have a column CustomerID which is an integer and should be presented as a combo-box consisting of SELECT CustomerID, CompanyName ORDER BY CompanyName Ascending. Describe it once, then drop it into every table where you need it. I spend a LOT of time devising my Domains before I get around to creating any actual tables. So.... UML is IMO most useful with truly O-O languages, and inappropriate for Access projects. Data-modeling tools on the other hand are essential for every serious database project (i.e. 30+ tables). My $.02... Arthur -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of bruce_bruen at mlc.com.au Sent: Monday, January 19, 2004 1:43 AM To: accessd at databaseadvisors.com Subject: [AccessD] Methods, tools and the d*^$#)( UML Hiya folks, Happy new year! Looks like I am be back from the "hallowed halls" of method consulting yet again and having to do with the ____real___ world of development.... Anyway, having spoken out (within the client) for the last x months about development best practices, UMl and the way, the truth and the light of rapid, but not extreme, development methods I am now in the enviable position of having to implement what I said. One of the problems of speaking from the ivory tower of development methodology reseacrh is that many, many options are presented and many ideas are gleaned and ...discussed... (many name also appear, amongst which the illustrious of this list come up quite frequently! ) . Its very easy to talk of best practice - and in one's own universe - to implement it. However, I have just been granted the privilege (?) of implementing it across an entire organisation structure. An organisation with a large and diverse set of IT environments (mainframe to J2EE) and a large and diverse set of psychologies (individual and team). <<sidebar>> When I started in this game FTN77 was a good idea, COBOL transformed the way we had to think about systems and information, IT centres consisted of programmers in white coats (or sports coats with elbow patches) and I/O was all about card decks or, for the bleeding edge companies, text to input forms ...... Name: |__|__|__|__|__|__|__|__|__| |__|__|__|__|__|__|__|__|__| Sex: | __| (Y/N) DOB: |__|__| / |__|__| / |__|__| etc... We seem to have moved on a bit from this paradigm. <</sidebar>> Now, given that AccessD represents one of the largest and most widely interested development communities on the planet - (if you doubt me try following a PHP mailing list for a couple of weeks - talk about AR!) my question is this (actually these) Are you using UML to design in VBA/VB/VB.net environments? Is it "working"? Are you using Unified Process methods in VBA/VB/VB.net environmets? Again, is it working? In your general experience, are methodologies enabiling or overhead? rgrds Bruce The information contained in this e-mail communication may be confidential. You should only read, disclose, re-transmit,copy,distribute, act in reliance on or commercialise the information if you are authorised to do so. If you are not the intended recipient of this e-mail communication, please immediately notify us by e-mail to postmaster at mlc.com.au, or reply by e-mail direct to the sender and then destroy any electronic and paper copy of this message. Any views expressed in this e-mail communication are those of the individual sender, except where the sender specifically states them to be the views of a member of the National Australia Bank Group of companies. Any advice contained in this e-mail has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this e-mail, National Australia Bank Limited recommends that you consider whether it is appropriate for your circumstances. If this e-mail contains reference to any financial products, the National recommends you consider the Product Disclosure statement (PDS) or other disclosure document before making any decisions regarding any products. The National Australia Bank Group of companies does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus or interference. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004