Hi Jie
> 1. If it is a quite large system, should/Could the subsystems
> be recognised
> and the supersystem can be divided into a number of
> subordinate subsystems.
> Then start to identify the actors, use cases for the supersystem and
> individual subsystem respectively.
Yes, you could do this but only for one level down and you are working with
a system of systems.
RUP has a nice paper about "System of Systems" that talks about these ideas.
If your subsystem is really a standalone system in its own right - then it
would make sense to work on this as a seperate project - starting from the
begining by identifying actors, use cases, etc. The other systems would be
possible actors, etc. This is only really needed in really big/complex
systems. Don't go more than one level down (ie the first level of systems
below the top level are treated as systems in their own right). Go deeper
with smaller use cases and you start functional decomposition: use cases
that deliver no value because they are so small.
I have only ever worked on one system that warranted this approach - it was
a very large, complex system for handling the shipment of freight around the
world - and each "subsystem" was a seperate product that the customers could
choose to buy an install.
As an aside - we did use cases for the overall system - and came up with 8
use cases for the whole thing ("Import Goods", and "Export Goods" where two
of them - these processes are sufficiently different to be seperate use
cases). Each subsystem did have use cases that just concerned themselves
with the functional requirements for that subsystem.
> 2. If the subsystems are found during architecture design as
> I have learnt
> from OOAD course, do we need to identify the actors and use
> cases for each
> subsystem before we start to design the subsystem, or as the
> OOAD course
> suggested what we should do is to identify the subsystem
> elements within the
> subsystem and distribute the subsystem behavior to subsystem
> elements.
As I mentioned above - if this is truely a system of systems, each subsystem
really needs to be treated as a system in its own right - and probably as a
seperate project in its own right. If you get to this stage (and you
probably hit this during the first iteration) - perhaps spin these out as
seperate projects and start from the begining for each of them.
Back to subsystems for a bit - the RUP activities mentioned in the Rational
OOAD course after architectural design talk specifically about subsystem
design - where the operations on the subsystem interfaces are worked on
end-to-end. By this, I mean you look at an operation on the interface,
decide how it could be realised in the subsystem and come up with an
"interface operation realisation" (not an official term - but essentially
what you are doing). This looks just like doing a use case realisation -
you just don't need to have a use case involved.
RUP does not officially mention this as I recall, neither does the Rational
OOAD course - but this idea about designing subsystem interface operations
is like building a use case realisation helped me keep the ideas clear in my
mind.
Sorry this is so long - hope it helps a bit
anthony
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
