1.  Design goals are derived form the non- functional requirements  Every subsystem is assigned to a team and realized independently  During system design, we define subsystems in terms of the services they provide

2.  Service: set of related operations  Later in the object design, we define subsystem interfaces in terms of operation they provide  Coupling: dependences between subsystems  Cohesion: dependencies between classes

3.  Two techniques for relating subsystems together:  Layering: subsystems hierarchy  Partioning: organizes the subsystems as peers

4.  Example: Friend system: we have: DispatureInterface subsystem FieldOfficerInterface IncidentManagement ResourceManagement MapManagement NotificationManagement

5. Services and subsystem interfaces  Subsystem is characterized by services it provides to other susbsystems  Service: set of operations that share common purpose:  Notification services has operations: Send notification Look up channels Subscribe and unsubscribe a channel

6.  Subsystem interface: set of operations available to other subsystems  Subsystem interface has: Operation names Parameters and types Their return values

7.  Object design focus more on API, which refines and extends subsystem interfaces  When writing subsystem interfaces, stive to minimize the amount of information provided about implementation  This lowers coupling

8. Coupling  Refer to the number of dependencies between subsystems  This has to be low so as to be independent  Refer to FRIEND Example!

9. Coupling is not the end!  Sometimes it produces more complexity  Consumes time and effort

10. Cohesion  Number of dependencies within subsystem  High cohesion: the objects are related to each other and perform similar tasks  Refer to book example

13. 7+- 2 rule  If a subsystem offers more than 9 services then something is wrong  More than 7+- layer is not good

14. Layers and partitions  Layer: grouping of subsystems providing related services  Usually layers can only depend on layers at lower level  Has no knowledge of above layers

15.  Closed architecture: layers can access layers below it  Example OSI  Open architecture: layers can also access layers at deeper levels

17. Architectural styles  Software architecture includes: System decomposition Global control flow Handling of boundaryconditions Intersubsystem communication protocoles

18. Repository  Subsystems must exchange data so that they can work together  We have two ways for doing so: 1- All shared data is held in central database * all subsystems access it * this is called Repository model

19. 2- each subsystem maintains its own database  Majority of systems with large amount of data use repository model

20. Repository 2  Subsystems access and modify a single data structure called repository  Here subsystems are independents  Interact only through repository  Repository has no knowledge of subsystems

21. Repository 3  They are well suited for applications with Constantly changing data Complex data processing tasks

22. Where it is Used?  Mainly used in DBMS  Such as banks and payroll, MIS, CAD  Coz easy to manage integrity and concurrency between subsystems  Repository can sometimes invoke subsystems when the data state change  BLACKBOARD systems

23. Repository disadvantages  Single repository can be bottleneck  Coupling between subsystem and the repository is high  Evolution is difficult  Distributing repository over number of machines is difficult