Systems

Integration &
Architecture
IT312
SYSTEMS DESIGN
CHAPTER 3
INTENDED LEARNING OUTCOMES:

1. To identify the people in-charge and those who take

responsibilities in auditing and reviewing
system/subsystem specifications.
2. To recognize different applications concerning system
engineering plan.
 INTRODUCTION
The system/subsystem requirements reviewed by program and
project personnel ensure accurate and complete understanding of
the restrictions of systems design and applied work products.
If program or project plans include reusable software interfaces;
requirements are identified and evaluated for use.
External software interfaces are defined as part of derived software
requirements.

Richard Thayer (2002), "External interface requirements specify hardware, software, or database elements with which a system or component must
interface...." This section provides information to ensure that the system will communicate properly with external components. If different
portions of the product have different external interfaces, incorporate an instance of this section within the detailed requirements for each such
portion.

Reusable software- it can be library or package-piece/set of code that can be used on various application. Ex. piece of library/code for time can be used for other
applications that require time.
INTRODUCTION
To support systems design, graphical representations are
prepared and take the form of
collaboration/communications, data flow, and
component diagrams.
A data flow diagram (DFD) maps out the flow
of information for any process or system. It uses
defined symbols like rectangles, circles and
arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes
between each destination. Data flowcharts can
range from simple, even hand-drawn process
overviews, to in-depth, multi-level DFDs that dig
progressively deeper into how the data is
handled.
 SAMPLE DATA FLOW
DFD can be used to analyze an existing system or model a new one.
Like all the best diagrams and charts, a DFD can often visually
“say” things that would be hard to explain in words, and they work
for both technical and nontechnical audiences, from developer to
CEO. That’s why DFDs remain so popular after all these years.
While they work well for data flow software and systems, they are
less applicable nowadays to visualizing interactive, real-time or
database-oriented software or systems.
UML
UML
Structure diagrams show the things in the modeled system. In a more
technical term, they show different objects in a system.
Behavioral diagrams show what should happen in a system. They
describe how the objects interact with each other to create a functioning
system.
 CLASS DIAGRAM
Class diagrams are the main
building block of any object-
oriented solution. It shows the
classes in a system, attributes, and
operations of each class and the
relationship between each class. In
most modeling tools, a class has
three parts. Name at the top,
attributes in the middle and
operations or methods at the
bottom.

In a large system with many related classes,

classes are grouped together to create class
diagrams. Different relationships between
classes are shown by different types of arrows.
 COMPONENT DIAGRAM

A component diagram
displays the structural
relationship of components
of a software system.
These are mostly used
when working with
complex systems with
many components.

Components communicate with each

other using interfaces. The interfaces are
linked using connectors.
 DEPLOYMENT DIAGRAM
A deployment diagram shows the hardware of your system and the
software in that hardware. Deployment diagrams are useful when
your software solution is deployed across multiple machines with
each having a unique configuration.
OBJECT DIAGRAM

Object Diagrams, sometimes referred to as Instance

diagrams are very similar to class diagrams. Like class
diagrams, they also show the relationship between objects
but they use real-world examples. They show how a system
will look like at a given time. Because there is data
available in the objects, they are used to explain complex
relationships between objects
PACKAGE DIAGRAM
As the name suggests, a package diagram shows the
dependencies between different packages in a system.
Check out this wiki article to learn more about the
dependencies and elements found in package diagrams.
USE CASE DIAGRAM
Profile Diagram
Profile diagram is a new diagram
type introduced in UML 2. This is
a diagram type that is very rarely
used in any specification

Composite Structure
Diagram
Composite structure
diagrams are used to show
the internal structure of a
class. Some of the common
composite structure
diagrams.
 ACTIVITY DIAGRAM
Activity diagrams represent workflows in a graphical way.
They can be used to describe the business workflow or the
operational workflow of any component in a system.
Sometimes activity diagrams are used as an alternative to
State machine diagrams.
State Machine Diagram
State machine diagrams are
similar to activity diagrams,
although notations and usage
change a bit. They are
sometimes known as state
diagrams or state chart
diagrams as well.
These are very useful to
describe the behavior of objects
that act differently according to
the state they are in at the
moment.
Sequence Diagram
Sequence diagrams in UML
show how objects interact
with each other and the order
those interactions occur. It’s
important to note that they
show the interactions for a
particular scenario. The
processes are represented
vertically and interactions are
shown as arrows.
 COMMUNICATION DIAGRAM
In UML 1 they were called collaboration diagrams.
Communication diagrams are similar to sequence diagrams,
but the focus is on messages passed between objects. The
same information can be represented using a sequence
diagram and different objects
Interaction Overview
Diagram
Interaction overview
diagrams are very similar
to activity diagrams.
While activity diagrams
show a sequence of
processes, Interaction
overview diagrams show a
sequence of interaction
diagrams.
Timing Diagram
Timing diagrams are very
similar to sequence
diagrams. They represent
the behavior of objects in a
given time frame. If it’s only
one object, the diagram is
straightforward.
But, if there is more than
one object is involved, a
Timing diagram is used to
show interactions between
objects during that time
frame.
The requirements for a system design definition are
reviewed with applicable users to ensure an accurate
and complete understanding of the restrictions of a
system or subsystem that affect work products. The
external software interface is defined at those levels
and verified for completeness.
The program and project plans at times include
reusable software and identify interface requirements
for use. The external interfaces based on software
architecture definitions also are identified as part of
derived software requirements.

