Chapter- 6

Object Oriented System Design

1
An overview of system design
 Analysis: Focuses on the application domain
 Design: Focuses on the solution domain
 System design is the transformation of the analysis model into a
system design model.
 During system design, developers define the design goals of the project
and decompose the system into smaller subsystems that can be
realized by individual teams.
 Design is about the HOW the system will perform its functions.
 It is also a technical description about how the system will implement
the requirements.
 System Design
 Reduces the gap between requirements and the (virtual) machine
 Decomposes the overall system into manageable parts
2
…Continued
 System design will produce:
 design goals -- what qualities of the system should
developers optimize?
 These are often derived from the non-functional
requirements.
 subsystem decomposition -- the activity of identifying
subsystems, their services, and their relationships to each
other.
 Developers divide the system into manageable pieces to
deal with complexity: each subsystem is assigned to a team
and realized independently. For this to be possible,
developers need to address system-wide issues when
decomposing the system.
 boundary use cases -- configuration, startup, shutdown, etc

3
…Continued

Figure 6.1 The activities of system design (UML activity diagram).

4
System Design Concepts
 In order to reduce the complexity of the solution domain,
we decompose a system into simpler parts, called
“subsystems,”
 subsystem -- a smaller and simpler part of a larger
system.
 a subsystem is made of a number of solution domain
classes.
 often one developer or development team is responsible
for one subsystem.
 By decomposing the system into relatively independent
subsystems, concurrent teams can work on individual
subsystems with minimal communication overhead.

5
…Continued
 A subsystem is characterized by the services it provides to other
subsystems.
 Subsystems provide services to other subsystems.
 service -- a set of related operations that share a common purpose.
 A subsystem providing a notification service, for example, defines
operations to send notices, look up notification channels, and subscribe
and unsubscribe to a channel.
 The set of operations of a subsystem that are available to other
subsystems form the subsystem interface.
 subsystem interface -- a set of operations of a subsystem available
to other subsystems.
 One subsystem provides services to others, specified through its
interface.
 The subsystem interface includes the name of the operations, their
parameters, their types, and their return values.
6
 …Continued
 System design focuses on defining the services provided by each
subsystem that is, enumerating the operations, their parameters,
and their high-level behavior.
 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.
 During system design, we define the subsystems in terms of the
services they provide.
 Later, during object design, we define the subsystem interface in
terms of the operations they provide.

7
 …Continued
 Two properties of subsystems: coupling and coherence
 coupling -- the strength of dependencies between two subsystems(is
an inter-module concept).
 If two subsystems are loosely coupled, they are relatively independent,
and thus, modifications to one of the subsystems will have little impact
on the other.
 If two subsystems are strongly coupled, modifications to one
subsystem is likely to have impact on the other.
 A desirable property of a subsystem decomposition is that subsystems
are as loosely coupled as possible.This minimizes the impact that
errors or future changes have on the correct operation of the system
 Sharing data via attributes increases coupling and should be avoided.
 Don't share attributes; use operations and a well-specified interface.

8
…Continued
 Coherence / cohesion -- strength of dependencies within a
subsystem(is an intra-module concept).
 Focuses on why elements are together
 Only elements tightly related should exist together in a module
 This gives a module clear abstraction and makes it easier to
understand
 If a subsystem contains many objects that are related to each other
and perform similar tasks, its coherence is high.
 If a subsystem contains a number of unrelated objects, its
coherence is low.
 A desirable property of subsystem decomposition is that it leads to
subsystems with high coherence.
 Ideal subsystem decomposition should minimize coupling and maximize
coherence.

9
System Design Activities: From Objects to Subsystems
 System design consists of transforming analysis model into the design
model that takes into account the nonfunctional requirements and
constraints described in problem statement and requirements analysis
document.
 System Design Activities:
 identify design goals from the nonfunctional requirements
 The definition of design goals is the first step of system design.
 It identifies the qualities that our system should focus on.
 Many design goals can be inferred from the nonfunctional requirements or
from the application domain. Others will have to be elicited from the client.

10
 design an initial subsystem decomposition
 The initial subsystem decomposition should be derived from the
functional requirements
 map subsystems to processors and components
 define access control policies
 describes the user model of the system in terms of an access matrix.
This section also describes security issues, such as the selection of an
authentication mechanism, the use of encryption, and the management
of keys
 select a control flow mechanism
 identify boundary conditions
 describes the start-up, shutdown, and error behavior of the system. (If
new use cases are discovered for system administration, these should be
included in the requirements analysis document, not in this section.)

11
…Continued

Activities of system design.

12
Documenting system design
 System design is documented in the System Design Document (SDD).
It describes design goals set by the project, the subsystem
decomposition (with UML class diagrams), the hardware/software
mapping (with UML deployment diagrams), the data management, the
access control, control flow mechanisms, and boundary conditions.
 The SDD is used to define interfaces between teams of developers and
as reference when architecture-level decisions need to be revisited.
 The audience for the SDD includes the project management, the
system architects (i.e., the developers who participate in the system
design), and the developers who design and implement each
subsystem.The following is an example template for a SDD:

13
…Continued

14
An overview of object design
 Object-oriented design includes two main stages, namely,
system design and object design.
 Object-oriented design is concerned with developing an object-
oriented model of a software system to implement the
identified requirements.
 The objects in an object-oriented design are related to the
solution to the problem that is being solved.

15
Object Design concepts
 Object-Oriented methodologies use these terms:
 System Design Activity
 Decomposition into subsystems
 Object Design Activity
 Implementation language chosen
 Data structures and algorithms chosen
 System Design => Service,
 Object Design => API
 ¨ Object design is the process of adding details to the
