David Freeman david_freeman@rocketmail.com writes:
This is cos you probalby have no formal training in systems analysis. once you try and use them they will become second nature, have a look at the book "UML in a nutshell" it explains it all, I was like you I ignored it all untill I understood how it would all work, I now will try and use UML for my software to improve it.
Well, I'll take a look, but the majority of systems analysis methods appeared to be focused on the object-orientated imperative paradigm, which isn't where I usually (want to) live.
Am I wrong on this? Would I be able to use UML in my work? I know that I've been on panels rejecting a candidate who started spouting about using UML. (OK, they were also talking about Z, formally proving programs and other things we didn't want for a "data juggler" who had to start with a backlog of data which had already had its format designed by experts elsewhere ;-) )
http://rabbit.stu.uea.ac.uk/pipermail/alug/2001-May/001083.html Only Brett seemed to criticise it...
Critisie my scheme or my methods?
Scheme afaict.
Good code is code which meets the needs of the application and doesn't crash. [...]
Being written is a prerequisite for these.
No its not, being written well is the prerequisite.
How is being written not a prereq for being written well? ;-)
Is an RDBMS appropriate, or should we just assume an OO backing store?
true, but the principles are the same, they all boil down to designing a relationa scheme which then needs to be normalised, and as relational theory is based on set theory as is OO theory the design is applicable to both, hence my keeping animplementation independent view of things.
The realities of modern RDBMSs with all the triggers and code inside the database seems to be quite far from pure set theory to me. There's quite a nice piece about it in the most recent VSJ, I think.
MJ Ray wrote:
David Freeman david_freeman@rocketmail.com writes:
This is cos you probalby have no formal training in systems analysis. once you try and use them they will become second nature, have a look at the book "UML in a nutshell" it explains it all, I was like you I ignored it all untill I understood how it would all work, I now will try and use UML for my software to improve it.
Well, I'll take a look, but the majority of systems analysis methods appeared to be focused on the object-orientated imperative paradigm, which isn't where I usually (want to) live.
that is true in some respects, UML, booch and the like are biased towards OO, but there are plenty of other schemes which can explain complex systems that don't use OO. In Electronic Engineering (yep, I call myself an EE as well as SE), there are methods that using state transition diagrams and flowcharts. While you can make a very bad flowchart, as well as a very good one, the point is that at least you have stood back and have a formal(ish) document which others can refer to. Whern you have large numbers of people working on something, you need to make sure that the design is set in stone, and cannot be open to interpretation. This is why a textual description is not good enough imho, as there is no formal use of english to describe something, therefore it is open to interpretation and errors are made....
BUT, (bear this in mind) it is impossible to design a system that is exactly righ the first time round, there is an iterativation stage of modifications and design changes (the waterfall model for those in the know)... this does not necessarly mean that the system was badly designed in teh first place, it's just that until you actually start building the system you won't be able to see the technical dificulties...
my opinion, get a basic design that is fairly generic, build it, then find out what is wrong (hopefully if the first design is well thought out there will be nothing serious!) and iterate the design to incorporate these changes.....
just my 5p.. Sz
Neaill,
--- Neill Newman neill@entora.co.uk wrote:
MJ Ray wrote:
David Freeman david_freeman@rocketmail.com writes:
This is cos you probalby have no formal training in systems
analysis.
once you try and use them they will become second nature, have a
look
at the book "UML in a nutshell" it explains it all, I was like
you I
ignored it all untill I understood how it would all work, I now
will
try and use UML for my software to improve it.
Well, I'll take a look, but the majority of systems analysis
methods
appeared to be focused on the object-orientated imperative
paradigm,
which isn't where I usually (want to) live.
that is true in some respects, UML, booch and the like are biased towards OO, but there are plenty of other schemes which can explain complex systems that don't use OO. In Electronic Engineering (yep, I call myself an EE as well as SE), there are methods that using state transition diagrams and flowcharts.
Good to here it, someone who calls them selves an engineer. UML and many other software systems analysis techniques can be used for many other uses.
While you can make a very bad flowchart, as well as a very good one, the point is that at least you have stood back and have a formal(ish) document which others can refer to. Whern you have large numbers of people working on something, you need to make sure that the design is set in stone, and cannot be open to interpretation. This is why a textual description is not good enough imho, as there is no formal use of english to describe something, therefore it is open to interpretation and errors are made....
Exactly. The english language is a self referential incomplete system ( i.e. recuresion to recursion) and by using a meta language - UML - we can desribe things without the self referentailism.
BUT, (bear this in mind) it is impossible to design a system that is exactly righ the first time round, there is an iterativation stage of modifications and design changes (the waterfall model for those in the know)... this does not necessarly mean that the system was badly designed in teh first place, it's just that until you actually start building the system you won't be able to see the technical dificulties...
I think you mean spiral, but your point is sound. We will get a system up and it will be tested and it will be iterated upon to complete a system.
my opinion, get a basic design that is fairly generic, build it, then find out what is wrong (hopefully if the first design is well thought out there will be nothing serious!) and iterate the design to incorporate these changes.....
Amen brother.
Thanks
D
just my 5p.. Sz
-- Open Source Specialists http://www.entora.co.uk/ Tel: +44 (0)701 0723686 Fax: +44 (0)870 3214368
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://www.anglian.lug.org.uk/ http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
--- MJ Ray markj@cloaked.freeserve.co.uk wrote:
David Freeman david_freeman@rocketmail.com writes:
This is cos you probalby have no formal training in systems
analysis.
once you try and use them they will become second nature, have a
look
at the book "UML in a nutshell" it explains it all, I was like you
I
ignored it all untill I understood how it would all work, I now
will
try and use UML for my software to improve it.
Well, I'll take a look, but the majority of systems analysis methods appeared to be focused on the object-orientated imperative paradigm, which isn't where I usually (want to) live.
Now why do you think that might be? OO is the future and it is also a very nice way to think, its natural, we don't think:
do a then b
we think
a has the facilities to do x y and y
b inherites the functionaility from a and adds p q r and s
OO is better for modern software.
Am I wrong on this? Would I be able to use UML in my work? I know that I've been on panels rejecting a candidate who started spouting about using UML. (OK, they were also talking about Z, formally proving programs and other things we didn't want for a "data juggler" who had to start with a backlog of data which had already had its format designed by experts elsewhere ;-) )
Read UML in a nutshell and get back to me, and also phone the poor sod and give him the Job, he sounds like he may know what he's talking about. Formally proving programs, nice :o)
http://rabbit.stu.uea.ac.uk/pipermail/alug/2001-May/001083.html Only Brett seemed to criticise it...
Critisie my scheme or my methods?
Scheme afaict.
ok.
Good code is code which meets the needs of the application and doesn't crash. [...]
Being written is a prerequisite for these.
No its not, being written well is the prerequisite.
How is being written not a prereq for being written well? ;-)
You obviously aren't in the camp of designing bugs out of programs.
Is an RDBMS appropriate, or should we just assume an OO backing store?
true, but the principles are the same, they all boil down to
designing
a relationa scheme which then needs to be normalised, and as
relational
theory is based on set theory as is OO theory the design is
applicable
to both, hence my keeping animplementation independent view of
things.
The realities of modern RDBMSs with all the triggers and code inside the database seems to be quite far from pure set theory to me. There's quite a nice piece about it in the most recent VSJ, I think.
I'm no expert in this sort fo stuff, but I do know that the whole relational Paradigm and the OO paradigm are very closely tide in,
Thanks
D
-- MJR
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
-
David Freeman -
MJ Ray -
Neill Newman