Talk:Object-oriented analysis and design
From Wikipedia, the free encyclopedia
 |
Object-oriented analysis and design has been reviewed by the Wikipedia Integration WikiProject |
Contents |
[edit] Don't Merge with Booch Method
The Booch method is a particular OOA&D technique. There are many more, such as OMT and Objectory, both of which have their own articles. I believe it's a separate entry Mjchonoles 05:04, 6 February 2006 (UTC)
- Those should be merged into here as well. Can you remember any more? They're all stubs and it's highly doubtful they will ever be significantly expanded. Booch Method, et. al. are little more than historical footnotes at 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)
Each of these techniques deserve its own article. The fact that they are currently stubs does not mean they won't or should not be expanded. Compare the list of programming languages. Should they all be merged into Programming language? RayGates 02:24, 7 February 2006 (UTC)
- Yeah, if they've been stubs for a long time and have little chance of ever being expanded then they should definately be merged -- although Programming language probably isn't the best choice. Then again this page isn't exactly Software engineering. Ewlyahoocom 05:40, 7 February 2006 (UTC)
No, I'm pretty convinced that they are signiifcantly different and don't belong together. While they can link to each other, the other techniques should be expanded. The concepts of these are quite different and they would be confusing in a single article.
The real problem here is no one appears to be willing to put any content into this article. Almost all the potential candidates for merging have descendants that are still practised to this date and should not be merged.
Modeling Languages are seperate problem. While many of the methods/techniques identified here had their own modeling language when first constructed, they mostly use UML today. However, there are other modeling languages, some related to UML and many not, that need their own articles. Mjchonoles
- Do you think we should have a different page for each kind of buggy whip that was once in popular use? They're not all the same, you know. How about the stirrup? Ewlyahoocom 18:05, 8 February 2006 (UTC)
Just because you don't use them, doesn't mean that they're not in use. I can't see why you're so aggressie about this. I'd recommend that this page should be deleted as it has no content and it only refers to other pages. Perhaps it should be a category. If it had content, then we could figure out if the other ones belonged here. Mjchonoles 19:12, 8 February 2006 (UTC)
- I originally wanted to read about this topic. 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)
- 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)
- 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)
-
-
-
-
- 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)
- 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)
- 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)
-
-
[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)
