What patterns fits this problem statement

Given one or many RAID disk controllers who manage zero or more
Logical Disks
of type RAID-0, RAID-1, RAID-50, etc who in turn manage one or more
Physical Disks
propose a pattern for a Storage Management Software (a CLI).

I'have reviewed some documentations on various patterns and am totally
saturated and
can not sort them out....so I went back to my instinct...

I'll have a Shell class responsible for UI issues (now a CLI). Shell
would be aware of
the CLI syntax, input , output, syntax errors, etc...

I'll have a Controller Manager playing the controller (or container)
role. ControllerMgr
will have a list of GenericControllers, extended by Specific
Controller Models.

Each controller object will have a list of LogicalDisks (or Units), a
List of Disks and
a list of Unit-Disks (the mapping or grouping object). Note that
LogicalDisks will also
extend some base_LogicalDisk (an abstract class).

Now let consider a scenario:

print Capacity of Disk-22 on Controller-5.

shellObject would send the following message

try
{
CtlMgr->getObjOfCtl
("Controller-5")->getObjOfDisk("Disk-22")->getCapacity();
}
catch ( myException &e)
{
// etc etc
}

Here is another scenario....

create a RAID-5 logicaldisk on controller-5 using disk-1, disk-2,
disk-3

CtlMgr->getObjOfCtl("controller-5")->makeRaid5(potential
args)->UsingDisk( list of disks )

As you see, this is a very hierarchical arrangement. I have also been
thinking about
having three Managers; Controller_Manager, Unit_Manager, and
Disk_Manager.
But I have a feeling that this would require too much inter manager
communication.

PS: Is the above coding sample acceptable....some hate it for poor
troubleshooting
facilities, but with exceptions that should not be a problem...so I
think...

It looks fine. As long as you minimize the role of the managers.
Just like in real life, the manager's role should be restricted to:
- Routing messages to the appropriate managed entity
- Creating/deleting entities
- Coordinating actions that involve more than one managed entity

See the following articles for details:

http://www.eventhelix.com/RealtimeMa...ignPattern.htm

http://www.eventhelix.com/RealtimeMa...er_pattern.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in PDF

EventHelix.com wrote:
> It looks fine. As long as you minimize the role of the managers.
> Just like in real life, the manager's role should be restricted to:
> - Routing messages to the appropriate managed entity
> - Creating/deleting entities
> - Coordinating actions that involve more than one managed entity

Perhaps also:
Representing the team to the external world.
In other words, taking care of also the outbound
traffic.


-Panu Viljamaa

Medi Montaseri wrote:
>
> Given one or many RAID disk controllers who manage zero or more
> Logical Disks
> of type RAID-0, RAID-1, RAID-50, etc who in turn manage one or more
> Physical Disks
> propose a pattern for a Storage Management Software (a CLI).

First, a couple of nits here.

1) "It" isn't really a pattern if you can introduce "it" as a proposal.
Patterns are discovered, by observing a recurring theme or structure.
This likely means you're talking about a design, which is completely
different, although patterns might apply to or be used in the design.

2) It will probably take more than a little review to start
gleaning useful design ideas from the patterns literature.
The range of detail captured in patterns varies greatly,
and it can be hard to see anything resembling a "big picture"
when you start reading about them. One usually needs to know
about several patterns, operating in concert, to get a feel
for what they accomplish. Keep working on it, it will come.
Reading patterns and working examples in a study group setting
will help immensely.

3) Your subject line asks about patterns which fit a problem statement.
The first that come to mind are:
a) the "what pattern fits" pattern.
b) the "inverse golorp" pattern.
c) the "Oh Oh - got anything I can put in this coffee?
It's too dark to drink" pattern.
d) the "On a clear disk" pattern.
but they're all beyond the scope of the problem you're solving,
so I won't go into any more detail.

Now, getting back to your design problem, the first thing
I notice when reading your description is that it triggers
several heuristic warning buzzers - they just alert me to
things which are likely to be a problem, before I really
even think about it.

Here's what the warnings were:

1) Objects with names ending in 'er'.
2) Multiple objects with names that include
the word 'controller' or 'manager'.
3) The word 'get' appearing in method names
of messages sent from another class.

(1) and (2) are similar, warning that a procedural style of
thinking is being applied to an object oriented design problem.

Buzzer (1) is warning that it might be a problem.
Buzzer (2) is warning that it might be a bad problem.
Since the results tend toward not-so-good when this happens,
I watch out for it whenever I am reviewing designs, including
my own. To shut this warning off, pick one of the objects
with this sort of 'er' name, and throw out the rest. Try to find
objects that still make sense to you, but don't have 'er' at the
end of their names. If you can't, back up, pick one of the other
names to keep, and try again.

(3) is warning of the same thing, but is a bit more specific
about the cause: Some Object is asking other objects for data,
and then doing things with the data. To shut this warning off,
think about the problem by "standing on your head" - try to find
ways to reach a design in which SomeObject is telling other objects
to do something, perhaps giving them some data to use in the doing.

You describe one very important buzzer going off
while you are thinking about this design -
the one that warns you it might be requiring too much
inter-manager communication.

Work toward a design that shuts that buzzer off.
Also, do take very good care of the buzzer, and don't
lose track of it - it is your best friend.

Regards,

-cstb



> I'have reviewed some documentations on various patterns and am totally
> saturated and
> can not sort them out....so I went back to my instinct...
>
> I'll have a Shell class responsible for UI issues (now a CLI). Shell
> would be aware of
> the CLI syntax, input , output, syntax errors, etc...
>
> I'll have a Controller Manager playing the controller (or container)
> role. ControllerMgr
> will have a list of GenericControllers, extended by Specific
> Controller Models.
>
> Each controller object will have a list of LogicalDisks (or Units), a
> List of Disks and
> a list of Unit-Disks (the mapping or grouping object). Note that
> LogicalDisks will also
> extend some base_LogicalDisk (an abstract class).
>
> Now let consider a scenario:
>
> print Capacity of Disk-22 on Controller-5.
>
> shellObject would send the following message
>
> try
> {
> CtlMgr->getObjOfCtl
> ("Controller-5")->getObjOfDisk("Disk-22")->getCapacity();
> }
> catch ( myException &e)
> {
> // etc etc
> }
>
> Here is another scenario....
>
> create a RAID-5 logicaldisk on controller-5 using disk-1, disk-2,
> disk-3
>
> CtlMgr->getObjOfCtl("controller-5")->makeRaid5(potential
> args)->UsingDisk( list of disks )
>
> As you see, this is a very hierarchical arrangement. I have also been
> thinking about
> having three Managers; Controller_Manager, Unit_Manager, and
> Disk_Manager.
> But I have a feeling that this would require too much inter manager
> communication.
>
> PS: Is the above coding sample acceptable....some hate it for poor
> troubleshooting
> facilities, but with exceptions that should not be a problem...so I
> think...