Objects by Design Forums Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home  
Objects by Design Forums : Powered by vBulletin version 2.3.5 Objects by Design Forums > Main Forums > UML Questions > UML: What is/r the most significant UML diagram(s) of an appl. to the eye of S.A.
Pages (2): [1] 2 »   Last Thread   Next Thread
Author
Thread Post New Thread    Post A Reply
Paul
Junior Member

Registered: Sep 2003
Location:
Posts: 13

UML: What is/r the most significant UML diagram(s) of an appl. to the eye of S.A.

UML: What is/are the most significant UML diagram(s) of an application to the eye of a Software Architect?

Hi All,

They say "Beauty is in the eye of the beholder", so to say this or that UML diagram(s) is/are the most important to a Software Architect is tough because every one may have different experience. However, is there a common agreement among them (S.A) on which is or are the most significant UML diagrams of an application to say whether the app is well-designed?

Basically, how would a S.A know if an application is well designed by just simply looking at the UML diagram alone? Of course, there are many factor involved. However, for my question here is that 'ONLY' UML diagrams are available, so which UML diagram(s)
would a S.A look at first to conclude that it's well designed?

1M Thanks.

__________________
A Picture is Worth a Thousand Words.

Report this post to a moderator | IP: Logged

Old Post 09-04-2003 09:42 PM
Paul is offline Click Here to See the Profile for Paul Find more posts by Paul Add Paul to your buddy list Edit/Delete Message Reply w/Quote
ipreuss
Member

Registered: Mar 2003
Location:
Posts: 43

I am not an architect, but I guess Collaboration diagrams would be the most telling, followed by Class diagrams.

Why do you ask?

Report this post to a moderator | IP: Logged

Old Post 09-07-2003 10:03 AM
ipreuss is offline Click Here to See the Profile for ipreuss Click here to Send ipreuss a Private Message Find more posts by ipreuss Add ipreuss to your buddy list Edit/Delete Message Reply w/Quote
sargasso
...

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

This seems to me like asking "which wall in your house is the most significant?"

"Well designed" can have many meanings, I would assume that the question you are asking is "How can the SA determine, by inspecting UML diagrams alone, that a particular application meets the client organization's generalised requirements for application design?"

Which of course opens up the question of the mandate that the client organization has given the architecture group.

If for instance, their mandate is to determine that applications are implemented using approved technology options then the most significant diagrams are those in the component model.

If their mandate is to ensure that applications are implemented in operationally manageable configurations, then the deployment model diagram(s) need to be understood and verified.

If the architectural mandate is to ensure that "robust" design standards (patterns?) are employed then the (UML extension) robustness analysis models come into play.

