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

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

Two techniques for relating subsystems together:

Layering: subsystems hierarchy

Partioning: organizes the subsystems as peers

Example: Friend system: we have:DispatureInterface subsystemFieldOfficerInterfaceIncidentManagementResourceManagementMapManagementNotificationManagement

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 notificationLook up channelsSubscribe and unsubscribe a channel

Subsystem interface: set of operations available to other subsystems

Subsystem interface has:Operation namesParameters and typesTheir return values

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

Coupling

Refer to the number of dependencies between subsystems

This has to be low so as to be independent

Refer to FRIEND Example!

Coupling is not the end!

Sometimes it produces more complexity

Consumes time and effort

Cohesion

Number of dependencies within subsystem

High cohesion: the objects are related to each other and perform similar tasks

Refer to book example

7+- 2 rule

If a subsystem offers more than 9 services then something is wrong

More than 7+- layer is not good

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

Closed architecture: layers can access layers below it

Example OSI Open architecture: layers can also

access layers at deeper levels

Architectural styles

Software architecture includes:System decompositionGlobal control flowHandling of boundaryconditions

Intersubsystem communication protocoles

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

2- each subsystem maintains its own database

Majority of systems with large amount of data use repository model

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

Repository 3

They are well suited for applications with

Constantly changing data

Complex data processing tasks

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

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