Analysis vs design

[Pradeep bhatt]

Hi all,
Whats the difference b/w analysis and design ?
Can one explain with examples ?
thanx in adv
pradeep

[Frank Carver]

In the simplest terms, analysis is finding out what needs to be done, design is deciding how to do it.

[Vikrama Sanjeeva]

Hi,
However Frank has already cleared.Here a bit different way of differentiating b/w two.
Analysis:What a System must do?
Design: How a System do?
Or
In Analysis we emphasizes an Investigation of the problem.
In Design we emphasizes on Logical Solution of the problem.
Hope it clearifies.
Bye,
Viki.
[ September 10, 2002: Message edited by: Vikrama Sanjeeva ]

[Pradeep bhatt]

What are the steps involved in analysis ? I want to know how do I understand the problem.
What do we do in design.
If analysis is understanding the system, then what do we do during Requiremets capturing time?
Please some one reply to my questions.

Originally posted by Vikrama Sanjeeva:
Hi,
However Frank has already cleared.Here a bit different way of differentiating b/w two.
Analysis:What a System must do?
Design: How a System do?
Or
In Analysis we emphasizes an Investigation of the problem.
In Design we emphasizes on Logical Solution of the problem.
Hope it clearifies.
Bye,
Viki.
[ September 10, 2002: Message edited by: Vikrama Sanjeeva ]

[Frank Carver]

Depending on how your organization is structured, analysis and requirements capture may be the same thing, or they may be different phases.
Analysis is generally taken to mean the whole process of understanding a problem and its context. Requirements capture is the part of analysis which takes the understanding gained and writes it down in some sort of formalized way.

[Fintan Conway]

Hi Pradeep,
One way to do Analysis is to examine the requirements and extract from them certain classes. e.g. a View class, a controller class, and as many Model classes as the use case suggests. The use case should also give the interaction between these analysis classes.
In design you would choose how you are going to implement the requirement (Web - jsp / asp / etc., or VB App or Java App or ...). Then you could split up the view and controller analysis class into a number of design classes, and refine the Model classes. You would also need to define the interactions and relationships between the design classes. This should give you the design for your use case.
Regards,
Fintan

Originally posted by Pradeep Bhat:
What are the steps involved in analysis ? I want to know how do I understand the problem.
What do we do in design.
If analysis is understanding the system, then what do we do during Requiremets capturing time?
Please some one reply to my questions.

[Frank Carver]

One way to do Analysis is to examine the requirements and extract from them certain classes. e.g. a View class, a controller class, and as many Model classes as the use case suggests. The use case should also give the interaction between these analysis classes.
I'm not sure I agree with this.
This sounds much more like part of design, to me. Analysis is the bit that happens before you have any requirements, and helps to turn vague understanding among users and customers into something concrete enough to be agreed and designed/implemented.

[Fintan Conway]

Hi Frank,
What you are describing I would classify as "Requirements Analysis", which would lead to your Use Cases.
As a programmer I would break down the step in going from Use Cases (Requirements) to the design classes into 2 phases.
The first which gives a implementation neutral overview I call Object-Oriented Analysis. This should give an overview or architecture of the system.
The second phase I call Object-Oriented Design. This is implementation specific (whether using Web App or standalone app, for example) and produces the design classes from which the coder can produce source code for the classes.
Hope this clears up my view on SW development ,
Fintan

Originally posted by Frank Carver:
One way to do Analysis is to examine the requirements and extract from them certain classes. e.g. a View class, a controller class, and as many Model classes as the use case suggests. The use case should also give the interaction between these analysis classes.
I'm not sure I agree with this.
This sounds much more like part of design, to me. Analysis is the bit that happens before you have any requirements, and helps to turn vague understanding among users and customers into something concrete enough to be agreed and designed/implemented.

[ October 03, 2002: Message edited by: Fintan Conway ]

[Ilja Preuss]

Originally posted by Fintan Conway:
[QB]What you are describing I would classify as "Requirements Analysis", which would lead to your Use Cases.
As a programmer I would break down the step in going from Use Cases (Requirements) to the design classes into 2 phases.
The first which gives a implementation neutral overview I call Object-Oriented Analysis.

If it is implementation neutral, how does it differ from requirements analysis? What else do you do than analyzig requirements in this step?

This should give an overview or architecture of the system.

Mhh, isn't this an oxymoron - "implementation neutral architecture"?

The second phase I call Object-Oriented Design. This is implementation specific (whether using Web App or standalone app, for example) and produces the design classes from which the coder can produce source code for the classes.

