You are on page 1of 31

System Design

HENDRA RUSDI FARIZI


System Design
Systems design is the bridge between user requirements and programming the
new system.

Approach

Object-oriented design
It is a process by which a set of detailed object-oriented design models are built
and then used by the programmers to write and test the new system.
Overview of Object-
Oriented Programs
◦ An object-oriented program
consists of a set of program objects
that cooperate to accomplish a
result.
◦ Each program object has program
logic and any necessary attributes
encapsulated into a single unit.
◦ These objects work together by
sending each other messages and
working in concert to support the
functions of the main program.
Object-Oriented Design
Models and Processes
The objective of object-oriented
design is to identify and specify
all the objects that must work
together to carry out each use
case.
Object-Oriented Architectural Design
◦ The first step in systems design is architectural design. In most cases, developers begin to
think about how the system will be deployed and what the overall structure will look like
during the early steps of requirements gathering and documentation.

◦ Software systems are generally divided into two types:


• Single-user systems
Single-user systems are found on a single desktop or execute from a server without sharing resources

• Enterprise-level systems
a system that has shared resources among multiple people or groups in an organization. Enterprise-level
systems almost always use client server architectures with multiple layers.
Object-Oriented Architectural Design
Mostly enterprise application using internet base system or network system
Component Diagrams
and Architectural Design
The component diagram identifies
the logical, reusable, and
transportable system components
that define the system
architecture. The essential element
of a component diagram is the
component element with its
interfaces.

Component Diagram Notation:


https://www.lucidchart.com/pages
/uml-component-diagram
Fundamental Principles of Object-Oriented
Detailed Design
The objective of object-oriented detailed design is to identify and
specify all the objects that must work together to carry out each use
case.
The most important model in object-oriented design is
1. Class Diagram
2. Sequence diagram
3. Communication diagram
Object-oriented detailed design steps
No Design Step
1 Develop the first-cut design class diagram showing navigation visibility.
2 Determine class responsibilities and class collaborations for each use
case using class-responsibility-collaboration (CRC) cards
3 Develop detailed sequence diagrams for each use case.
(a) Develop the first-cut sequence diagrams.
(b) Develop the multilayer sequence diagrams.
4 Update the design class diagram by adding method signatures and
navigation information using CRC cards and/or sequence diagrams
5 Partition the solution into packages as appropriate.
Object-oriented detailed design steps (1)
• Develop the first-cut design
class diagram showing
navigation visibility
• Main purpose of class diagram
is to document and describe
the programming classes that
will be built for the new
system.
Object-oriented detailed design steps (1)
• It describes the set of object-
oriented classes needed for
programming, navigation
between the classes, attribute
names and properties, and
method names and properties.
• This info will be used to develop
sequence diagram
Object-oriented detailed design steps (1)
Guidelines for adding visibility navigation
• One-to-many associations that indicate a superior/subordinate relationship
are usually navigated from the superior to the subordinate—for example,
from Sale to Sale Item.
• Mandatory associations, in which objects in one class can’t exist without
objects of another class, are usually navigated from the more independent
class to the dependent class—for example, from Customer to Sale.
• When an object needs information from another object, a navigation arrow
might be required, pointing either to the object itself or to its parent in a
hierarchy.
• Navigation arrows may be bidirectional.
Class Diagram
Notation
Class Diagram Notation:
https://www.uml-
diagrams.org/class-reference.html
Example of first Cut of class diagrams from use case diagram
Object-oriented detailed design steps (2)
• Second step is detailed design with CRC Cards
• CRC cards a brainstorming technique for designing interactions in use cases
by assigning responsibilities and collaborations for classes
Object-oriented detailed design steps (2)
Step to create detailed design with CRC cards
• Selecting a use case
• Identifying the problem domain class that has responsibility for this use case
• Identifying other classes that must collaborate with the primary object class
to complete the use case
Example of final CRC Cards
Object-oriented detailed design steps (3)
• Third step is develop detailed
sequence diagrams for each use
case
• Sequence diagrams type of
interaction diagram that
emphasizes the sequence of
messages sent between objects for
a specific use case
• First step to detailed sequence
diagram of each use case, is
creating first cut of sequence
diagram
Object-oriented detailed design steps (3)
After develop, first cut of
system design, develop the
multilayer sequence
diagrams.
Class Diagram
Notation
Class Diagram Notation:
https://www.uml-
diagrams.org/class-reference.html
Object-oriented detailed design steps (3)
MVC as common design pattern to develop system
MVC divides an application into three interconnected parts (model, view,
controller)
• Model is the component that manages the data, logic and rules of the
application.
• View can be any output representation of information, such as a chart or
a diagram.
• Controller, accepts input and converts it to commands for the model or
view
Object-oriented detailed design steps (3)

Example of final CRC Cards


Object-oriented detailed design steps (3)
• entity class a design identifier for a problem
domain class
• boundary class, or view class a class that exists
on a system’s automation boundary, such as an
input window
• control class a class that mediates between
boundary classes and entity classes, acting as a
switchboard between the view layer and domain
layer
• data access class a class that is used to retrieve
data from and send data to a database
Object-oriented detailed design steps (3)
• entity class a design identifier for a problem
domain class
• boundary class, or view class a class that exists
on a system’s automation boundary, such as an
input window
• control class a class that mediates between
boundary classes and entity classes, acting as a
switchboard between the view layer and domain
layer
• data access class a class that is used to retrieve
data from and send data to a database
Object-oriented detailed design steps (4)
Fourth step is Update
the design class diagram
by adding method
signatures and
navigation information
using CRC cards and/or
sequence diagram
Object-oriented detailed design steps (5)
Fifth step is Partition
solution into packages as
appropriate. Package
diagram is a model that use
separate class diagram into
each package. In summary,
package diagrams show
related components and
dependencies.
Fundamental Detailed Design Principles

Coupling
Coupling is a qualitative measure of how closely the classes in a design class
diagram are linked. A simple way to think about coupling is as the number of
navigation arrows on the design class diagram. Low coupling is usually better
for a system than high coupling. In other words, fewer navigation visibility
arrows indicate that a system is easier to understand and maintain.
Fundamental Detailed Design Principles

Cohesion
Cohesion is qualitative measure of the focus or unity of purpose within a single
class. Cohesion refers to the consistency of the functions within a single class.

Protection from variations


is design principle in which parts of a system that are unlikely to change are
segregated from those that will. Try to isolate the parts that will change from
those that are more stable.
Fundamental Detailed Design Principles
Cohesion
Cohesion is qualitative measure of the focus or unity of purpose within a single
class. Cohesion refers to the consistency of the functions within a single class.

Protection from variations


is design principle in which parts of a system that are unlikely to change are
segregated from those that will. Try to isolate the parts that will change from
those that are more stable.
Fundamental Detailed Design Principles
Indirection
is the principle of decoupling two classes or other system components by placing an
intermediate class between them to serve as a link. In message terminology, don’t send a
message from A to B; let A send the message to C and then let C forward it to B.

Object Responsibility
Is a design principle in which objects are responsible for carrying out system processing. These
responsibilities are categorized in two major areas, knowing and doing. “Knowing” includes an
object’s responsibilities for knowing about its own data and knowing about other classes with
which it must collaborate to carry out use cases. “Doing” includes all the activities an object
does to assist in executing a use case.
THANKS