Talk:Object-oriented analysis and design

From Wikipedia, the free encyclopedia

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
WikiProject Integration Object-oriented analysis and design has been integrated by the Wikipedia Integration WikiProject

Contents

[edit] Do SHARATH Merge with Booch Method

The Booch sdsdat this point, yes? Should Object modeling language be merged into here, into Modeling language, or as part of a history section of Unified Modeling Language. Ewlyahoocom 06:10, 6 February 2006 (UTC)

Later, I found I had a slew of open windows yet was none-the-wiser. Aggressie would have been merging the pages without consulting you. Ewlyahoocom 07:18, 15 February 2006 (UTC)
I think they should be merged or expanded as, it is very messy and all over the place. Vec 18:05, 6 March 2006 (UTC)

[edit] Discourage Merge

Merging as a policy should be rejected. It runs against general Wikipedia Article Length Policy. It is a better editorial practice to arrange "knowledge" in smaller modules/units. Further, in the future, the Target Merge article will be too lengthy to be manageable.Connection 17:09, 7 March 2006 (UTC)

An overview and links to other articles is a better arrangement.Connection 17:09, 7 March 2006 (UTC)

[edit] Shlaer-Mellor merge

Personally I feel that these articles shouldn't be merged. Is there anyone here who wants to give reasoning as to why they should be? GeorgeBills 05:57, 22 April 2006 (UTC)

[edit] Wikipedia Integration

Analysis & design stubs were merged in per the methodology of Wikipedia:WikiProject_Integration. Cwolfsheep 19:16, 12 June 2006 (UTC)

[edit] Use Cases in OOP

I do not fully agree to the statement: "Use cases are not specific to object-oriented analysis, and are better suited for analysing a system that will be implemented in the procedural paradigm ". As it is true that Use cases are not specific to object oriented analyzis, I do not see why that is better suited for procedural methodology. I think this is missleading as the use of Use cases was strated with object oriented programming.

Use cases is a new technique to help capture requirements. It helps analysis in general, by focusing on the interaction between the user and the proposed system. It helps to see the system boundaries, that helps to scope the new application. It also helps to define sub-systems, that helps the iteretive development which OOP advicates.

Also OOP in general can handle more complex requirements. Having more complex requirements ask for better technique to capture requirements. So the above statement may discourage the reader of useing usecases, so if there is no objections I will Change that. Ervinn 15:57, 30 August 2006 (UTC)

