How to design when domain is well understood?

[Nachiket Patel]

Hi, Guys. For understanding my situation better, i have to tell you bit about it. Please bare with me.

We already completed two huge similar project for "Heavy Material Tracking Project" in steel industry. Our team was very fresh. We end up having two different system altogether.

And after that Miracle happened, our boss decided to have training in OOAD and Design Patterns. We were given good time to study stuff. I read Head first OOAD, OOAD with Applications - by Grady Booch.

I read many articles, had good training, and tried with one small project of OO analysis & design. We used Iterative development for that small project, and worked well, we also tried to used TDD approach, but not succeeded 100%, but atleast we tried.

As i said Our aim was to adopt iterative and OO approach, and we succeeded.

But now U turn comes, They decided to develop Components for "Heavy Material Tracking", as we have to deliver same kind of system at more 4 to 6 different places.

Now let me tell you, i found working on "Component based development" is totally different from "developing good OO System".

My boss's arguments are, 1) You have complete knowledge of Domain. 2) You had good training, and you performed well. 3) You guys have already developed 2 System of same kind & 5) It should be REUSABLE business components.

But my feeling is, Components should developed by experience architects, not by good and fresh OO developers. I do not have any practical experience of developing huge system, or components. But it is for sure, that i and my colleague have to do it.

I want to know, how i should go, I should start develop one component, then another. Should i process serially or i should start developing components parallel, developing core functionality of multiple core components.

One more thing, We can choose J2EE and develop in J2EE directly, or first we design and develop it in core Java, then extend it in J2EE.

Ah, Very Optimistic , it is killing me.

Please feel free to ask more about it, i will try to reply as fast as i can, because I am desperate to have a solution.

Regards,
Nachiket

[Jimmy Clark]

Now let me tell you, i found working on "Component based development" is totally different from "developing good OO System".

Please explain why you feel this way. In your opinion, what are these differences?

[Ilja Preuss]

Well, I agree to the point that it takes more than good training and a test project to become a decent OO developer - it takes a lot of practice, seeing the forces of OO design in action, getting used to dealing with the interaction of lots of small objects etc. And it takes a bit more than a good OO developer to become a good component developer - namely, a good API design skill. Google for "API design" for some good references.

Anyway, it's not a good idea to try to develop reusable components from scratch, anyway. The best way to develop reusable components is to actually reuse them. That is, you should simply develop your first OO system, and on the way keep care that you get a good OO design, without focus on reusability (outside that system). Then, when you create your second system, have an eye on what code from the first project you could reuse by extracting it into reused components. That way, the component API will be based on actual reuse scenarios, not on speculation (which will almost always not be exactly right). Once you've implemented your fourth or fifth system that way, you will have a decent component library, that's proven to be reusable in the way you need it.

To be able to do that, you should probably get some form of training on refactoring...

[Nachiket Patel]

Hi James,
[I am writing in very layman language and it is not the only differences, so some may be not agreeing with me, but this is what i think, & any of my thoughts are wrong, please tell me.]

Mainly, In Good OO systems, You can always refactor later, change method signature (Method name or parameters), but in case of Components, once you publish methods/interfaces (by which outer world interacts with components), it should not be changed. So identifying that interfaces, which are less likely to change over change-in-functionality or change-in-requirement is one of the toughest issues to tackle.

[Although you can change published interfaces, when your component usage is under your control. like your components are used in your company only and in particular domain, in which you are working, as i am, that i can change the interface, and made change to all the places, where it is used, But it is more management issue then technical]

Another point is- you have to draw a clear border between components. Yes it is good practice that your code should be less coupled, but in OO systems, it can happen at later stage, you keep refactoring your code, and try to decouple unrelated functionality. When in Component design you have to do it upfront, [although internal refactoring to the component is possible].

Feel free to ask if you have doubt.

Regards,
Nachiket

[Nachiket Patel]

To Ilja,
Thanks for Google guideline on API Design.

Okey, so what i have to convince is, Develop complete system without customer, rather than developing components. [It is possible because we got all the domain knowledge, and information where system will be deployed.] & At later stage when another system is suppose to be deployed at that time identify possible components, separate them and use in old system and reuse in new system. Right?
Anyways, I'll talk it out with my dept.

One more question..
What about J2EE, Consider that first system will be going to develop in J2EE. When components will be identified and separated, Weather components should be J2EE components or it should be POJO. [I know it is not the time to take decision, but just curious about your thoughts]

Regards,
Nachiket

[Darya Akbari]

Nachiket,

this is a very important topic you brought up here

[Nachiket Patel]

I am just telling my story.
But Thanks for the compliment.

[Jimmy Clark]

Nachiket,

You seem to be comparing two concepts: (1) OO systems and (2) Component design.

Just to understand your comparison, are the "components" written in object-oriented code? Do the same design principles of creating object-oriented software apply to designing object-oriented components?

Yes, there are different approaches to designing code, including aspects of reusability and whether the code will be "labelled" and used as a "component." However, the two concepts are not different from each other. Differences in how one might design API does not make it a different technology.

