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 - sargasso

Pages: 1 ... 87 88 [89] 90 91 ... 94
Uml Process / Re: collaboration diagram problem
« on: April 04, 2004, 05:00:15 pm »
I mainly wanted to show how we use the classes on the communication diagram to add the clarity and evolve the design to the next level.

The diagram (as it stands) is not "pure" UML but it does show that the "important" element is the CustomerPort object and (I think) show the true order of events so we can create the lifelines later.

Customer is the initiator of the first sequence.  It is the only object that knows its identity at this time.  It can certainly generate the creation of a new Call:CustomerPort object and supply its own Identity to it.  Call can then get the attention of the HeadClerk object as in "Hey, I'm a newly created call!"
HeadClerk can look around the room decide that ClerkX isn't working hard enough and tell Call to Allocate itself to ClerkX.
HeadClerk is now out of the way (in terms of Call) and can go back doing whatever else.
Call alerts ClerkX that he is to handle it (TakeCall)  and ClerkX must respond.... etc

Now the diagram is slightly wrong here..  I have shown supply service as a call on Customer by Clerk.  In reality it should be more properly a call on Call by Clerk, but I left it this way to make things clearer at this time and would fix it later.

What we see by adding the classes is that the object knowing information about the call and controlling the execution is the Call.  Its temporary existence matches the real-world situation, it can provide the services that are need by the system (as I understand them) and none of the other (more persistent) classes need concern themselves with that "call" information or methods.


Uml Process / Re: collaboration diagram problem
« on: April 01, 2004, 03:48:03 pm »
I have sent you a diagram directly as I cant post to a website from here. If you would stick it up here I will discuss it.

Uml Process / Re: collaboration diagram problem
« on: April 01, 2004, 01:58:00 pm »

Yes, I think that you could do it that way. In fact I see no problem with including the class on the collab diagram if it adds clarity.  I have, as a matter of fact, one interaction in a system that we had been "discussing" for several days trying to decide where a particular object should be created. (A trivial and pedantic exercise perhaps, but the issue was fairly germaine to the design approaches (and architecture principals) that we were proposing.  The minute we plonked the class element into the diagram the real issue crystalised - it was a mismatch in assumptions made by the group as to what the attributes of the class were going to be.  As soon as this was resolved the class element was removed again and the "published" interactions rewritten to remove the ambiguity.

In general though, I find no problem with putting the paramters on the messages and the way EA lets me display the paramaters as either caller attribute names or callee types gives great flexibility.


Uml Process / Re: collaboration diagram problem
« on: March 31, 2004, 04:39:15 pm »
using parameters on the message

1.1 allocateClerk (CustID)


using return value and parameters on the message
1.1 Customer.Allocated=allocateClerk(CustID)


1.1 Clerk.Busy=Clerk.Allocate(CustID)

or even
1.1 Cutomer.AllocatedClerk=Clerk.Allocate(CustID)


Uml Process / Re: tech spec
« on: April 07, 2004, 03:29:14 pm »
The flow we use here, as we gradually move away from legacy methods is:
    [1]Requirements Spec
    [2] Analysis Spec
    [3] Design Spec

Of these I guess our anaysis spec (actually called the Analysis Survey hint hint) is the closest to what you mean by the Tech spec.
It contains the conceptual or logical or "high" level interpretation of the requirements and can include:
  • a Logical Behavior model, containing collaboration syle analyses for each use case implemented in the release
  • an Analysis Class model, containing the "real world" level classes (i.e. before any patterns or other technical concepts are introduced) that arise from the behaviour model
  • (optionally, if warranted by specific issues) state machine breakdowns for interesting classes and sequence diagrams for any interesting behaviour
  • if warranted, a conceptual persistence model - preferably done in "crowsfeet" technique as the business people can understand the issues that are being discussed.
  • optionally, if helpful, we include conceptual architectural models such as component and node diagrams to assist in the resolution of issues.

Now here's the rub... We do not insist that the analysis survey be a mandatory project deliverable.  If the nature of the system or system changes can be adequately resolved by moving directly from the requirements spec to the design spec, then we dont consider that the analysis survey adds any great value to the process.

It is used to assist in the development of the design.  That is, to explore technical options or issues at a conceptual - and often business - level.  

The design spec OTOH is fairly left up to the designers and developers.  The only mandatory item is the design class model, which we insist includes reasons why ccertain design decisions were made as these often are real at a particular time and fade later.


Uml Process / Re: Use Case - regarding the systems memory...
« on: April 01, 2004, 02:26:36 pm »
so the chef can not choose that option again  

Then it sounds like an expressed requirement and therefore the inclusion represents the proposed solution to the requirement. Therefore it is a design level aspect. Therefore:
if you are using the use cases to reiterate the design aspects back to the stakeholder put it in the use case,
otherwise (if you are trying to be pure) I would tend to put in an action diagram associated with the use case.

In our courses, we talk about an iceberg "view" of our standard inhouse UML models.  Only 20% of the iceberg is above the "waterline" and that is the material we make sure that the non-technical reader can understand.  In that  20% we focus on the business issues and (try to) keep any technical jargon or technical issues out.  We also try to be "pure" in this area so that business level models across teams have a similar flavour - thus lessening the confusion amongst the natives that could occur when two different IT teams present business level models in different UML "dialects".

"Below the waterline" is a different matter.  We use UML as a tool to solve design problems.  Flexibility in usage, adequately explained, gets us to the desired result - an unambiguous expression of the system design.  

Now, before you start on "to a man with a new hammer - everything is a nail" let me explain.  You (Ian) seem to be working very much below the waterline with your use cases.  The points you raise are relevant both in terms of usage and  content.  In your environment I see no reason to constrain yourself to "pure" usage.

However, remember this.  Your models will be used later than you intend.  Either by others who have to support your grand design in operation or by yourself sometime when you look at your system and think "Why the bloody hell did I do it that way?".  So when you have solved all your design issues, go back and edit the models into a formal "above the waterline" view and a formalised "below the warterline" view.  Do not let them tell you there is no budget for this.... (no I'd better not get into that argument - its bleedin obvious why there should be a budget for it and what happens if ther isn't).

hmmm - I seem to have strayed somewhat from the original issue here.  So what, its Friday here and I'm not going to recant - so there!


Uml Process / Re: Use Case - regarding the systems memory...
« on: March 31, 2004, 03:49:57 pm »

Why is it important to state that the system hides the "Set Program" thingy?  Do you have some issue with that step you want to explore further?  Does it add value to the process? OTOH Does it detract value from what you are trying to describe?

.... or are you just trying to remember that the design models have to include that step?  ;)