I've changed the sentence to this : Use cases was invented with object oriented programming, but it can be also used in a system that will be implemented in the procedural paradigm. Ervinn 15:23, 11 September 2006 (UTC)
The reason for the statement against using use cases to model object-oriented systems is the focus of use cases. In OOA and OOP, one of the basic assumptions is that you want to identify and distinguish reusable parts of the system (those that are stable under changing requirements) from those that are not. Use cases do not make this distinction, but instead attempt to distinguish different functionalities and behaviour from each other. Granted, it's possible to use use cases to model OO systems, but this requires an extra step after the use-case analysis to find the reusable portion of the system, which is completely ignored by the use case approach. So, it seems that when you use use cases in conjunction with procedural approach, the requirements analysis has one less steps than when you use use cases with the object-oriented paradigm. There are also several books [e.g. Meyer: Object-oriented software construction] that advice against using use cases to analyze requirements for an object-oriented target architecture. In particular, Meyer's book states: (pg. 112): "... (would be object-designer) is tempted to rely on early identification of system usage scenarios ("use cases") as basis for analysis. This is incompatible with object-oriented principles, and often leads to top-down functional decomposition of the purest form...". esap 18:14, 14 September 2006 (UTC)
I do not really agree. I think it is possible to create and organize use cases with "thinking-ahead" that we want to identify and distinguish reusable parts of the system. A use case can be re-used many time during the system, or we can decide not to re-use a use case, based on a maintainability requirement. How we organize use cases are also governed by other requirements. If there is a requirement to build a secured system, to minimize possible affect of a change, re-use of use cases are discouraged. ...
I haven't seen this notion of re-use of use cases. What I've seen of use cases, they describe so specific business goals that reuse of them is impossible. Are you thinking from the point of view of the actor (which might easily reuse a use case), or from the point of view of the implementor of the system (for which reusing a use case would cause the same requirement to be implemented twice!). esap 15:50, 15 September 2006 (UTC)
Many times users interact with the system in different times that results similar response from the system. Similar interactions can be part of different business processes. Also one user interaction can be sub-divided to smaller ones. It can be, but does not have to be. We divide if one of the sub use case can be reused in a different business flow.
So to answer your question, I think I was referring to the point of view of the implementor, however the implementor may decide to implement it twice or re-use the same code.
I think the benefit of use case becomes obvious in big and complex systems. But to ilustrate what I mean I try to use an example.
Lets have a retail application, we have two business flows. One is to buy an item, the other is to return an item. During creating the use case, we recognize that in both interactions the taxes need to be calculated. So we can create a use case called "Calculate Taxes Use Case" and we include it to both the "Buy Use Case" and "Return Use Case". Ervinn 18:47, 19 September 2006 (UTC)
I don't see why "Calculate Taxes" would be a use case, since I would expect that calculating taxes requires no interaction with the user (whether it's the clerk or the customer that uses the thing that calculates the taxes, I'd expect the receipt to contain summary of taxes in both 'buy' and 'return' use cases). And it would seem to me that the interaction (if any) associated to calculating taxes is different when you buy or when you return the item, so the interaction itself couldn't be reused. esap 16:55, 21 September 2006 (UTC)
This is just meant for an arbitrary example, it may not the best one, it tried to illustrate a situation when a use case can be re-used. "We may do not know what the receipt contains". Ervinn 20:49, 21 September 2006 (UTC)
It is true, that use case does not have any tool to help to make those decisions. But I am aksing what is the alternative? Is there a better tool to capture requirements for OOP? Also, I think that "Meyer" argument againts use cases should be put in the "Use Case" page. Ervinn 14:02, 15 September 2006 (UTC)
Conceptual models are a tool to capture OO requirements. Each concept in a conceptual model can be mapped in straightforward way to classes in OO design. esap 15:50, 15 September 2006 (UTC)
The Conceptual model may hold the requirements for the analyst who created it, but not for the business people, unfortunately. Conceptual model is the product of analysing the requirements. The analyst is trying to understand what needs to be built. What do you mean by OO requirements, business people do not care if OO is used. Ervinn 18:47, 19 September 2006 (UTC)
Yes, conceptual model is clearly the product of analysing requirements. But in my understanding, so are use cases. Both are tools used to understand requirements. The actual requirements are not necessarily the same as what is formulated as use cases or as conceptual models. Use cases and conceptual models are both just tools to describe the requirements. I don't think business people care what formalism is used to express the requirements, only that it corresponds with what is required, so that the end product that will be built can also correspond with the actual (as opposed to what is described) requirements. With 'OO requirements', I really mean 'requirements that can be modelled/described using OO methods'. Note that such requirements do not require particular interaction between the system and the actor, but instead require some particular service, concept or action to be available to be manipulated using some existing means [e.g. one requirement could require existence and proper handling of receipts in the retail application in all use cases, whether implemented currently or not]. This is often called a 'cross-cutting concern', e.g. something that is orthogonal to the primary modelling method. If you use use cases as primary means of capturing requirements, then all OO stuff are cross-cutting concerns. This also applies vice versa, e.g. functionality is a cross-cutting concern in OO. esap 16:55, 21 September 2006 (UTC)

[edit] Redirect

Why does "object oriented" redirect to this article instead of "object oriented programming"? I think the latter would be more appropriate. Thanks.

[edit] We

"The result of object-oriented analysis is a description of what we want to build"

"Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we want to solve by developing an OO system."

Who is "we?" I don't think encyclopedia entries ought to be written in firstperson plural. :)

[edit] Illustrative example?

Object-oriented analysis is arguably quite an abstract concept for most people.

How about including an example to illustrate the concept?

User:derekgillespie 13:07, 18 December 2006 (GMT)

I suppose it is fairly abstract, but I'd suggest that more detail and examples ought to be in a separate article on OOA. There's already an article on OOD, so why not one on OOA? The purpose of this article is surely to give an overview and an entry point to anyone searching for OOAD, and so it shouldn't get too involved with the details of either. --Malleus Fatuarum 02:02, 12 August 2007 (UTC)

[edit] Disambiguation

Does any one think that there should be a disambiguation for this article even if OOD does not directly go to it. There are other abreiviations for OOD such as Officer of the Deck and many others. Sith Penguin Lord 22:28, 10 May 2007 (UTC)

[edit] OOA

I have today rewritten parts of this article, and I felt as a result that the {{Essay}} and {{Expansion}} tags could reasonably be removed. The article now seems to me to be the start of a reasonable portal into OOA/OOD. Or at least it would if there was actually a page on OOA. I was rather surprised to find that there isn't one. --Malleus Fatuarum 02:14, 12 August 2007 (UTC)