Scribd
Upload
65 views

Chapter No.6 System Design: Decomposing The System

The document discusses system design concepts including: 1) Subsystems decompose a system into smaller manageable pieces to reduce complexity, with each subsystem having well-defined interfaces and encapsulating classes. 2) Services define the operations a subsystem provides to others through its interface. 3) Coupling and cohesion, layers, partitions, and architectural styles further guide subsystem design.

Uploaded by

Abdul Rahman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
65 views

Chapter No.6 System Design: Decomposing The System

The document discusses system design concepts including: 1) Subsystems decompose a system into smaller manageable pieces to reduce complexity, with each subsystem having well-defined interfaces and encapsulating classes. 2) Services define the operations a subsystem provides to others through its interface. 3) Coupling and cohesion, layers, partitions, and architectural styles further guide subsystem design.

Uploaded by

Abdul Rahman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Chapter no.

6
System Design: Decomposing the System
6.2: An overview of system design
Analysis results in the requirements model described by the following
products:
• a set of non-functional requirements and constraints
• a use case model
• an object model
• a sequence diagram for each use case.
The analysis model describes the system completely from the actors’ point of
view and serves as the basis of communication between the client and the
developers.
Continue…..
The analysis model, however, does not contain information about the internal
structure of the system, its hardware configuration, or more generally, how
the system should be realized. System design is the first step in this direction.
System design results in the following products:
• design goals, describing the qualities of the system that developers should
optimize
• software architecture, describing the subsystem decomposition in terms of
subsystem responsibilities
• boundary use cases, describing the system configuration, start-up,
shutdown, and exception handling issues.
Continue…..
The design goals are derived from the non-functional requirements. Design
goals guide the decisions to be made by the developers when trade-offs are
needed. The subsystem decomposition constitutes the bulk of system design.
Developers divide the system into manageable pieces to deal with complexity
Relationship of system design with other
software engineering activities
6.3: System Design Concepts
6.3.1: Subsystems and Classes
6.3.2: Services and Subsystem Interfaces
6.3.3: Coupling and Cohesion
6.3.4: Layers and Partitions
6.3.5: Architectural Styles
6.3.1: Subsystems and Classes

• In order to reduce the complexity of the application domain, we identified


smaller parts called “classes” and organized them into packages. Similarly,
to reduce the complexity of the solution domain, we decompose a system
into simpler parts, called “subsystems,” which are made of a number of
solution domain classes.
• A subsystem is a replaceable part of the system with well-defined interfaces
that encapsulates the state and behaviour of its contained classes.
Example:
• For example, the accident management system we previously described can
be decomposed into a DispatcherInterface subsystem, realizing the user
interface for the Dispatcher; a FieldOfficerInterface subsystem, realizing the
user interface for the FieldOfficer; an IncidentManagement subsystem,
responsible for the creation, modification, and storage of Incidents; a
ResourceManagement subsystem, responsible for tracking available
Resources (e.g., FireTrucks and Ambulances); a MapManagement for
depicting Maps and Locations; and a Notification subsystem, implementing
the communication between FieldOfficer terminals and Dispatcher stations.
Continue…..
• In UML, components can represent both logical and physical components.
• A logical component corresponds to a subsystem that has no explicit run-
time equivalent, for example, individual business components that are
composed together into a single run-time application logic layer.
• A physical component corresponds to a subsystem that as an explicit run-
time equivalent, for example, a database server.
This subsystem decomposition using UML components:
6.3.2: Services and Subsystem Interfaces

• A subsystem is characterized by the services it provides to other


subsystems.
• A service is a set of related operations that share a common purpose.
• The set of operations of a subsystem that are available to other
subsystems form the subsystem interface.
• The subsystem interface includes the name of the operations, their
parameters, their types, and their return values.
• Object design will focus on the application programmer interface
(API), which refines and extends the subsystem interfaces. The API also
includes the type of the parameters and the return value of each operation.
Continue…..
• Provided and required interfaces can be depicted in UML with assembly
connectors, also called ball-and-socket connectors.
• The dependency between two subsystems is shown by connecting the
corresponding ball and socket in the component diagram.

You might also like