The Java code of an application server and the Java code of an application that executes in an application server are different. And the designs are different. It is still Java code, however.

The principles of designing object-oriented components and the principles of designing larger object-oriented information systems are slightly different. They are still object-oriented design principles, however.

[Nachiket Patel]

Hello James,

You seem to be comparing two concepts: (1) OO systems and (2) Component design.

No, i think, i am comparing (1) Complete System and (2) Reusable Components [And both will be OO[using Java] only.

Sorry for referring Complete [Software] System as a OO Systems in previous posts. I meant Software system only.

are the "components" written in object-oriented code?

Yes.

Do the same design principles of creating object-oriented software apply to designing object-oriented components?

Yes, absolutely.

The principles of designing object-oriented components and the principles of designing larger object-oriented information systems are slightly different. They are still object-oriented design principles, however.

Yes, i agree with your point.

But there are many concerns [& Most of are not related to OO] you have to take care in case of component development.

One need clear vision about what component will do & knowledge of all the places where that component can be used.

Let me explain another problem.

As i told you if some piece of code which is properly separated, less coupled BUT not labeled as a component, then you can change the interfaces of that piece of code, without any problem. But Say that same piece of code is component, then scenario is different, It may be used in OTHER PROJECTS, you have to go through your boss, and he may need confirmation of his boss because if affects other project, so now OTHER PROJECTS cannot use new component version without changing code of all the projects. [And say someone Find&Fix a major bug in that component, but OTHER PROJECTS cannot get benefit of that, until & unless code is updated/changed]

------- I know it is very hypothetical, but it happens... I don't know about others, but It happens with us. ----------

As i said, These problems are not related to OO Concepts, but it is more related to managerial and general issues.
[ November 18, 2008: Message edited by: Nachiket Patel ]

[Jimmy Clark]

One need clear vision about what component will do & knowledge of all the places where that component can be used.

The same need applies to designing an OO system or any other software system for that matter. This is not something specifc to only "component" design.

One needs clear requirements about what a component or a software system will do.

One needs clear requirements about all the places where a component or a software system can be used.

[Ilja Preuss]

Originally posted by James Clark:

The same need applies to designing an OO system or any other software system for that matter. This is not something specifc to only "component" design.

Well, no, by far not as much, because you can always refactor later - which is much harder to do once you published a component.

[Darya Akbari]

Isn't Nachiket talking about Product Line Development?

You can use every OO design principle and all known OO design patterns for it. The point is that you have to use patterns like adapter, factory or template heavily to plug-in your customer software with your product software solution.

[Jimmy Clark]

The same need applies to designing an OO system or any other software system for that matter. This is not something specifc to only "component" design.

Well, no, by far not as much, because you can always refactor later - which is much harder to do once you published a component.

The "need" I am talking about is the "need clear vision about what component will do & knowledge of all the places where that component can be used."

The "effect" of not having a complete set of requirements might be greater with component development once it is published.

In regards to the "need" above, the importance and degree may vary from person to person. I favor them having the same approach.

I see "component development" as a possible subset of OO system design. Much in the same way as "service development" can be viewed as a superset of OO system design.

[Nachiket Patel]

To James,

One needs clear requirements about what a component or a software system will do.

But, Is it required to have complete set of requirement [A COMPLETE LIST, which cannot be change later] for software system?? I don't think it is desired or recommended, unless it is Waterfall approach.

But it is desired that once you publish your interfaces and start using particular component, it should not change or extend it's requirement.

One needs clear requirements about all the places where a component or a software system can be used.

I feel identifying the places where components can be used, is OO design decision, and it is related to reusability.
&
Identifying the places where software system can be used is user centric and more related to system scope/coverage.

I hope you understand what i am trying to explain.

[Nachiket Patel]

To darya,
Please tell me, how it makes difference? Is there anything special when someone wants to develop Product???

You can use every OO design principle and all known OO design patterns for it. The point is that you have to use patterns like adapter, factory or template heavily to plug-in your customer software with your product software solution.

I am not getting, If i am designing software system not as Product, is there any restriction for using Patterns or OO Concepts??

[Nachiket Patel]

To James,

I see "component development" as a possible subset of OO system design.

Oh, I was thinking in quite opposite direction. I was thinking as superset of OO system design.

I feel....
"OO System" requires OO understanding + OO design skills + minimal documentation [UML] + code + unit tests + [bunch of other stuff]

"component development" requires "OO system" requirements + extra care for designing publish interfaces + Component Specification

Please tell me what is in your mind? I am eager to know.

[Jimmy Clark]

An entire object-oriented system may include the usage of one or more object-oriented components.

An object-oriented component may be used in one or more object-oriented systems.

The system is the larger concept. A component is part of a system. A system is not part of a component.

[Ilja Preuss]

Originally posted by James Clark:

The system is the larger concept. A component is part of a system. A system is not part of a component.

That's true. Doesn't tell you much about the skills required for each, though.

[Sylvester Camphorian]

Hi everyone,

Nice discussion going on here about component and OO Design and am very excited to jump in...

I have also been working on component design and object oriented design so what I have learnt and know is that OO Design and Component Design are like the rail lines which are always together but no one overlaps each other...

You can design a component in a completely non object oriented way and use it in a system designed using OO ways....

While designing any system using reusable components requires the knowledge of OO Design Techniques as it inherently requires OO concepts at a larger granular level but then we need not concentrate on component design at the system design level... Remember our good old abstraction mechanism to conquer complexity...

I guess our approach of concentrating on both the aspects at the same time makes them seem overlapping
[ November 19, 2008: Message edited by: Sylvester Camphorian ]

[Nachiket Patel]

Well said, Sylvester.
Although i won't be able to comment fully agree on it because, i feel it is very hi level for me.

Anyways but you can share your experience as you are working on OO and components,

So, Is it the case that you create components first as per requirement and use it in software system?
If yes, What problems you faced with this approach?
If no, then how you develop components?

And Welcome to the JavaRanch.
[ November 19, 2008: Message edited by: Nachiket Patel ]

[Sylvester Camphorian]

Hi Nachiket,

Well, even I am not an expert in developing components and I am also just fighting through the intricacies of component design...

But as far as I have understood, its about understanding the basics rather than getting into the complexities of component and OO design collisions...

First, you should know what a component is and what things in your application you can make as a component. And for this, go back to the definition of reusable components. Stick to the basic definitions. Some of the links which provide the very basic details may help

http://en.wikipedia.org/wiki/Component-based_software_engineering

http://en.wikibooks.org/wiki/Computer_programming/Component_based_software_development

http://journals.ecs.soton.ac.uk/java/tutorial/beans/whatis/software-components.html

(The last link although not completely relevant to developing business components but it provides a good way of thinking about components)

As it says-
"The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modeling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.

Component-based software engineering, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics."

You can derive two things from this-
1. Object oriented design and component based design are two separate things
2. It is not difficult to design a component, but it is difficult to identify the relevant components as they are developed independently of any specific context and it is almost impossible to predict all the relevant scenarios in which the component is going to be used.
So even the most generalized components fall short of fulfilling the requirements in all the relevant domains, because software consists of many strongly coupled interacting entities, which cannot be wired together in a straightforward way.

So you should feel lucky if a component designed by you is reused even twice (without change) after its development.

I guess that's the reason why the component specification of frameworks like Java EE does not specify the components as reusable components, but rather they are components which let you develop applications faster as they provide out-of-the-box service support and support for independent deployment

Whatever be it, reusable component development is not a trivial task and certainly very difficult if you are just starting out. So rather then concentrating on the reusable aspect, you should concentrate on the service aspect as described for Java EE while developing the components.

Regards

[Jimmy Clark]

Object oriented design and component based design are two separate things

If the "component" consists of object-oriented code, then object-oriented design principles are a very important part the "component's" design. They are not separate things.

If the "component" was written with COBOL or Visual Basic, in a non-object-oriented way, then object-oriented design principles have nothing to do with the "component's" design. They are not related and are separate things.

The Struts Controller is a good example of a object-oriented "component" that has been, and is globally reused, in many, many applications.

[Ilja Preuss]

Originally posted by Sylvester Camphorian:

As it says-
"The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modeling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.

Frankly, I think that's marketing bullshit. There is nothing about OOD/P that makes it more about modeling the real world, or more intuitive to end users or programmers than other approaches. What OOD/P does is giving you additional tools into the hands - mainly polymorphism - to manage code dependencies, leading to better decoupled systems.

[Jimmy Clark]

English-based keywords and the ability to create English-based classnames, methods and data fields enable object-oriented programmer's to create applications that "seem" to model the "real world" closer than older progamming technologies, e.g. Assembly, Cobol

The ability to create a class named "Customer" or "Account", and the ability to create computing methods named "applyDiscount" or deleteAccountFromLedger" do help us create applications that model the real world easier, in my opinion.

[Ilja Preuss]

Originally posted by James Clark:
English-based keywords and the ability to create English-based classnames, methods and data fields enable object-oriented programmer's to create applications that "seem" to model the "real world" closer than older progamming technologies, e.g. Assembly, Cobol

The ability to create a class named "Customer" or "Account", and the ability to create computing methods named "applyDiscount" or deleteAccountFromLedger" do help us create applications that model the real world easier, in my opinion.

I can easily write a module called Customer or Account with functions called applyDiscount etc. in many structured (non-OO) languages, let alone those "object based" languages. Using names from the domain you are modeling has been done way before OO.

[Jimmy Clark]

Good point.
[ November 23, 2008: Message edited by: James Clark ]

[Nachiket Patel]

Hello guys,
What i understood is,
Business Component should not be developed upfront,
Derive/Separate it when required, for that you need good decoupled OO system in place.

Regards, and thank you
Nachiket.

[Ilja Preuss]

Originally posted by Nachiket Patel:
Hello guys,
What i understood is,
Business Component should not be developed upfront,
Derive/Separate it when required, for that you need good decoupled OO system in place.

Regards, and thank you
Nachiket.

Yes. Plus good refactoring skills, because to actually extract a true component from a system, even if already well designed, you will probably have to make some adjustments to the design.