If the mandate of the architect is to police the code design and build to ensure that they conform to published organizational standards then sequence, class and component diagrams would provide the likely evidence. (Note: there is always a danger that "architects" decline approval of a design if it doesn't meet their personal ideas of good design in this area. Therfore they must use published and agreed standards at this level and be prepared to approve architectural exceptions (well documented of course!).)

Have I missed anything? Oh yes - if the mandate of the architect is to confirm that the design meets user requirements then correlating all of the above to the use case models would be the first point to check.

Data models - no. Confirmation of data models is the data architects job and they should be using a similar approach.

Finally, IMHO the most important diagram that the SA should check first is the system context model asking one question - "is it complete?" If the system's set of interactions with the outside world is not described completely then the remainder of the design is highly likely to be incomplete.

rgrds
Bruce

Report this post to a moderator | IP: Logged

Old Post 10-07-2003 11:13 PM
sargasso is offline Click Here to See the Profile for sargasso Click here to Send sargasso a Private Message Find more posts by sargasso Add sargasso to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

The most important artifact may very well not be a diagram!

Over time, I have found well-written Use Cases (yes, textual) to be one of the most important artifacts. By Use Cases, we mean the type that Craig Larman describes in his book Applying UML and Patterns. They are so important because they are the beginning of the UML process that Larman describes. Without good Use Cases, you don't have a process (unless you use XP ).

The next most useful artifact is the Class Diagram. Take a look at Robert C. Martin's Agile Software Development to see many excellent examples of using class diagrams effectively to explain design patterns.

Report this post to a moderator | IP: Logged

Old Post 10-08-2003 01:29 AM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
ipreuss
Member

Registered: Mar 2003
Location:
Posts: 43

quote:
Originally posted by SZ
The most important artifact may very well not be a diagram!



I guess we all agree - the OP specifically asked for diagrams, though... (I still wonder why!)

quote:
Without good Use Cases, you don't have a process (unless you use XP ).


Which of course means that *any* process can do without use cases if it replaces them by other means to know about the requirements...

(Alistair Cockburn once called XPs User Stories "2 Bit Precision Use Cases" - I am not sure whether I agree. See http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison)

Report this post to a moderator | IP: Logged

Old Post 10-08-2003 04:57 PM
ipreuss is offline Click Here to See the Profile for ipreuss Click here to Send ipreuss a Private Message Find more posts by ipreuss Add ipreuss to your buddy list Edit/Delete Message Reply w/Quote
ipreuss
Member

Registered: Mar 2003
Location:
Posts: 43

quote:
Originally posted by sargasso
This seems to me like asking "which wall in your house is the most significant?"


Or like "which is more important to assess the healthiness of a human-being: the ECG, the radiograph or the hemogram?"

quote:
Note: there is always a danger that "architects" decline approval of a design if it doesn't meet their personal ideas of good design in this area. Therefore they must use published and agreed standards at this level and be prepared to approve architectural exceptions (well documented of course!).



Personally, I wouldn't like to work in a company where the SAs job is that of a "design police". I'd rather like the architect(s) to give *valuable feedback* regarding the design to the development team(s). And for that, I'd think, personal experience is much more valuable than standardized documents. After all, every project is different, with different needs, different forces etc. impacting design decisions.

Your mileage may vary, of course...

Report this post to a moderator | IP: Logged

Old Post 10-08-2003 05:24 PM
ipreuss is offline Click Here to See the Profile for ipreuss Click here to Send ipreuss a Private Message Find more posts by ipreuss Add ipreuss to your buddy list Edit/Delete Message Reply w/Quote
sargasso
...

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

quote:
Personally, I wouldn't like to work in a company where the SAs job is that of a "design police". I'd rather like the architect(s) to give *valueable feedback* regarding the design to the development team(s).

True, very true. However, in many commercial situations the architects have, for reasons that are valid or not, been mandated with sometimes poorly defined design approval authority. I was (unfortunately very obliquely) trying to point out to Paul, the dangers and care that must be exercised by an architect so that they dont fall into the category of the "design police".

There is nothing inherently wrong with the architect checking that a design meets a standard, concept or policy that is well though out and presented in an organization as "the way we do things here". Each organization usually has good reasons for opting to require that software conform to certain facets of design constraints. For example, financial organizations need to conform to both their own and externally imposed privacy, security, prudentiality and ethical policies and regulations in their software design. I would not expect each and every system designer in such an organization to be aware of the breadth and nuances of each of these areas. That is not their field of expertise. The architect on the other hand should be aware of the design constraints raised through these factors as they have been decided on in that organisation and as you say provide valuable feedback as to the impact of these factors on the current system design.
quote:
And for that, I'd think, personal experience is much more valuable than standardized documents. After all, every project is different, with different needs, different forces etc. impacting design decisions.

I may have given the wrong impression here. I was not talking about the document itself when using the term "published". I was using the term in a sense of state, i.e. a standard (either internal or external) may be in the states of "preliminary", "draft", "proposed", "published" and "obsolete" where "published" means "in use".

Most certainly, every project is different but the above still holds true (IMO at least) - if an organisation has decided to adopt a level of standard for certain facets of system design and the architect has been given the responsibility to ensure that a specific system design conforms to those standards then this is what they must do, regardless of whether the outcome of the activities that the architect undertakes to ensure conformance is an exception request + approval, guidance and mentoring and provision of "valuable feedback" or (at the last resort and given that the architect has been granted the authority as well as the responsibilty) denial of design approval.

The point I am trying to get to, via a long pathway, is that conformance checking is not properly done by an architect looking at design models (or diagrams only) without having a set of reference points on which to base their decision as to whether a particular design is "good" or not.

I have been in situations where I have been asked "is this design good" - without having the relevant reference points - and been expected to give a professional (and guaranteed) opinion. Now they are organizations that I do not like to work with!
rgrds
Bruce

Report this post to a moderator | IP: Logged

Old Post 10-09-2003 12:15 AM
sargasso is offline Click Here to See the Profile for sargasso Click here to Send sargasso a Private Message Find more posts by sargasso Add sargasso to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

To get back to the importance of Use Cases - I will go a step further and say that the role of the Business Analyst (BA) should be emphasized more on OO projects. What I mean by BA is a person highly skilled in requirements gathering through interviews and elaboration meetings who can generate high quality Use Cases (Larman style). Later in the SDLC the BA should be able to transition over to the QA phase and generate Test Scripts from the Use Cases. Automated tools for this would help a lot; for this to happen Use Cases should be in XML and tools should translate them to the framework for Test Cases. Finally, the BA's should be directly involved in functional system testing since they are closest to the the Use Cases and understand the system well from a functional, end-user perspective.

Where is the training for this role? It doesn't really exist. The industry should start to focus on this role in order to make it well-defined. That would help the SDLC significantly.

Do others out there see the same requirement??

Was Ivar Jacobson right all along?

Report this post to a moderator | IP: Logged

Old Post 10-09-2003 11:21 AM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
ipreuss
Member

Registered: Mar 2003
Location:
Posts: 43

Bruce, we seem to be on the same page...

quote:

I have been in situations where I have been asked "is this design good" - without having the relevant reference points - and been expected to give a professional (and guaranteed) opinion. Now they are organizations that I do not like to work with!



I agree - although I have seen many designs I could have asserted as bad without having any reference point...

Report this post to a moderator | IP: Logged

Old Post 10-09-2003 05:48 PM
ipreuss is offline Click Here to See the Profile for ipreuss Click here to Send ipreuss a Private Message Find more posts by ipreuss Add ipreuss to your buddy list Edit/Delete Message Reply w/Quote
ipreuss
Member

Registered: Mar 2003
Location:
Posts: 43

quote:
Originally posted by SZ
Where is the training for this role? It doesn't really exist. The industry should start to focus on this role in order to make it well-defined. That would help the SDLC significantly.

Do others out there see the same requirement??


Yes, certainly!

XP, for example, requires that the team has a Customer integrated. The person(s) filling this role should have both the expertise and the authority to make business decision - that is, decide about what the system should do, priorities etc. The Customer has also the responsibility to define (and preferably also somehow write) the acceptance tests.

The Customer team might well include one or more BAs, preferably helping the "real customer" or even a user find out about and formulate his needs.

It is well-known in the community that finding such a Customer is both hard and worth it. "Training the Customer" is a recurring theme at discussions. Unfortunately, I haven't seen a good solution till now...

Report this post to a moderator | IP: Logged

Old Post 10-09-2003 06:05 PM
ipreuss is offline Click Here to See the Profile for ipreuss Click here to Send ipreuss a Private Message Find more posts by ipreuss Add ipreuss to your buddy list Edit/Delete Message Reply w/Quote
sargasso
...

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

Aha! One or two of my favorite topics.

I cannot agree with the scope of the role you have assigned to the business analyst. To my way of thinking the role should be constrained to "understand and communicate the business needs regarding the system as they relate to technology solutions." The role requires an ability to both understand and record (model) the business processes that an organisation uses, an ability to synthesize new or changed business processes that take advantage of technological advances implemented in the organization, an ability to understand (and often question) why the organization follows a business process, the ability to understand the environmental conditions that the organization does business in (and/or plans to), etc etc.
In other words the BA role is a lot "higher" than the role you have described. Your role is what I (and RUP) would call the Systems Analyst with the following caveats.
1) Analysts/Designers/Developers make lousy testers! Their roles are driven by the need to abstract a complex business situation into a deliverable partially generic technology solution. Testers on the other hand need to be able to isolate the required number of specific business complexities to prove that the delivered system meets an agreed level of business need. That is, they do the exact opposite of the analyst/designers.
2) Use cases provide only the first level of the test framework In anything but trivial systems the complexities mentioned above do not always lie within the uses cases, very often they lie between them. By way of example consider this. In the futures industry (in Oz at least) clearing a trade between the market and the broker involves three use cases, "accept", "assign" and "split". accept means that the broker removes that parcel of contracts from the clearing pool to assign to one (or more) of their clients. assign means passing a parcel on to another broker and split means splitting a parcel possibly extended by subsequent accept and/or assigns. However, there are different classes of brokers involved in the market - "clearing", "non-clearing", "local" etc. The business rules affect how accepts and assigns may be done between the brokers. These rules result in a mathematically provable set of over 70 pathways that trades could go through in the clearing. Each one of these pathways has to be tested - not just the 3 "functional requirements" represented by the use cases. Further the pathways are "temporal" in that the exact sequence of the transactions is important. UML in general and use cases in particular do not provide a means to model the pathways, nor was there a need to in specifying the system requirements or design - only the testing needed this model as only the testing is concerned with the complete flow of the trade through the system to its final clearance.
For a less challenging analysis, consider the testing needed for these common retail system use cases "cancel credit card transaction" or "process credit purchase return" and the possible variations on that that can exist. If the mental challenge is to high go buy 4 items on your card but do it in two transactions of two items, now go back and return one item from each transaction!!! Now consider what the analyst/ designer is trying to do in this situation - "how can I simplify this to make it workable?" Finally, what does the tester have to think about in designing a test suite - "OK the customer is returning one, or perhaps more than one, item they bought on credit. Lets see, how could we have arrived at the sale of these items? One sale, more than one sale, the return is for the entire set of items sold in the transaction, its for a partial set, does the original transaction(s) exist, is this relevant, was one or more of the original sold items discounted" etc etc etc notice I haven't even started to think about the current transaction i.e. the credit refund and its possible variations yet! and finally note that the refund use case code (usually) does not care about the initiating transaction set.
So IMHO use cases by themselves provide at best a flimsy framework for testing.
rgrds
Bruce