That certainly is part of designing, yes. Coding is designing, too.

[Frank Carver]

I'm a little puzzled by this, too. Can you give us an example of such an "implementation-neutral overview", so we can see how it might differ from what we would think of as ordinary requirements or design?

[Fintan Conway]

Originally posted by Frank Carver:
I'm a little puzzled by this, too. Can you give us an example of such an "implementation-neutral overview", so we can see how it might differ from what we would think of as ordinary requirements or design?

Sorry for any ambiguity guys.
Analysis :
For each use cases I would define oneBoundary class for all GUIs and one Boundary class for any external interfaces, one controller class and any entity classes. I would draw up a Sequence diagram and Class diagrams for these classes. This is what I call "implementation neutral architecture" i.e. it does not matter whether the end system will be a standalone application, or a fully-fledged 3 tier web application. These diagrams still describe the system, without getting into implementation specific details. However they are not enough to describe the system to some one who wants to code it.
Design :
At this stage we decide what way to implement our design (may have been decided earlier but only has an impact at this stage). The analysis classes are refined (e.g. one class per gui, controller class responsibilities diveded among multiple classes, etc). This is implementation dependant - will be different if we are splitting classes into (a) Windows forms and VB classes, (b) JSP pages and servlets, (c) asp pages, etc.
Cheers,
Fintan

[Ilja Preuss]

Fintan,
I wonder on what types of applications you are working. For me, there generally isn't any direct relationship between Use Cases and GUI/Controller classes at all. I also find Sequence Diagrams only to be usefull in very specific cases.
Additionally, I probably wouldn't call your "implementations neutral architecture" implementation neutral. It seems to me that it already had to take into account implementation details like inheritance and aggregation relationships, use of polymorphism etc. For me, something called "implementation neutral" shouldn't even depend on wether it gets implemented in an OO language or not.

[Fintan Conway]

Originally posted by Ilja Preuss:
For me, there generally isn't any direct relationship between Use Cases and GUI/Controller classes at all.

Looking on the Web I see that there are a thousand (million?) and one ways to do use cases. The way that I do up a use case defines steps like the following :
"The system displays XYZ screen.
The actor enters XYZ data [A data, B data, C data]."
Screen is the most generic form I can find for GUI elements and covers Web page, Windows Form, etc.
Thus in my use cases I define a requirement for the system to produce an interface for the actor to interact with. This is how I find the GUI analysis classes from the use cases.

I also find Sequence Diagrams only to be usefull in very specific cases.

I do not use collaboration diagrams and so all my diagrams of the dynamic system are sequence diagrams. I find them useful in determining the exact method signatures which will be in the final classes.
Also the GUI classes and the data passed between them - as shown on the sequence diagram - are useful to our UI/Usability Engineer.

For me, something called "implementation neutral" shouldn't even depend on wether it gets implemented in an OO language or not.

I am following an Object Oriented Analysis and Design process. Therefore there is an assumption that the system will be implemented in an Object Oriented fashion. In fact I have been forced to implement some systems in Asp, as well as in VB. The analysis model (UML sequence diagrams and VOPC diagrams) for these systems did not depend on whether we were using non-OO languages, or OO language. The difference arises in the OO Design stage when we refine the analysis model - then it is treated differently depending on whether the language is OO or not.
Otherwise "implementation neutral" depends on how you want to define "implementation". To me implementation means specifying whether your system is developed as a standalone application / client-server/n-tier/web application. My analysis model generates UML diagrams which do not constrain you to have considered which of these implementations your system will use. Additionally it does not even constrain you to use full OO design (as stated in previous paragraph).
Thanks for your input,
Fintan
[ October 11, 2002: Message edited by: Fintan Conway ]
[ October 11, 2002: Message edited by: Fintan Conway ]

[Frank Carver]

Ah. I think I begin to see where the confusion arises. By limiting the range of application types you are able to "assume" some aspects of what I would consider design, because they are common to all the applications you are considering. These aspects are so fundamental to all your solutions that you treat them as part of the analysis process.
I don't feel that the division of responsibilities you suggest would work in the general case, though. Imagine you needed to produce (say) a JNDI server or a spreadsheet, for example. They don't follow the screens-and-input-fields paradigm which seems implicit in your approach.

[Fintan Conway]

Hi Frank,
In essence I am producing UML diagrams for my Use Cases - in other words a further step in Analysis to produce UML diagrams as a starting point for design.
Yes, I do make the assumption that the MVC pattern can be applied. I do not build and middle-ware products or real-time systems. Someone in another post on this forum classified the MVC pattern as an Architectural Pattern. Perhaps there are other Architectural Patterns for middle-ware or real-time systems that could be "assumed" at analysis stage, to allow you to do the same?
Regards,
Fintan