Uml Process / Re: Use Case - regarding the systems memory...
« on: March 31, 2004, 03:42:54 pm »

C-SUC! Where do I join? :)

Ian and Thomas' original thread (and others that I have joinned into) are very much associated with that wonderfully grey area - moving from requirements gathering into analysis.

One thing we have talked about/around is how use cases are used to explore what the Analyst doesn't know about the system (or the requirements) and how the textual content can be used to bring these things to the Anlysts attention.

By writing down - as detailed as necessary at the time - the inner workings of the use case I am very frequently surprised at how many assumptions I make as to how it will work.  My typing (and retyping) speed probably helps here :) as I have time to think through each step of the use case and what it means.

However, it is certainly true that this can often be taken too far - and we (all) start designing the system inside the use case!

I wish I knew a way to "ring the oven bell"  when the use case is sufficiently cooked.  The only guideline I have is to go back to the specifier when I have 3 to 5 questions at the scenario level and certainly before I have more than 7.

As you say, many times the answers to the questions are material to the UML design artifacts, not the use case models.

One of the things that I think is great about EA is the Maintenance Items. It is where I record these questions and their answers - and manage the changes to the other models.  Our standard doco's are set up as virtual documents and all include element defects, issues etc so these things dont ever go away until they are fully resolved.


Uml Process / Re: Use Case - regarding the systems memory...
« on: March 31, 2004, 03:25:25 pm »

Yes and no.  My point is, and has been through previous threads on use case textual content, that at the end of the day you cannot completely ignore the systems exisitence in describing use cases and use case scenarios.  After all the desired behaviour of the system is what we are trying to explore here.  To be even more specific, it is the behaviour of the system as perceived by the involved actors (both initators and subscribers).

Continuing the oven metaphor, review the "good form" scenario.  Lets say that the initiator, the chef, is reasonably concerned about certain facets of his new oven and is diligent in the review of the scenario.  At first review, yes it looks like what he has specified and perhaps raised his curiosity as to what the control panel interface will look like.  That is, I have written the scenario in a manner that raises interest (queries, concerns, panic?) in exactly where I want him to go next in our requirements gathering sessions.  He is focussed on the interface not on the internal design and operation of the software that will control the oven.  I strongly believe in getting their attention away from the internals and back to the interface as early as possible.  Otherwise, we end up with user requirements that constrain the internal design of the system.  An example of what I mean:
The oven shall implement all prompts and other textual displays using an external resouce file that can be loaded at the point of manufacture so that the oven can be built and sold in more than one country

"Aargh!" He's not only constraining architecture and design but also the implementation process, regardless of whether we could build the damn thing anywhere using a global resource file and -perhaps- make the language end-user selectable.

