CS3SADe22 - CS3SAD/CSMDAS:SoftwareArchitectureandDesign

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
CS3SAD/CSMDAS: Software Architecture and Design Week 3: Complex components and connectors, Simple  architectural styles Exercise sheet 2: Four Questions Question 1 This architecture is too big and complex. Can you make it more manageable by  replacing two (separate) groups of components by two composite components?  Redraw the architecture with composite components shown. (Be careful with your  notation! Marks are taken off for not complying to the visual standard.) Note that there are several reasonably good ways to do this. Justify your particular  choice.  Answer to Question 1 A group of components  should  be converted into a composite component  if, and only  if,  their collective functionality satisfies our definition of a component: that is, if  The group can be considered as a software package (is modular, encapsulates  a cohesive set of functions, is – hopefully -- reusable) Can be independently replaced (substitutable) –in other words,  we could  potentially replace the group with a different  single  component that does all  their work Provides  and  requires  services based on specified interfaces – we can identify  the provided and required interfaces needed to make  the group function. The  two groups of components can be classified as The loan subsystem. This is  at least  the connected  LoansSys  and  PenaltySys  component.  PenaltySys  is not needed by other components, and its  functionality might best be encapsulated within a composite Loans subsystem  component. It  could  also contain the  LoansDeskSys  component – this would  then extend the subsystem’s purpose to presenting functionality for the loans  desk frontend GUI. The maintenance subsystem – the bits of the system that have to do with  maintaining the catalogue of books. This consists of  at least   MaintenanceSys,  OrderingSys  and  RepairsSys . It  could  also   contain the  AdminSys  component –  this would then extend the subsystem’s purpose to include maintaining user  details and presenting functionality for the administrator’s frontend GUI.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
I cannot see any other possible groups of components in the architecture that could be  considered as encapsulated cohesive software packages.  For instance,  BrowserSys CatalogueSys  and  UserSys  can be considered as a  subsystem whose purpose is to present views on user and catalogue data for the  library’s browser frontend.  However,  the  CatalogueSys  and  UserSys  components are  used by many other parts of the system in ways that have nothing to do with the  library browser frontend. This makes the functionality of these three components not 
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 12/09/2011 for the course ECE 750-T11 taught by Professor Ladan during the Fall '11 term at Waterloo.

Page1 / 10

CS3SADe22 - CS3SAD/CSMDAS:SoftwareArchitectureandDesign

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online