requirements analysis and making implementation decisions ¨
 The object designer must choose among different ways to
implement the analysis model with the goal to minimize
execution time, memory and other measures of cost.

16
Object design activities
 Object Design consists of 4 Activities
1. Reuse: Identification of existing solutions
• Use of inheritance
• Off-the-shelf components and additional solution objects
• Design patterns
2. Interface specification
• Describes precisely each class interface
The interface specification activities of object design include
• identifying missing attributes and operations
• specifying type signatures and visibility
• specifying invariants
• specifying preconditions and postconditions

17
…Continued
3. Object model restructuring
 Transforms the object design model to improve its understandability
and extensibility
4. Object model optimization
 Transforms the object design model to address performance criteria
such as response time or memory utilization.

18
Managing object design
 This section discusses management issues related to object design.
 There are two primary management challenges during object design:
 Increased communication complexity.The number of participants involved
during this phase of development increases dramatically.
 The object design models and code are the result of the collaboration of
many people.
 Management needs to ensure that decisions among these developers are
made consistently with project goals.
 Consistency with prior decisions and documents. Developers often do not
appreciate completely the consequences of analysis and system design
decisions before object design.
 When detailing and refining the object design model, developers may
question some of these decisions and reevaluate them.
 The management challenge is to maintain a record of these revised
decisions and to make sure all documents reflect the current state of
development.
19
Documenting object design
 Object design is documented in the Object Design Document
(ODD).
 It describes object design trade-offs made by developers,
guidelines they followed for subsystem interfaces, the
decomposition of subsystems into packages and classes, and
the class interfaces.
 The ODD is used to exchange interface information among
teams and as a reference during testing.
 The audience for the ODD includes system architects (i.e., the
developers who participate in the system design), developers
who implement each subsystem, and testers.

20
…Continued

Figure 6.2 Embedded ODD approach. Class stubs are generated from the object design
model. The object design model is then documented as tagged comments in the source code.
The initial object design model is abandoned and the ODD is generated from the source code

21
 Chapter- 7
Software Quality Assurance

22
 Software Quality Assurance
 Software quality assurance is a methodology that determines
the extent to which a software product is fit for use.
 The activities that are included for determining software
quality are:
 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system

23
…Continued
 One reason why quality assurance is needed is because
computers are infamous for doing what you tell them to
do, not necessarily what you want them to do.
 To close this gap, the code must be free of errors or bugs
that cause unexpected results, a process called debugging.
 Once a program code is written, it must be tested to detect
and subsequently handle all errors in it. A number of schemes
are used for testing purposes.

24
object oriented testing
 Testing is a continuous activity during software development.
 In object-oriented systems, testing encompasses three levels, namely,
unit testing, subsystem testing, and system testing.
Unit Testing
 In unit testing, the individual classes are tested. It is seen whether
the class attributes are implemented as per design and whether the
methods and the interfaces are error-free.
 Unit testing is the responsibility of the application engineer who
implements the structure.
 Goal: Confirm that subsystems is correctly coded and carries out the
intended functionality

25
…Continued
Subsystem Testing
 This involves testing a particular module or a subsystem.
 Or testing a Groups of subsystems (collection of classes) and
eventually the entire system
 It involves testing the associations within the subsystem as well
as the interaction of the subsystem with the outside.
 Subsystem tests can be used as regression tests for each
newly released version of the subsystem.

26
…Continued
System Testing
 System testing involves testing the system as a whole and is the
responsibility of the quality assurance team.
 Or testing The entire system
 The team often uses system tests as regression tests when
assembling new releases
 Goal: Determine if the system meets the requirements (functional
and global)

27
…Continued
TESTING STRATEGIES
 The extent of testing a system is controlled by many
factors, such as the risks involved, limitations on resources,
and deadlines.
 In light of these issues, we must deploy a testing strategy
that does the "best" job of finding defects in a product
within the given constraints.
 There are many testing strategies, but most testing uses a
combination of these: black box testing, white box testing,

28
…Continued
Black Box Testing
 The concept of the black box is used to represent a system whose
inside workings are not available for inspection .
 In a black box, the test item is treated as "black," since its logic is
unknown; all that is known is what goes in and what comes out, or the
input and output.
 Black box testing focuses only on functionality
 What the program does; not how it is implemented
 In black box testing, you try various inputs and examine the resulting
output; you can learn what the box does but nothing about how this
conversion is implemented.

29
…Continued
 The Black Box Test is a test that only considers the external behavior of
the system; the internal workings of the software is not taken into
account.
 Black box testing works very nicely in testing objects in an object-
oriented environment.
 Its advantage is Tester can be non-technical. And Test cases can be
designed as soon as the functional specifications are complete.
 Example: Dynamic Application Security Testing (DAST)

30
…Continued
White Box Testing
 White box testing assumes that the specific logic is important and must be tested to
guarantee the system's proper functioning.
 The White Box Test is a method used to test a software taking into consideration its
internal functioning. It is carried out by testers.
 The main use of the white box is in error based testing, when you already have tested
all objects of an application and all external or public methods of an object that you
believe to be of greater importance.
 In white box testing, you are looking for bugs that have a low probability of execution,
have been carelessly implemented, or were overlooked previously .
 White box testing is useful for error-based testing.
 Unlike black box testing white box testing focuses on implementation.
 Example: loop testing, control flow testing, data flow testing, branch
testing, etc.
31
.

End of the course!

32