Desinging a component

[KevinJL]

Hi everyone,

Would anyone mind sharing how they go about designing a component. I can't seem to find a method that I am comfortable with. I have used use cases before but am interested in other methods.

What questions do you ask to ferret out what the component should do? Do you have a methodology you follow, or fly by the seat of your pants?

Thanks
Kevin

[Edneeis]

What do you mean? Generally you develop components to solve problems and that may be helpful in more than one application. So its usually just standard problem solving, but I'm not sure I understood the question.

Who are you asking questions to? What are 'cases'?

[KevinJL]

True components are developed to solve problems. They also can mimic real world objects, like a book, or a person or a car. Lets take for example a box.

How do you go about deciding what the properties and methods of the box are. Does the box do anything, pour something perhaps? How many sides does it have? How tall is it? What is it's volume?

So if you have a problem to solve, reading the problem will help you to define the class. Picking out the verbs and nouns in the problem help you define the properites and methods of the class.

Use cases are description of how a person would use your object. They are typically focused on single action a person would perform using an object. It is more a part of UML.

[Edneeis]

Well generally there is still some purpose for which the object is created and so I'd ask myself what is the least or the most economical set of properties and/or methods to have that object achieve it's purpose. Are there actually methods that you use to gether this information? I'm not really up on UML, I know what it is in the general.

[KevinJL]

Hmm... I like that the most economical set of properties and methods, that changes ones thought pattern.

"Are there actually methods that you use to gether this information? "

Yeah there are few that I am aware of.

1. Is writing code on paper that you as a user (developer) using an object would expect to have to write. For example if you wanted to copy a file what code would you write to do that.

2. Use Cases, describes how a user (sales rep) would interact with your object. You list who the actor, secondary actors are, what the flow of events and business rules are.

3. Textual Analysis, read the problem statement and pick out the nouns and verbs. Analyze the nouns with an eye to first identifying the classes. After that examine the remaining nouns to see if they are properties. You might also discover hidden properties, and lastly examine the verbs to see if they describe any methods of the classes you indentified.

[Arc]

*** are you talkling about? lol

I think you are making WAY more complex than it needs to be.

By Component, what exactly do you mean? a DLL, an ActiveX control?

Anywho, i find out exactlywhat the thing is supposed to do, then start doing it. I certainly don't write anything on paper and REALLY don't scan a description for Nouns and Verbs and crap. What kind of panzy college did you graduate from lol.

[KevinJL]

Hmm..clearly code by the seat of your pants.