Talk:Object-oriented analysis and design

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)

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)

I don't agree that merging in general should be rejected or discouraged, it all depends on the articles. In my experience there actually tend to be a lot of articles that are really about the same topic but they became two different articles because people just started one article without doing a good search and because editors in general -- at least some of them -- seem to get more satisfaction from creating new articles than improving existing ones. But having said all that, I agree in this case, absolutely the two are not at all the same thing. It's like saying "software development" and "programming language" are the same topic, they aren't and it's really the same here just up one level of abstraction, a modeling language is a tool you use when doing analysis and design but they are not the same. --MadScientistX11 (talk) 13:57, 12 December 2013 (UTC)

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)

Wikipedia Integration

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

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)

These philosophical discussions may be interesting but they are all really besides the point. Use cases absolutely are a fundamental technique of many, at this point I would say almost all OO analysis methods. Jacobsen's book on OO software engineering -- which is one of the bibles of OO methodologies -- is subtitled "A Use Case Driven Approach". I've taken and given classes in OO and they all had sections on use cases. I actually am kind of sympathetic to the view that use cases aren't all that OO, I used to think that a lot myself actually but those discussions are for blogs or drinks after a hard day programming, this is an encyclopedia and it should reflect what is accepted best practices and standards and there is no question in my mind OO and use cases go hand in hand. MadScientistX11 (talk) 23:25, 11 December 2013 (UTC)

Redirect

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

I agree but I just checked and object-oriented does now go to OO programming not to analysis and design. MadScientistX11 (talk) 23:26, 11 December 2013 (UTC)

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. :)

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)

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)

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)

IMO it makes sense to keep analysis and design as one topic when talking about OO. The distinction between the two is always fuzzy, even in other methodologies but with OO, at least in my experience it's fuzzy by design. I've been on lots of OO projects and no one ever says "OK, we finished analysis now let's do design". Sometimes people don't bother doing much analysis and design to begin with but when they do there is really no distinction between the two in my experience. I think it's because OO tends to go hand in hand with iterative development and agile methods approaches. MadScientistX11 (talk) 23:31, 11 December 2013 (UTC)

Rewrote Most of the Article

I rewrote most of the article. I added 6 inline references to classic OO books like Jacobsen and I therefor removed the tag that said the article needed inline refs. I removed a template called FOLDOC because so little of the original article remained and I didn't use the online dictionary it refers to MadScientistX11 (talk) 22:27, 13 December 2013 (UTC)

The introduction should be rewritten shorter. Alphama (talk) 15:12, 25 December 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Object-oriented analysis and design. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070928035622/http://www.eden-study.org/articles/2002/isf4(4).pdf to http://www.eden-study.org/articles/2002/isf4(4).pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:19, 9 January 2018 (UTC)

Proposed merge of Object-oriented design into Object-oriented analysis and design

very wide overlap. fgnievinski (talk) 02:37, 10 September 2023 (UTC) fgnievinski (talk) 02:37, 10 September 2023 (UTC)

  Y Merger complete. Klbrain (talk) 15:53, 23 June 2024 (UTC)