Report this post to a moderator | IP: Logged

Old Post 10-10-2003 12:38 AM
sargasso is offline Click Here to See the Profile for sargasso Click here to Send sargasso a Private Message Find more posts by sargasso Add sargasso to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

quote:
Analysts/Designers/Developers make lousy testers!


I disagree. Developers make very good unit testers (if trained and managed properly). And Business Analysts make very good functional testers. That is why I prefer to have the Use Case modeling done by a BA and not an SA. At least here in the USA an SA is closer to a programmer (who I agree cannot do the functional, business rules testing), whereas the BA is much more attuned to the business owners' requirements (after all, they sat through hours of elaboration meetings).

quote:
Use cases provide only the first level of the test framework.


Your contention doesn't account for the alternate paths that are so well understood as being core to Use Case analysis. In a recent project we had an excellent Use Case analyst and the developers coded directly from the Use Cases. Every path was accounted for in the Use Cases. From a functional testing point of view, you could have compiled the complete list of test cases from the Use Cases (if only there was a UC-XML ).

Report this post to a moderator | IP: Logged

Old Post 10-10-2003 02:46 AM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
sargasso
...

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

quote:

Your contention doesn't account for the alternate paths that are so well understood as being core to Use Case analysis.


My contention is exactly that neither basic nor alternate paths cater for what happens between use case executions. Nor do they cater for sequences of use cases. Indeed by definition and by common comment here and elsewhere they cannot and should not. UML is silent on the topic of inter-transaction dependencies and on so-called history models. Don't forget that I'm not talking object state machines here, the information lies in the temporal pathways between the transactions and how these transactions occurred over time.