But, back to the interface...
Where I want the specifier to go is into further detail about the requirements.  By getting into the interface we can focus him/her yet again on what they percieve and not on "how" the system does it.  For example, I have the following questions I want answered in this session:
1) 12hr/24hr clock display? Requirement or doesn't matter?  
2) Date rollover?  Do you want to start the oven at 23:45 and end at 01:15 for example?
3) Degree of accuracy of the temperature setting display? 1o, 5o, etc?
etc etc
Oh, and I have one last issue to raise with him.
While the oven is actually cooking, do you want some indication that it is "Regulating the Cavity Temperature"?


Uml Process / Re: Use Case - regarding the systems memory...
« on: March 30, 2004, 03:09:23 pm »
Woah there guys!

There is no law against talking abut the system in a use case.  The only "law" is to talk about the use case from the user's perspective - not the systems perspective.

The intent is to describe what the user is trying to achieve through the system in a manner that
1) is comprehensible to non-technical readers
2) does not constrain design of the system by prescribing technical details (unless they are real requirements)
3) relates a single use of the system by (a single or set of) users that achieves an outcome of value to the user.

Consider the use case "Cook Dinner" which uses the system "Automatic Oven".

Bad form - The Cook Dinner use case begins when the user invokes the Set Parameters extension use case and ends at the completion of the include use case Heat Cavity.

Good form - The Cook Dinner use case begins when the cook has prepared the ingredients and placed them in the oven cavity and ends when the cooked meal is removed from the oven for serving.

In the good form we have set the scope of the use case in a manner that is clearly understandable by the user - all actions and reactions by the system between these two points are what is covered in the use case

Scenario (Basic):  
Bad form - 1. The chef sets the parameters of the system relating to the proposed cooking session through the user interface elements. The parameters accessible are limited to Session Start Time, Session End Time and Target Cavity Temperature.
2. At the trigger event fired when the Session Start Time is reached, the system initiates the Regulate Cavity Temperature(Target Cavity Temperature) system include use case.
3. The Regulate Cavity Temperature use case executes in a synchronous manner until the trigger event fired when the Session End TIme is reached, when control is returned to this use case.
4. System invokes the Ring Bell extesion use case.

Good form - 1. The chef selects the Set Program action on the control panel.
2. The system prompts the user for the desired cooking temperature on the control panel display.
3. The chef sets the temperature using the digital input panel.
... the other parameters ...
6. When the Session Start Time is reached the system begins heating the oven and controls the cavity temperature close to the desired temperature until the Session End Time is reached.  (Further detail is explained in the included use case - "Regulate Cavity Temperature"
7. The system alerts the chef that the session is complete by ringing a bell.

(I believe the good form adequately describes the fact that the system has remembered certain parameters of the operation without having to resort to technical language)

I believe that Intent 1 is met.
I believe that the technical constraints that the specifier wanted (digital control panel) are adequately expressed
without limiting design freedom.  Even though I did mention a functional decomposition of the control panel into the display and input sub-components.
I believe that the use case description and scenario presents a complete case of value to the user.

I also reckon that the use case is fairly well expressed to provide a framework for technical analysis and design work to follow - and thats where we will start discussing the things in the "bad" forms above.


Uml Process / Re: Aggregation overload! - in domain model
« on: March 25, 2004, 03:29:08 pm »
Well explained!
As a matter of fact I have been looking for a succint explanation like this for our training material.  So I hope you wont mind if I pinch it!  ;D

The only thing I would add is that weak aggregations in diagrams can also help to highlight multiplicity (i.e owner attibute is a collection).


Uml Process / Re: Domain Modeling in the ICONIX process
« on: March 18, 2004, 02:19:12 pm »
As  understand it, the domain model is "sort of" a differnet view of the business model.

The business model is used to gain insight into the wider scope of the subject system and its use within the organization.  At this level, we see the business process elements and the business organizational elements that "have some visibility" of the system.  

The business model is essentially behavioral even though it contains structural elements - we see organizational structures and high level business processes, and perhaps some actual roles played by actors that are particularly pertinent.

The domain model is the first cut at the structural composition of the organization. However its scope is bounded securely by the "system" under discussion.

Lets see if we can generate an example - say a retail wine distributor developing an online store ;)

We may need to model the business to see how the proposed web site will "fit" into the business.