[Ilja Preuss]

Originally posted by Fintan Conway:
Yes, I do make the assumption that the MVC pattern can be applied. I do not build and middle-ware products or real-time systems. Someone in another post on this forum classified the MVC pattern as an Architectural Pattern. Perhaps there are other Architectural Patterns for middle-ware or real-time systems that could be "assumed" at analysis stage, to allow you to do the same?

IMO, assuming the use of a specific architectural pattern already *is* a design step. Doing it already when writing Use Cases might be appropriate in some cases, though I would worry that it too strongly constricts the thoughts, handicaping creativity on implementing the requirements.

[Ilja Preuss]

Originally posted by Fintan Conway:
The way that I do up a use case defines steps like the following :
"The system displays XYZ screen.
The actor enters XYZ data [A data, B data, C data]."
Screen is the most generic form I can find for GUI elements and covers Web page, Windows Form, etc.
Thus in my use cases I define a requirement for the system to produce an interface for the actor to interact with. This is how I find the GUI analysis classes from the use cases.

Why do you call them "analysis" classes? Aren't they meant to be implemented - and therefore already part of the *design*?
I also wonder wether it would make sense to write the use cases in a more abstract way. After all, you seem to be not only describing what the system should do (request some data from the user), but also *how* it should do that (show the user screen xyz). For me, which screens do exist is already a design question...

I do not use collaboration diagrams and so all my diagrams of the dynamic system are sequence diagrams. I find them useful in determining the exact method signatures which will be in the final classes.

For determining the exact method signatures, I find *implementing the classes* (preferably test-first) extremely usefull... seriously! I don't typically use diagrams for this - as I can't execute them to see if they are "right".

Also the GUI classes and the data passed between them - as shown on the sequence diagram - are useful to our UI/Usability Engineer.

Interesting - can you elaborate on this, please? I wonder, what exactly the UI/Usability Engineers are doing with the diagrams...

I am following an Object Oriented Analysis and Design process. Therefore there is an assumption that the system will be implemented in an Object Oriented fashion.

That certainly follows from using OOD, yes. I don't think it does follow from using OOA - whatever that might be exactly...

In fact I have been forced to implement some systems in Asp, as well as in VB. The analysis model (UML sequence diagrams and VOPC diagrams) for these systems did not depend on whether we were using non-OO languages, or OO language. The difference arises in the OO Design stage when we refine the analysis model - then it is treated differently depending on whether the language is OO or not.

Mhh, I have some problems imagining how, for example, "implementation neutral" sequence diagrams are of much help for creating the "design diagrams" - without constraining the usage of polymorphism and/or Design Patterns. In my experience, these things are much more strongly shaped by pragmatic implemention needs - like handling dependencies - than by the "domain model"...

Otherwise "implementation neutral" depends on how you want to define "implementation". To me implementation means specifying whether your system is developed as a standalone application / client-server/n-tier/web application.

Well, yes - that seems to be the main issue. For me implementation means the code, so everything that directly affects how the code gets structured (for example what classes will exist), certainly is not implementation neutral...

Thanks for your input

Well, thanks for the interesting and constructive discussion!
[ October 11, 2002: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Please indulge me if my messages currently seem to be a little bit confusing. I am currently quite stressed out - I use posting to JavaRanch as a form of recreation, though I assume the quality of my posts might suffer... :roll:

[Fintan Conway]

Hi Ilja,

Just to answer a couple of your points - not to stress you out any more
1) My Analysis classes are not implementable. The are only a stepping-stone to the Design classes, which are / should be implementable. These classes are basically a UML representation of the requirements and are meant to give the "big picture" of what the final system may look like. They do not necessarily represent any classes which will eventually end up in the final design.
2) Perhaps I should have put the word screens in double quotes. In requesting information from the user the system will have to display some form of interface (or pass control back to an interface). "Screen" seems to me to be more abstract than "form", "page", etc. When the UI / usability engineer is shown the sequence diagram of these "screens" with all the data that is passed back and forth, he can easily understand the data flow between the "screens". He can make a decision as to which "screens" can be merged to provide a single interface "screen", and if some need to be split into more than one interface "screen" (Hope all these "screen" references are not confusing, or adding to your stress )
3) I find my exact method signatures by first figuring them out on paper (i.e. on the UML sequence diagrams). Then I implement the class, test and refine the signatures if necessary.
4) I would apply Design patterns and implementation in the OOD phase, rather than in analysis - as analysis is really a restatement of the requirements in UML notation.
I hope I have not added to your stress,
Fintan