SYSTEMS DESIGN
DEFINITION
 The systems engineering team for programs and
projects is responsible for the development of
software requirements and analyzes the system
architecture and design and allocates system
requirements.
A systems engineering plan (SEP) can be written to
establish system-level technical reviews that could be
conducted for military and aerospace programs and
projects.

SYSTEM
ENGINEERING
PLAN
A systems engineering plan (SEP) is a "living" document that captures a program's current and evolving systems engineering strategy and its relationship with
the overall program management effort. The SEP purpose is to guide all technical aspects of the program.
 The major technical reviews and audits affecting
software and systems include:
• Initial requirements (IR)
• Incremental design review (IDR)
• Final design meeting (FDM)
• Test readiness (TR)
• First-article inspection (FAI)
• Functional configuration audit (FCA)
• Physical configuration audit (PCA)

SYSTEM
ENGINEERING
PLAN
(IDR) formal technical review of prototype design approach for a configuration item (CI) or computer software configuration item (CSCI) including
evaluation of progress, technical adequacy, and risk resolution on a technical, cost, and schedule basis.
The main purpose of the SEP is to address upgraded
processes from a systems engineering point of view.
This plan is organized into three main sections:
1. systems engineering,
2. technical program processes, and
3. engineering integration.
The systems engineering team describes an orderly
and structured approach to the overall system design,
software design/development, required formal
reviews, and audits.
SYSTEM
ENGINEERING
PLAN
It is important to have such a plan to document and
provide the technical expertise to execute activities
throughout a software design/development life cycle.
Using the plan also enables performance to be more
effective and productive and enables technical
planners to spend more time planning, ensuring the
customer will have greater assurance and satisfaction
in addressing the technical challenges that lie ahead.

SYSTEM
ENGINEERING
PLAN
The purpose of software architecture evaluations is to
provide a common approach to developing the work
product architecture.
This evaluation applies to the implementation of
enhancements for change or corrections to existing
software architectures.
This evaluation provides the feasibility and
effectiveness of software architecture definitions to be
applied for software work products.

SOFTWARE ARCHITECTURE
EVALUATION
The software architecture of a system represents the design decisions related
to overall system structure and behaviour.
Architecture helps stakeholders understand and analyze how the system will
achieve essential qualities such as modifiability, availability, and security.
Software architecture supports analysis of system qualities when teams are
making decisions about the system rather than after implementation,
integration, or deployment. Whether designing a new system, evolving a
successful system, or modernizing a legacy system, this timely analysis
enables teams to determine whether the approaches they’ve chosen will
yield an acceptable solution.
An effective architecture serves as the conceptual glue that holds every
phase of the project together for all of its stakeholders, enabling agility, time
and cost savings, and early identification of design risks. Building an
effective architecture that enables rapid product delivery for today’s needs
while also addressing long-term goals can prove challenging. Failing to
identify, prioritize, and manage trade-offs among architecturally significant
qualities often leads to project delays, costly rework, or worse.

SOFTWARE ARCHITECTURE
EVALUATION
Conflicts in requirements, architecture, or program and
project plans should be reported to affected product
teams for resolution.
The objectives of the software architecture are
operational scenarios and system or subsystem
requirements.
The scope of the software architecture does use
interface requirements to analyze operational designs,
software risks, and plans to determine the objectives of
the architecture.

SOFTWARE ARCHITECTURE
EVALUATION
The development of the software architecture is
identified during development and made available and
understood before beginning a software
design/development life cycle.

The program and project plans or schedules are

analyzed to determine the impacts on architecture
development.

SOFTWARE ARCHITECTURE
EVALUATION
Continual evaluations provide:
• The operational scenarios to be reviewed
• The defined system and subsystem requirements to
be analyzed
• The defined system/subsystem interfaces for analysis

SOFTWARE ARCHITECTURE
EVALUATION
Architecture requirements allocate software to gain
a complete understanding of the requirements and the
capabilities of software architectures.
The system or subsystem architecture requirements
determine impacts that would include:
• The impacts to quality factors
• The required functional requirements for the
determination of the software architecture

SOFTWARE ARCHITECTURE
EVALUATION
The trade-offs between quality performance
and the modifications are prioritized and
identified outside system or subsystem
requirements and reviewed to determine if
requirements are to be modified.

The evaluation of the software architecture

does show how well the architecture meets
objectives, constraints, and quality attributes.

SOFTWARE ARCHITECTURE
EVALUATION
The results of software design for architecture changes
are examined to determine appropriate design
methods to ensure problems are always addressed.
One approach to consider is the quantitative technique
for the assessment of quality attributes for designs,
which are dictated by analysis and considerations and
by using your brain.

SOFTWARE ARCHITECTURE
EVALUATION
Software architectural choices are very
subjective and there is no single design that
fits all the scenario and also all sizes of the
system that we want to build. Please, keep
it simple, keep it easily maintainable as well
as easy to comprehend.

CONCLUSION