Pr crc

315
-1

Published on

Man

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
315
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pr crc

  1. 1. Software ArchitectureCRC Card workshop Vakgroep Informatietechnologie – IBCN
  2. 2. CRC Workshops The CRC card workshop is a brainstorm technique using scenario walkthroughs to model the dynamic behavior of a software architecture. For each candidate subsystem, module or submodule in the architecture, a CRC-card is made, featuring :  Class name  Class type : subsystem, module or sub module  Responsibilities : which functionality does the class perform ? (list attributes and methods)  Collaborations : which other classes are needed to realize this functionality ?Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
  3. 3. Module Identification and Function AllocationCRC-cards = Class - Responsibility - Collaboration card = Container for responsibilities Class name : Class type : <system> <subsystem> <module> … Class characteristic : Responsibilities : Collaborations : Describe the functionality List other modules needed of the module to achieve this functionality Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
  4. 4. CRC identificationCRC cards:  Show collaborations between the child modules  Find new responsibilities based on role play  Driven by scenarios and sequence diagrams. Identify new child modulesVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
  5. 5. CRC Role play Once CRC-cards have been drawn up for each candidate, collaborations can be shown in a (sequence) diagram Often, CRC-cards are put on a whiteboard, and are grouped according to the level of collaboration. A technique to check whether all classes, responsibilities and collaborations are identified, consists of assigning each member of the group a set of CRC-cards, and to “play” the scenarios.  Each time an operation is needed, the team member holding the CRC-card of the class involved, checks whether the functionality is listed, which other classes are needed (and which functionality of these collaborating classes is required).  If functionality, attributes or an entire class is missing, the CRC- model is updated, and the role play starts all over again .Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
  6. 6. ExampleClass name : Device Context Manager <module>Responsibilities : Collaborations : Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
  7. 7. ExampleClass name : Transcoder <module>Responsibilities : Collaborations : Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
  8. 8. Software Architecture Document At the end of the session the results of the workshops have to be captured in static & dynamic views.  Static views : component diagrams  Dynamic views : white box sequence diagramsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

×