[Ilja Preuss]

Fintan, you didn't!
Thanks for the clarifications. Now the "screens" make much more sense to me...

[Frank Carver]

I wish I had the ability to debate highly technical software design issues, in a second language, for recreation !! Take it easy Ilja.
Now on to Fintan's comments:
My Analysis classes are not implementable. The are only a stepping-stone to the Design classes, which are / should be implementable.
I'm still puzzled by why these intermediate design artefacts need to be "classes", if they are not implementable. Do you really, honestly, deal in "classes" at this stage, or do you actually think about "objects"?
To me, the concept of "classes" is just a convenience to allow simple and efficient coding of similar objects. Why so many people try to start their designs by thinking about classes and inheritance baffles me.
These classes are basically a UML representation of the requirements and are meant to give the "big picture" of what the final system may look like.
I can certainly understand the value of writing/drawing something to act as a talking point and a "stick in the ground" for all the project stakeholders. I do wonder if UML is more appropriate than just a bunch of index cards with screen sketches, data item names or whatever.
They do not necessarily represent any classes which will eventually end up in the final design.
Which is why I would probably stay at a more abstract, domain-specific level at this stage of the user/designer discussion.
Perhaps I should have put the word screens in double quotes. In requesting information from the user the system will have to display some form of interface (or pass control back to an interface). "Screen" seems to me to be more abstract than "form", "page", etc.
I still worry that this may be constraining the creativity in the design. Some of the most important software innovations have come from breaking these sort of process assumptions. The spreadsheet for example, with a single "screen" and a completely flexible arrangement of fields; "drag and drop"; multiple input/output windows open at once; visual/graphical navigation; user-customisable information aggregation; etc. etc.
Let me tell a story of a project I worked on a few years ago. The project manager had decided to split the development into two teams: "designers" and "programmers". The responsibility of the designers was to liase with the customers' representatives and produce just the sort of screen and field flows you seem to be describing. The physical screen on the device was quite small, so there were over 200 input screens, each with up to 8 input fields arranged in complex branching paths. Agreeing this "design" with the customers took months of long meetings, The end result was very cumbersome and buggy, and detested by the users.
When the "design" team "moved on to other projects" I joined a programming team with responsibility for the whole requirements/design/programming job. Once we started from scratch, we found that what the users actually needted was much simpler. A single working screen with a status display and a little help text, with all the keys on the keyboard active as separate "something has happened" buttons which stayed on the same "screen". One button took them to a single, scrollable form for any extra information which they could return to and change/update at will.
Despite thousands of hours of work, the original design team and customers never came up with this solution. They were too focussed on deciding what should be on each screen, and in which situations and order each screen should appear.
It didn't help that the project documentation templates supplied at the start of the project were designed to each describe a single screen, its fields, and where a user should "go" next.
I find my exact method signatures by first figuring them out on paper (i.e. on the UML sequence diagrams). Then I implement the class, test and refine the signatures if necessary.
I'm a big fan of test-first design, and I feel that most of the "figuring them out on paper" and "refine the signatures" could be streamlined in this process by starting with writing executable test cases. I find it much easier to settle on a workable API if I already have code which needs to use it.
I would apply Design patterns and implementation in the OOD phase, rather than in analysis ...
That's good, although I prefer to interleave design with coding rather than treat it as a separate "phase".
... as analysis is really a restatement of the requirements in UML notation.
This seems to be where we disagree the most. To me "Analysis" is studying the problem domain, its users, its vocabulary, its needs and its existing processes until enough understanding is gained to consider a solution. "Requirements" are a statement of some of this knowledge in a form concrete enough to be tested.
You seem to be implying that, somehow, requirements come before analysis! How can we know what the requirements for the solution are until we know what the problem is ?
I agree with Ilja. This is growing into a really interesting discussion.

[Pradeep bhatt]

Check out this link
http://genet.cs.umass.edu/~gwking/whyoop04.htm

[Ilja Preuss]

Originally posted by Pradeep Bhat:
Check out this link
http://genet.cs.umass.edu/~gwking/whyoop04.htm

Sorry - I find this article to be misleading at best, even dangerous in parts.
I will elaborate on that later...

[Frank Carver]

I see what you mean, Ilja.
It reads a lot like a student essay rather than something written by a knowlegable professional software developer.

[Ilja Preuss]

