Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Stephen

Pages: 1 [2] 3 4
16
General Board / Re: Self Messages in Sequence Diagrams
« on: March 30, 2004, 05:33:22 am »
Thomas,

Would you boil things out in an activity diagram - or possibly a statechart, sorry State Machine diagram.

Or do you have something else up your sleeve for interesting algorithm documentation?

Stephen

17
General Board / Re: Stumped! Generalised object creation aka late
« on: April 02, 2004, 08:10:15 am »
errata!
Second Scott Ambler link should have been http://www.agilemodeling.com/style/collaborationDiagram.htm

But that still doesn't address your concern around distinguishing late binding from early binding
Must be using the wrong model.
Sequence diagram feels right but.... took me half an hour to get this little example right - can't be worth it
- perhaps I ought to practice drawing these a little more often    ;)

Stephen

D**n - How do you get a picture in here, I've seen others...Can't believe I've wasted all that time...

18
General Board / Re: Stumped! Generalised object creation aka late
« on: April 02, 2004, 07:09:38 am »
Bruce,

Bear with while I try to get up to speed. My modelling skills are woeful :(, but if I don't try to understand they're not going to get any better are they?

My basic understanding was that communication diagrams are used to "... show the behaviour of several objects collaborating together to fulfill a common purpose" (Scott Ambler, www.agilemodeling.com/artifacts/collaborationDiagram.htm - also see www.agilemodeling.com/artifacts/collaborationDiagram.htm).
If we accept the statement and put our algorithm logic in a complementary sequence diagram (which would show object lifetime - a pre-existing object would just be live throughout the diagram), then I wouldn't expect to see any creator/destructor style messages in the collaboration diagram.... The object is assumed to be present to participate in the collaborative effort.

message to self.....
I must get beyond class diagrams
I must get beyond class diagrams
I must get beyond class diagrams

Stephen

19
General Board / Unicode Install
« on: March 31, 2004, 07:35:08 am »
What should I consider when deciding whether to install the "standard" build or the uniode supporting build?

Does it "just" provide extra character support for comments and names etc. - Vital for non-english speakers, but just doubling the database size for the rest of us.

OR

Does it have a very immediate impact on forward or backward engineering. Do I have to use the unicode version to engineer a unicode based Oracle database (say). If I use the Unicode EA will it still work with non-unicode targets?

Many thanks

Stephen

20
General Board / Help File Update
« on: March 30, 2004, 02:16:37 am »
I notice the help file haas had a refresh today.

Anyone at Sparx like to give us a few clues about what's changed. A cursory skim has failed to spot any differences.


21
General Board / Re: Upgrade to Shared SQL Server Repository
« on: December 04, 2003, 08:45:59 am »
Just got in - on about 5th time of asking
Only strange thing I did was enter security key for the file based model already loaded
(No I don't believe this is signifcant either - but it was the only difference!)
Steve

22
General Board / Upgrade to Shared SQL Server Repository
« on: December 04, 2003, 07:59:45 am »
 ???
Having used EA for a year or so (Professional version) I've recently persuaded the dept. to adopt as a standard. Company has decided to buy the corporate version to support sharing of repository.

I must have forgotten something during install of database on server. I'm able to complete a Data Transfer to the database, but I can't connect to it afterwards. When I try to connect to the database model, my connection checks out; I enter details for Connection Name and Type; But when I attempt to Open  - EA crashes.

Also when I try to create a new model I am only prompted to create a file based model, not a db version.

I uninstalled my previous copy of EA before installing a fresh full install (just downloaded from the Corporate area)

Also - Am I going to have to create a new database for each model (for each user)? - most users are without SQL server experience so this job is likely to land on my plate...


23
Uml Process / Re: Use cases scenarios and activity diagrams
« on: April 26, 2004, 06:40:44 am »
Of course (!) you need to decide exactly what it is you're after. Formally Collaboration diagrams model interactions between objects as messages.

If your modelling process or data flow the "correct" model is the activity diagram.

I'm prepared to bet that most readers won't spot the difference - although its always a very good idea to not get messages and data flow mixed up.

24
Uml Process / Re: Use cases scenarios and activity diagrams
« on: April 26, 2004, 03:06:38 am »
Another option for the more diligent modeller is to use Collaboration Diagrams, rather than Activity Diagrams.

You do need to educate your less-technical readers to get the most out of them, but they can help you make sure you don't miss any objects out on your journey from use-cases to detailed architecture.

Just as you can map a process onto a sequence diagram it goes onto a collaboration, but makes a more compact diagram!

25
Uml Process / Re: Trigger modeling in Interaction diagram
« on: April 08, 2004, 08:34:24 am »
Found message looks useful - I sometimes add a "generic" triggering object if I have some particular wish to detail the circumstances of the trigger.

But the message would give you as much flexibility..

Stephen

26
Uml Process / Re: tech spec
« on: April 08, 2004, 06:51:02 am »
You may like to consider a couple of key heuristics as you build your technical specification,

whatever the final format you adopt.

Firstly, create a set of "highest" level requirements, written in a format and with language to suit

the Client. Present these as a set of "system goals" (or business goals). The idea is to create a

boundary for the system that will be "easy" for both parties to spot. It's worth including both

functional and non-functional aspects here - including some operating envelope parameters will give

you a set of sensible get-out's at the end of the project (Document the number of users or

transactions etc the system is designed to support - include some tooling to monitor this so you can

have a two pronged approach to performance issues). The driver here is to create a set of statements

about the system that are very unlikely to change during the lifetime of the project. This is not to

sya that this is just a business process analysis piece against your client, you just want something

that will help both of you identify when the Client askes for a change to far (...when you want to

ask for some extra money on a fixed price contract).

The other key element is to create a very clear bridge between these business goals for the system

and the artifacts you need to implement.

Flip into you analysis mode and create sets of use-cases, class diagrams and (say)

collaboration/communication/statechart models in parallel. Restrict your use-cases to the obvious

"what happens" stuff; put the "what does it" in the class model and the "in  what order" in the

communication diagram. Doing all three at once will help you cover all the bases and not get too

bogged down in the use-case (c4suc). The really anal modeller can rope the generation of sequence

diagrams in at this point also.... Doing the the models at the same time helps you make use of all

of the information captured on your CRC's while you can remember what you were thinking.

To form the links between the business and the technical worlds map the use-cases onto the "goals".

For clients with a little bit of an engineering background create something like a work breakdown

structure under your goals to clearly key some deliverables (use-cases) to some particular element

(functionality) of the system. Only put prices on these links (stops you charging for something the

Client can't validate).

Don't try to do all this for the User interface esp. on a browser delivered system. Try to keep all

UI discussions in a separate stream (can still document client-side functionality in same way, just

don't get into detailing screen layout). The XP practitioners don't want to deal with this yet, the

waterfallers only need a storyboard anyway(!)
Similarly for data issues - system meta-data manangement, data migration etc.
I also hive off reporting issues because I mainly service clients within the same group of companies

or external organisations with their own I.S. dept.

As I try to live with my organisations processes I phase my projects as small as I can get away

with, do a couple of iterations of the above at the highest level I can manage without getting

vertigo. Then use what I've learnt to take a stab at a price. As long as the "goals"are solid I can

generally price safely, then flesh out the technical side for each phase (release!) as I get to it.

Just got to get a bit more flexibility into the off-shore dev. team now......

Hope a bit of the above fires some useful ideas

Stephen

27
Uml Process / Re: Use Case - regarding the systems memory...
« on: March 31, 2004, 04:11:15 am »
Campaign for Simple Use Cases

Who reads your use cases? If you try to capture everything in (essentially) as textual format, are your clients sufficiently technically savvy to understand all the nuances? If your use-cases become too detailed they may not work for your Clients anymore, just help to steer your developers. Then you need to manage some other document to capture client requirements (CRC's?), which you then have to trace into your UC's.
Keep the UC's simple, stash away a couple of activity diagrams or communication diagrams (state machine diagrams if in a very decomposed OO environment) for the developers to get there extra detail. Building these models may also help ensure the robustness step gets done.

I no fan of useless documentation, but I keep reading comments on this site and others, that use-cases are developed in detail and other diagrams are perhaps sketched out and discarded on an ad-hoc basis.

Assuming the essential systems architecture is reasonably fixed (and understood), what is needed is a documentation standard for non-technical readers (Clients); something to get the development team started (which will be a living model/repository including all the little alterations); some method to automatically analyse what the developers have produced - probably back to a series of UML docs (easy to do structural diagrams, behaviour is a bit more tricky!); which can then be annotated by developers explaining how and why the system looks the way it does. (won't ask them for too much or we won't get it, but make sure they cover the behaviour.)

The real problems are with change and configuration management and apply just as much to the model as to the system....

28
Uml Process / Re: Model Change Management
« on: March 05, 2004, 02:52:47 am »
Good simple idea with the renumbering - I'll have to come up with something similar. I want to try and extend the idea to cover sets of artifacts (and possibly their associated diagrams)

I also need to adopt a naming convention for my model artifacts. I end up struggling for names when trying to tie together all the particiapants of an interface from database to presentation layer.

Sounds like merging into a "master model" is always going to be rather manual....

29
Uml Process / Re: Model Change Management
« on: March 04, 2004, 06:44:37 am »
Very much thinking along the procedural level.

I was looking at creating an independent model of the changed system (the "to be" case), but then wondering how to manage that into the overall system model - or back out again if the change was reversed.

Bruce - you've lost me a bit with the reference to a "4+1 paradigm".

I'm not sure that using the EA attributes is going to help me manage my system model - though I accept the usefulness for reporting.
Do you ever re-cast your use-cases from <<changecase>> to ordinary use-case once the feature becomes part of the base system (??). Sound like you make a new model and swap over as opposed to a merge style operation.

I wanted to come up with a process that would help me manage "small" localised change within the context of a much larger model.

30
Uml Process / Model Change Management
« on: March 03, 2004, 08:03:00 am »
[Scenario]
I have a complete model of my system, typical n-tier browser viewed system.

I receive a change request from the business to alter some aspect.

I can model a revised version of the system.

How does the panel manage the change within the (overall) model?
I'm clearly going to want to retain the previous set of artifacts, and the new set - with a bit of context so I know why the change was made. Anyone got any ideas about how to merge by change set of objects into the base design?

Cheers!

Pages: 1 [2] 3 4