I am an eager enthusiast (is that redundant?) of CrcCard
s as an analysis tool. I am interested in whether anyone has applied the concept to the next level UP (or the next activity PRIOR) to CRC.
Has anyone tried Subsystem-Responsibilities-Collaborators Cards? We have a set of use cases that detail the functionality required for a distributed system. We need to establish more detailed requirements for each of the subsystems so that we can apportion work and get started on more detailed design.
Has anyone attempted to use SrcCards
in this manner? Are there any gotchas involved in applying this practice at a higher level of abstraction? Across distributed system boundaries? -- BillBarnett
I've used CrcCard
s to define the responsibilities of components. It was just like defining classes. The technical details of which things are in which address space, time slice or physical hardware should usually be ignored at the CrcCard
level of abstraction. Try it out and see. Cards are cheap. -- EricHodges
Using this approach at an even higher system level is described as Fortress-Ally-Responsibility cards in Software Fortresses: Modelling Enterprise Architectures
by Roger Sessions and Janet Van Sickler. The "Fortresses" you are modelling here represent whole applications (or clusters of them) that operate as sort of an atomic unit of processing focus and trust. -- bb
Class-Responsibility-Collaboration, Component-Responsibility-Collaboration, Subsystem-Responsibility-Collaboration, etc... do I smell a pattern? Maybe we should just start calling them XrcCards?
? -- MikeSmith