Here is a summary of my main issues with the article mentioned above:
- a good OO design is *not* data centric, but behaviour centric
- OO design *can* be done top-down, and this probably isn't the worst approach
- OO is *not* more appropriate for modeling the real world in general than other approaches. Specifically, the real world *does not* work object-oriented (you typically don't send a message to your bootlaces, telling them to knot themselfs) and people *don't* naturally *think* object oriented (the confusion OOP produces in most of the beginners should make that obvious)
- it is not even a *goal* of software design to model the real world as closely as possible; the goal is to produce an abstraction that is most usefull for the implementation of the problem at hand
- implementing for the future is very dangerous and certainly not something that makes OOP more usefull than other approaches; YouArentGonnaNeedIt. It is not this embracement of the future that improves reusability in OO, but increased decoupling and stronger abstractions through informed use of polymorphism and encapsulation.
- the article awkwardly mixes OOA and OOD; for example, in OOA there is no such thing as inheritance, only generalization/specialization. The article also doesn't make clear enough that the link between OOA and OOD is a rather weak one; the is-a relationship in OOA is not a good criterion for forming an inheritance relationship in OOD, for example.
That's it for now...

[Mohamed Chaoui]

Hi all,
There is somme general rules to apply :
- OOA must focus on describing the "users requirements". A this level don't think about implementation.
- OOA try to apply some "architectural models" to the OOA results. At this stage we must consider implementation environment and architectural choices.
I think the problem is that there is no "EXACT" limit of the OOA and OOD. With experience, every one or evert team make it's own choices and best practices.
For me it's a good practice to begin programming at the same time of the design process. This help us validadate our choices.

[kapil kumar]

Hi,
Can anyone summarize what analysis and design is all about. I am confused after reading this thread.
How does analysis help in design ?
When drawing sequence diagram for analysis model, Is it required to start each operation with "//".
Thanks
kapil

[Ilja Preuss]

Originally posted by kapil kumar:
Can anyone summarize what analysis and design is all about.

Analysis is finding out what the system you plan to build is supposed to do.
Design is about how to build the system in an efficient way (whatever that means to you...).

How does analysis help in design ?

Well, it's rather pointless to design a system without knowing what that system should do, isn't it? Analysis helps you search that out.
Some methodologies (like Fusion) also try to directly connect entities found in the analysis to entities used in the design. IMO you should be *very* cautious in doing so and rather see that as a simple heuristic than as a strong rule.

When drawing sequence diagram for analysis model, Is it required to start each operation with "//".

I don't think so, but I have to admit that I don't know what the "//" does mean at all. I think I would still understand your diagram if you omitted it...
OTOH, I wonder what a sequence diagram would be usefull for in analysis, anyway. Why do you want to draw one?

[Pradeep bhatt]

I guess that Rational insists on drawing sequence diagram for both analysis(Use case Realization) and design.

[Pradeep bhatt]

I guess that Rational insists on drawing sequence diagram for both analysis(Use case Realization) and design.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
I guess that Rational insists on drawing sequence diagram for both analysis(Use case Realization) and design.

You are wrong!
Rational insists on *none* of their diagrams. The Rational Unified Process is a "buffet" from which you choose whatever is right for your process - none of the artifacts is mandatory.
You could totally abandon UML and still do RUP (as the XP plugin shows).

[Ilja Preuss]

Just found an interesting paper on "RUP for a one man team": http://www.therationaledge.com/content/feb_02/f_processForOne_pk.jsp

[Pradeep bhatt]

What is use case realization ? It comes as a part of analysis stage, isn't?

[Fintan Conway]

Originally posted by Pradeep Bhat:
What is use case realization ? It comes as a part of analysis stage, isn't?

Hi Pradeep,
Use Case realisation is the forming of concrete design classes from use cases. You may need to perform some Analysis of your use cases to give Analysis classes, and then you create your final design classes using your analysis classes as the starting point.
HTH,
Fintan

[Ilja Preuss]

Originally posted by Fintan Conway:
Use Case realisation is the forming of concrete design classes from use cases. You may need to perform some Analysis of your use cases to give Analysis classes, and then you create your final design classes using your analysis classes as the starting point.

That would be an UML driven approach, so it seems to me.
An alternative is the test driven approach; basically:
- transform the use case into automated Acceptance Tests (functional tests) which non-ambiguously communicate and verify the requirements
- write an automated simple unit test for the first bit of functionality you need
- make the test pass by implementing the simplest production code necessary
- refactor the code so that it is in the best imaginable state
- write the next unit test, forcing you to extend the production code
- iterate until all acceptance tests pass
For me, this works better than thinking about "analysis classes" and the like. YMMV.