I would agree with everything Bruce says, except I usually place the interface outside the subsystem and make the architect (or the designer of the next level up) the owner. That way any changes to the interface are more explicitly controlled.
However, Bruce's suggestion is a reasonable approach before the interface has been published (i.e.. before any dependencies exist outside the subsystem). In RUP, the need these interfaces are discovered by the developers during UC Analysis, are refactored by the architect at the end of UC Analysis, and are defined, formalised and then assigned to subsystems during Architectural Design activities. This basically means that the negotiations (for an iteration) are finished before the interface is assigned to a subsystem - the interface is published and design 'road-tested' before the implementation is written. Regards, Dave. -- Davyd Norris - Consultant Regional Services Organisation (Asia Pacific) Rational Software Level 2, 459 Collins Street Melbourne, Vic 3000 Australia. Phone: +61 3 9613 9632 Fax : +61 3 9613 9699 HDesk: +61 2 9419 0111 -- > -----Original Message----- > From: Bruce Douglass [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 21 November 2001 3:35 AM > To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: (ROSE) Re: (OTUG) Questions on subsystem component > architecture > and subsystem inter faces > > > > Subsystems may have as many interfaces as necessary. I would > certainly NOT > recommend one per client, but it is usually possible to group > clients into > areas of common interest. For example, a subsystem might have > a functional > interface (providing the major functionality of the > subsystem), a control > interface (which sets how the subsystem should operate), and > a management > interface (for maintenance and updates), or you may find that > you need 3 or > 4 functional interfaces. Probably not significantly more than > that though. > The interfaces of a component or subsystem should be owned by the > developers of that subsystem or component, but are specified > in negotiation > with the customers or clients of that interface. > > At 11:08 AM 11/20/2001 -0500, Gibbs, Dennis wrote: > > Greetings, > > > > A topic of discussion has come up on a project I am > working on. It > >concerns subsystem component > > architecture, and subsystem interfaces. In > discussing this topic, > >we discovered all of us have > > widely differing perspectives and experiences :-) > > > > Background: We are trying to come up with a solid > architecture for > >a fairly large system. > > The system is a web-based system implemented in > J2EE. We want to > >create a component-based > > architecture. The system has ten separate business > areas that will > >be designed and built over the > > next 4 years. The ten business areas will utilize > the shared > >services of several components > > that we refer to as "common components". The > controversy involves > >the definition of the interfaces > > to these common components. The questions are: > > > > 1) How many interfaces (JAVA) should a shared > common component have? > > > > In UML, subsystems are usually represented with one > interface class > >and one proxy class that implements the interface and then delegates > >functionality to other hidden classes within the > component/subsystem. In our > >case, the clients may ask for component functionality > particular to them. > > > > 2) Does this warrant a separate interface for each > different client > >therefore hiding the functionality not relevant to them? > > > > 3) If so, should the interfaces all have separate > proxy classes? > > > > Another scenario is that the client asks for a > particular object > >from the component, and then performs operations on it > before giving it back > >to the component to store to the database. > > > > 3) Should the client be given the object, a > separate interface to > >operate on that object, or not be given the object at all > and always be > >working through one standard interface? > > > > 4) If the client is given the interface, should > this interface also > >have a proxy class inside the component that implements it? > > > > 5) If the client is not given the object, could > there be performance > >issues related to not having the object locally? > > > > 6) Who owns the interfaces - the client developers > developing > >against them or the component developers implementing them? > > > > Comments? Advice/suggestions? > > > > Thanks for any help > > > > Dennis > > > > > >----------------------------------------------------------------- > >To unsubscribe from OTUG, send an email to [EMAIL PROTECTED] > >with the word 'unsubscribe' in the body of the message. > > ************************************************************** > ********** > * 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/support/usergroups/rose/rose_forum.jsp > * Other Requests: [EMAIL PROTECTED] > * > * To unsubscribe from the list, please send email > * > * To: [EMAIL PROTECTED] > * Subject:<BLANK> > * Body: unsubscribe rose_forum > * > ************************************************************** > *********** > ************************************************************************ * 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/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * *************************************************************************
