Decomposition Strategies: How apply?

[Demetrio Carvalho]

Hello. I am new in architect studies. Could someone indicate me some Tutorials about Decomposition Strategies? I read about ten strategies divided in five groups. I wolud like to understand exactlly what mean in details each one and how I should apply.
The strategies are divided this way:
Group 1: Layering or Distribution
Group 2: Esposure, Functionality, or Generality
Group3: Coupling, Cohesion or Volatility
Group4: Configuration
Group5:Planning and Tracking or Work Assignment
The author Mark Cade states on the book I am reading now:"For ane strategies that are grouped together, you chose one of the strategies and then move on to the next grouping." I didn't understood how do this.

Hugs

[Jeanne Boyarsky]

Demetrio,
Welcome to CodeRanch!

Demetrio Carvalho wrote:The author Mark Cade states on the book I am reading now:"For ane strategies that are grouped together, you chose one of the strategies and then move on to the next grouping." I didn't understood how do this

He means that first you group by, say, layers. Then within each layer group, you further decompose by, say, functionality.

For example, suppose you first decompose by layer and get session beans being a layer. There are way too many things in that layer. So then you decompose further by part of the application and have functionality specific packages.

[Demetrio Carvalho]

Jeanne Boyarsky wrote:Demetrio,
Welcome to CodeRanch!

Demetrio Carvalho wrote:The author Mark Cade states on the book I am reading now:"For ane strategies that are grouped together, you chose one of the strategies and then move on to the next grouping." I didn't understood how do this

He means that first you group by, say, layers. Then within each layer group, you further decompose by, say, functionality.

For example, suppose you first decompose by layer and get session beans being a layer. There are way too many things in that layer. So then you decompose further by part of the application and have functionality specific packages.

Jeanne, thank for your anwswer.
Please, could someone indicate some tutorial or step by step example how to decompose by layer, functionality, and so on?

Hugs.

[Jeanne Boyarsky]

I provided an example. Granted it was small, but it was still an example. What kind of information are you looking for?

[Remacle Ludovic]

Demetrio, have you find a tutorial ?

Jeanne, can you give an other example more practice.

In advance thanks for your help.

Ludo.

[Jeanne Boyarsky]

Ludo,
Welcome to CodeRanch!

Let's try it as an exercise this time. Reading about this only helps so much. You really need to try it. So try the following example. You can post your answer here for comments.

Suppose I have the following things in my sandwich shop:

jelly

lettuce

peanut butter

pickle

onion

roast beef

rolls

rye bread

tomato

turkey

wheat bread

white bread

wraps

Now suppose you want to decompose this list in two passes so you have no more than 3 items in a category at the end. Post your thoughts on how you could decompose the list. What strategy would you use first? Why? What would you do next?

[Demetrio Carvalho]

Ludo, I didn't find some tutorial yet. Did yoy find something?

Jeanne, thanks again. I have been programmer for a long time, but now I am doing my best to understand the architecture issues. Of course I have applied some best pratices and design patterns (for ex.: MVC) for a long time. But now, I want to understand and discuss whitch is better for each case. And when I read about Decomposition Strategies, I really got confused.
Well, I would group by similarities. But I supposed you are expect more about my answer. Could you indicated me some article to read about the strategies?

Group 1:

jelly

peanut butter

Group 2:

lettuce

pickle

onion

tomato

Group 3:

roast beef

rolls

rye bread

turkey

wheat bread

white bread

wraps

Jeanne Boyarsky wrote:Ludo,
Welcome to CodeRanch!

Let's try it as an exercise this time. Reading about this only helps so much. You really need to try it. So try the following example. You can post your answer here for comments.

Suppose I have the following things in my sandwich shop:

jelly

lettuce

peanut butter

pickle

onion

roast beef

rolls

rye bread

tomato

turkey

wheat bread

white bread

wraps

Now suppose you want to decompose this list in two passes so you have no more than 3 items in a category at the end. Post your thoughts on how you could decompose the list. What strategy would you use first? Why? What would you do next?

[Jeanne Boyarsky]

Ludo,
There is more than one correct answer to this question. Feel free to give it a try as well.

Demetrio,
Group 1 and 2 are fine. (group 2 can't be decomposed more and still make sense). Group 3 still has two unrelated things in it. Think about what you would name each group. Group 1 could be "lunch spreads". What would group 2 and 3 be? I expect you will have trouble coming with a name for group 3 which points you towards the problem. Let's try it again. I've given an extended example below. This time rather than trying to go straight to the answer; do it in passes. Can you divide the items I gave into 2-3 groups and give each a name? Then can you divide the big groups further.

As far as references go, I can't point you to an article. I learned this a long time ago; I don't remember where but it was likely in a school textbook and not in article form. Keep going with the exercise I gave though. Thinking about it and the discussion thereof will help you grok it. (I may write an article based on the discussion here as I didn't find anything on googling it.)


Extended example:
# cream cheese
# jelly
# ketchup
# lettuce
# mayo
# mustard
# peanut butter
# peppers (green)
# peppers (red)
# pickle
# onion
# roast beef
# rolls
# rye bread
# tomato
# turkey
# wheat bread
# white bread
# wraps

[Jeanne Boyarsky]

This thread inspired me to write an article/blog post with an example and answer.

[P Das]

Above, what is shown can be termed "bottom up" approach of decomposition; however, it is not always possible to follow this line in practice since you need to have all the classes or components before you could classify them following this approach--a paradox since the very purpose of decomposition is to find the classes or components. Hence, you need to follow some blueprint--e.g. Sun's--or other rules of thumb to find roughly what large divisions (or layers or overall components) would be. For example, you may decide to have a presentation, a business logic, and a persistence layer. Here, again, you need to ponder over tradeoffs between one/two/three tier architectures and your domain/requirements. I spoke about layers as if they were components because then you will be encouraged to create overall interfaces for each of them--improves loose coupling. Next, you may focus on each one of these larger components to find out how should you divide their tasks among smaller components or classes.

However, often, you might start with some larger components and some fine-grain ones when you create an architecture in the real world--yet another paradox--which probably tells us about the inscrutable way our brain works!

Probably, the best way to find out is by dirtying your hands--take some requirements and start working on them. If you have a qualified guide, nothing's better than that.

[Jeanne Boyarsky]

I agree. I use bottom up for the purposes of example. In a real system, things are often much higher level. The same techniques apply. They just happen at a component/package level or system/subsystem level.