Sure, the futures exchange system could have been modelled at a slightly higher business level where each use case described a single temporal pathway. But to what end? The system still needed to be designed and built using the three single actor, single transaction use cases. And would modelling at the history level be a natural thing for the RE to do? Not likely, the single transaction level is all that is required for analysis and design and the single transaction level is intuitively obvious to an RE with industry experience.

So an analyst and designer would not intuitively look for and attempt to prove that there are exactly 76 permutations of transaction history that the system had to work correctly for.

Similarly, the retail case histories again do not lend well to use case specification.
quote:
Analysts/Designers/Developers make lousy testers!
I suppose I should have expected a bite on that one!
I have no doubt that a development trained and focussed person can be retrained as a test specialist. Indeed, I are one! My point is that it does take a change in mindset and purpose... and a conscious willingness to be a tester and not a developer in that realm.
On the topic of domain experts (BA's) who have been involved as RE's on projects rejoining the project as a tester I recall a statistic I read a few years ago on the number of test cases missed by people who are too familiar with a system to "see the gaps" that a naive (systemwise) user will walk straight into. I am sorry I cannot recollect where the statistic was quoted or what the exact value was but it was disturbingly high. This is not to denigrate SMEs as testers, just that a fresh viewpoint often reveals things - and ways of doing things - that are completely invisible to knowledgeable users. Many years ago I worked on a bond trading system that required that the user cancel a transaction set by manually reversing up the original sequence. It never occurred to us to check that doing it in any other order would break the system. Indeed the system was in use in 8 different clients for over 5 years before someone managed to achieve the "impossible" - reversing the trades in a different order than they happened - leaving the database corrupted and several $m of negotiable bonds "locked" in the system without an associated owner. The client asked us why we hadn't tested for that possibility, our answer (which he accepted after thinking about it) was that it never occurred to us developer types that someone would be dumb enough to cancel a sale without re-allocating the bonds back into the pool first. There was no business rule that said it had to be done on that order (when you think about it it is a system imposed rule not a business one). There was no requirement expressed for the system to prevent such an occurrence... and the system didn't prevent it. But it sure taught me the value of testing beyond the rules and requirements set down.

rgrds
Bruce

Report this post to a moderator | IP: Logged

Old Post 10-10-2003 04:26 AM
sargasso is offline Click Here to See the Profile for sargasso Click here to Send sargasso a Private Message Find more posts by sargasso Add sargasso to your buddy list Edit/Delete Message Reply w/Quote
Paul
Junior Member

Registered: Sep 2003
Location:
Posts: 13

Gentlemen (Bruce, SZ, ipreuss)

I've 2 questions:

1.

Without having a complete and comprehensive look at the requirement as a whole,
it's hard or even impossible to evaluate objectively whether the UML diagrams are indeed well designed for any given required system
inspite of the fact that we're 'likely and perhaps systematically' in favor of commonly named diagrams such as Sequence, Collaboration and Class diagram and SZ's Use cases as well.

quote:

<SZ>
The most important artifact may very well not be a diagram!
</SZ>




Question: Am I correct? in summarying the underlying thoughts of your discussions.

2.
quote:

<ipreuss>
Personally, I wouldn't like to work in a company where the SAs job is that of a "design police". I'd rather like the architect(s) to give *valueable feedback* regarding the design to the development team(s).
</ipreuss>

<sargasso>
True, very true. However, in many commercial situations the architects have, for reasons that are valid or not, been mandated with sometimes poorly defined design approval authority. I was (unfortunately very obliquely) trying to point out to Paul, the dangers and care that must be exercised by an architect so that they dont fall into the category of the "design police".
</sargasso>



Question: What do you guys thinks about this link?
who Needs Architect by martinfowler

__________________
A Picture is Worth a Thousand Words.

Report this post to a moderator | IP: Logged

Old Post 10-10-2003 07:26 PM
Paul is offline Click Here to See the Profile for Paul Find more posts by Paul Add Paul to your buddy list Edit/Delete Message Reply w/Quote
sargasso
...

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

Re 1. I'd only make the following change to make it even more explicit:
"Without having a complete and comprehensive look at the business environment, requirements and constraints for a system as a whole, it's hard or even impossible to evaluate objectively whether the UML diagrams are indeed well designed for any given required system"

Re 2. I'd read this article some time ago while in a different frame of mind. On re-reading it I believe it does capture some of the problems we have been discussing here. However, in doing so Martin is refining a specific role definition for the SA, and a definition that does not fully resolve our focus problem.

Pragmatically, the title "system architect" remains applied across a much wider and less well defined set of roles and responsibilities. Some of which we have discussed here.

Paul, to refocus this thread back to your original question, are you looking for a specific answer to what I have assumed is a fairly specific (and horrid) position - being asked for a design opinion without both adequate design information and adequate "problem definition". If so, perhaps more detail of the situation would let us answer a bit more specifically.

Alternatively, in your summary definition you may have slightly changed our tack. Your phrase "whether the UML diagrams are indeed well designed" may be conveying a different meaning to what I thought your original focus was. If so, my answer would be a lot simpler: Do they convey the required amount of information to their intended audience?

We model for two reasons, firstly we model individually as a technique (or step if you prefer) in the problem solving mental process. I'll try and explain this process as consisting of four co-inciding, iterative and overlapping activities: familiarization, abstraction, synthesis and realization. In the familiarization activity we seek and collect information about the problem at hand, in abstraction we model for our own personal benefit to record the abstracted knowledge about the problem we have discovered, in systesis we "create, discover or invent" a solution to the problem - and perhaps model it again for our own benefit -, finally we realize the solution, in this case as a system design "specification". And this last activity is the second reason to model, in order to convey the "answer" to other humans in a format that they can assimilate in order to come to the same understanding as the modeller. Ipso facto, if the models enable the intended audience to come to the same understanding of the solution as the designer then the model is "well designed" (assuming of course that the solution is feasible!)

rgrds
Bruce

p.s. One of the "models" I personally hate is the xxx Strategy Document. A strategy usually has such a large audience of people with differing individual foci that a satisfactory communication usually tends towards the impossible to achieve end of the scale!

Report this post to a moderator | IP: Logged

Old Post 10-12-2003 11:50 PM
sargasso is offline Click Here to See the Profile for sargasso Click here to Send sargasso a Private Message Find more posts by sargasso Add sargasso to your buddy list Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 01:20 AM. Post New Thread    Post A Reply
Pages (2): [1] 2 »   Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 

< Contact Us - Objects by Design >

Powered by: vBulletin Version 2.3.5
Copyright ©2000 - 2018, Jelsoft Enterprises Limited.
Copyright 1999-2005, Objects by Design, Inc.