The company organisations that are involved with the system somehow are:
The warehouse who will be dispaching the wine to customers.
The accounts department who will have to be notified of accounts receivable items (for credit card sales), inventory changes (for restocking and licence/excise matters).
The management will want measurement of sales made through the site.
The marketing department may want measurment of the types of sales made so they can plan what to push etc.
The "art" department may need to be involved in keeping the page "attractive"
The IT department (never forget this one and never leave it out as being too obvious) who have to run and support the site.
There are communicates and subscribes associations between these structures and the "system"
We use this model as a checklist with the business to make sure that no-one is forgotten in the requirements and analysis stages.

Now from that model we can start to derive the set of business objects that are salient to the system:
Order (we may even see at this point that an order appears to have states of "Open", "Authorised" and "Filled".)
Customer (aka "Deliver To")
etc etc

No really detailed fleshing out of these elements is needed - they act as placeholders for discussions with the business, say as in "Do you want to keep records on every customer that buys through the wine site? Lets talk this through and see what impact it will have - and what issues are raised."

Sometimes you need a business model, sometimes not.
Many times I see analysts attempting to avoid domain models - again, they are not really "compulsory" but add a great deal of value, at the least the provide a checklist that can be used to validate the rest of the requirements view and the analysis view.


Uml Process / Re: Model Change Management
« on: March 03, 2004, 01:15:39 pm »

Is your question aimed at the technical issues, which Marcello has answered, or at the procedural level?

If the latter, then there are many ways to achieve a result.  

The way we are moving new analysts into UML thinking is to use "as is" and "to be" models of the system.  We encourage them to keep both models very separate at first so they do not modify the wrong one.

EA provides several great features to asist "logical" change management - of these we emphasize use of the Maintenance Menu items - Element Defects, changes, Issues and Tasks the most.  This lets us pre-model the changes to the existing system, discuss that work with the users and when the "release" has crystalised in scope we then create a new model using the existing model as a base and begin work on requirements, analysis and design.  

Another feature we use is use cases stereotyped as <<changecase>> which highlights the impact of a change on the business use of the system, and provides a context point (in the 4+1 paradigm) for the changes to the system that will occcur in this cycle.

Finally, do not underestimate the use of the Phase and Version attributes in EA - they can be used in many of the reports and utilities to filter appropriately to the elements of interrest to a particular release.


Uml Process / Re: Business Model
« on: March 01, 2004, 02:36:31 pm »
To be "traditional" about things....
The business model is a contextual model.  It is produced to ensure that the design team understand the business processes that the system is to support.
The salient issues are coming to terms with the real world constraints that apply to the requirements, often eliminating those "why do it that way" errors.
If the business constraints are understood, eg authorisation policies, need for process controls etc and the business level objects are evident - i.e. all business artifacts are disclosed, then business models may not be "necessary".
In your cited case, where the business processes are not formulated business modelling is more likely to assist than hinder.  You can treat the exercise as a simple business process re-engineering exercise, perhaps using existing client processes as the "as is" model, drafting up a "to be" process involving the web idea and walking through the models to ensure that the client is aware of the differences that the introduction of the system will bring.
By way of a complex example (the only one I can think of at the moment) I was several  years ago involved in the quality assurance of a large integrated stockbroking system.  When we investigated how the system was designed to process diary updates on the various stocks (ex-dividend dates, dividend pay dates etc) something didn't ring true.  I followed up the actual business process with the SME concerned and found that she had not been consulted regarding that functionality, which was implemented using a data feed from the exchange.  We modelled the process and she informed us that it was useless as the data feed notified the broker of the diary event on the day it occurred - not 2 weeks earlier as  needed for the (business) system.  This meant that the entire diary subsystem needed to be redesigned from scratch as the developers had assumed that the automatic feed would take care of all the data entry.  
These are the types of mistakes that can be made if "not enough attrention" is paid to the business process modelling of the system early on.
Personally I advocate the use of the Erikson-Penker UML extension (as supported by the EA profile) which lets us model the objects, events and macro data flows of the business without having to understand the nitty gritty details of the process itself.  That is the process is represented as a single element, no process pathways etc are needed.  Resources and information elements are the key objects and initiation and outcome events can be simply modelled with the analysis diagram Receive and Send pennants.


Uml Process / Re: Categorizing Requirements
« on: March 08, 2004, 03:14:39 pm »

F(unctional) - yeah, we use it
U(seability) - bah! gives users a chance to impose design constraints!
R(eliability) - we dont see such a need to delineate these particularly from other supplementary requirements
P(erformance) - yeah, we use it - fairly common thing that users think they can express correctly "The system will have sub nano-second response times for all functions"
S(upportabilty) - have not yet come across a system that needs to express a supportability requirement other than "The system will be fully supported by the IT department" ;)
and as for the "+" things, they are the things we typically classify as "Constraint" in our models .

Pages: 1 ... 87 88 [89] 90 91 ... 94