CHAPTER 6 NOTES

Foundations for Systems Design

Systems Analysis and Design in a Changing World, 7th Ed

1. What is Systems Design?

Before we get into design, let's understand the big picture. Building a system happens in three
phases:

Phase What it does Simple Analogy

Analysis Figures out WHAT the system must do Drawing up a wish list for your
(requirements) dream house
Design Figures out HOW the system will be built Creating the architectural
blueprint
Implementation Actually builds the system (coding) The construction workers
building the house

Design is the bridge between analysis and implementation. Programmers should not have to
guess how things should work — design tells them exactly.

💡 Think of it this way: Analysis says 'we need a login screen'. Design says 'the login screen will look
like this, connect to this database, and check passwords using this method'.

Key Points about Systems Design:

• Analysis provides the starting point for design
• Design provides the starting point for implementation (coding)
• Design documents and models are created to coordinate everyone's work
• The objective of design is to define, organise, and structure all the components of the
final solution — it is a blueprint for construction

Important Quote to Remember:

"A programmer who jumps into code without carefully thinking it through ends up with
errors, patches and poorly structured systems. This is often referred to as cowboy
programming."
💡 This is why we do design first — no cowboy coding!
2. Analysis vs. Design Models
During analysis, you create models that describe what the system must do. During design, you
convert those into models that describe how it will be built. Here is how they map:

Analysis Model (Requirements) Design Model (Solution)

Domain model class diagram Component diagrams & Deployment diagrams
Use case diagrams Design class diagrams
Activity diagrams & Use case descriptions Interaction diagrams (sequence diagrams)
System sequence diagrams Design state machine diagrams
Requirements state machine diagrams Package diagrams

💡 You don't throw away your analysis work — you convert it and build on it during design.

3. Major Components of a System Design

When we design a system, we need to think about ALL the physical and software pieces that
make the system run. The diagram in the slides shows a network with:
• Mobile phones connecting wirelessly
• Wi-Fi enabled devices via the internet
• An application server (runs the software logic)
• A database server (stores all the data)
• Internal desktop computers
• Foreign/external systems that the system must communicate with

💡 The green 'cloud' in Figure 6-1 represents the system environment — everything inside the
boundary is what WE are responsible for designing.

Remember the Perfect Technology Assumption from Chapter 3:

• During analysis: ignore things like logins, backups, security (pretend technology is
perfect)
• During design: NOW you must include all those things — logins, backups, security, error
handling, etc.

4. Design Activities
There are five main design activities. Think of these as the five big tasks a designer must
complete:
 Design Activity Key Question It Answers
1. Describe the environment How will this system interact with other systems and existing
technologies?
2. Design the application What are the key parts of the system and how will they interact when
components deployed?
3. Design the user interface How will users interact with the system?
4. Design the database How will data be captured, structured, and stored?
5. Design the software classes What internal structure will each component have to ensure efficient,
and methods reliable operation?

Activity 1: Describe the Environment

This activity is about understanding and documenting the technical environment in which the
system will operate. There are two key elements:

Element A: Communications with External Systems

Most systems don't stand alone — they talk to other systems. You need to design HOW they
communicate:
• Message formats — what structure does the data take?
• Web and networks — how does data travel?
• Communication protocols — what 'language' do systems use to talk to each other?
• Security methods — how do we protect data in transit?
• Error detection and recovery — what happens if something goes wrong?

Real-world examples:
◦ A library system reads patron details from another university system
◦ An HR payroll system communicates with SARS (South African Revenue Service)

Element B: Conforming to Existing Technology Architecture

Technology Architecture = the set of computing hardware, network hardware, and system
software that an organisation already uses.
The designer must discover and document what already exists:
• Servers and desktop computers
• Mobile devices
• Operating systems

💡 You cannot design a new system without knowing what technology the organisation already has —
your design must fit in with it.
Activity 2: Design the Application Components
A component is a well-defined unit of software that performs one or more functions. In this
activity, designers decide how to package the software into components.

Key decisions to make:

• Scope and size — What functions does each component perform? What are its
boundaries and interfaces?
• Programming language — What languages are approved for use?
• Build or buy — Can we buy existing software instead of building from scratch?
• Partition into subsystems — Break the large system into smaller, manageable parts
• Database infrastructure — How will the system connect to the database?
• Multilayer design — Organise the software into layers (View layer, Domain layer, Data
Access layer)

💡 The multilayer design separates the user interface, the business logic, and the data access into
separate layers. This makes the system easier to maintain and update.

Models produced during this activity include:

• Package diagrams — show how components are grouped
• Component diagrams — show how components connect to each other
• Deployment diagrams — show which hardware each component runs on

Activity 3: Design the User Interface

The user interface (UI) is what the user sees and interacts with. This is extremely important
because:

"To most users, the user interface IS the system!"

• A poor UI can destroy user productivity, even if the system works perfectly underneath
• Requires heavy user involvement — the users know what they need
• Includes both analysis tasks (understanding what users need) AND design tasks
(creating the actual screens)

In today's world, you need to design for MULTIPLE devices:

• Desktop computers (large screens)
• Smartphones (small screens, touch input)
• Tablets and iPads
• Wireless/mobile devices
The UI design process:
• Starts with requirements from analysis (use case flows, system sequence diagrams)
• Design adds: screen layout, look and feel, navigation, and user experience (UX)
• Storyboards are used to prototype and plan screen designs before coding begins

💡 A storyboard is a series of sketches showing how users will move through the screens — like a
comic strip of the system.

Activity 4: Design the Database

Every system needs to store data somewhere. The database design activity decides how that
data will be organised and stored.

The process:
• Start with the domain model class diagram (from analysis) or an Entity Relationship
Diagram (ERD)
• Choose the database structure — usually a relational database (like MySQL,
PostgreSQL, SQL Server)
• Design the database architecture — will it be centralised (one server) or distributed
(multiple servers)?
• Design the database schema — create the tables and columns

Other technical issues to address:

• Throughput and response time — how fast must the database respond?
• Security — who can access what data?

💡 A relational database stores data in tables (like spreadsheets). Each table has columns (fields) and
rows (records). For example, an InventoryItem table might have columns: productItem, inventoryItem,
size, color, options, quantityOnHand, etc.

Activity 5: Design the Software Classes and Methods

This is also called detailed design. It goes deep into how each piece of software will actually
work internally.

Using the analysis models, you develop detailed designs for each use case using:
• Design class diagrams — show all the classes (objects) with their attributes and
methods (functions)
• System sequence diagrams — show the step-by-step messages between objects for a
specific use case
 • State machine diagrams — show how objects change state (e.g. an order goes from
'Ready' to 'Shipped')

💡 A 'class' in software design is like a template for an object. For example, a 'Customer' class might
have attributes like accountNo, name, address, and methods like updateName() and
updateAddress(). The design class diagram shows all these classes and how they connect to each
other.

Example from the slides: The partial design class diagram shows classes for SaleHandler,
Customer, Sale, SaleItem, and InventoryItem — detailing how 'Process New Sale' and 'Make
Payment' use cases work at a code level.

5. System Controls and Security

Security is not optional — it must be designed in from the beginning. Every system needs to
safeguard:
• Access to the servers (application server and database server)
• Data travelling on the network (e.g. data sent over Wi-Fi or the internet)
• External connections — extra caution needed when communicating with outside
systems

💡 Security design was ignored during analysis (perfect technology assumption), but in design you
MUST include it. Think: firewalls, encryption, authentication, access control, etc.

6. Summary: The Big Picture

Here is how everything fits together in one simple view:

Stage Purpose Output

Analysis Understand WHAT the system must Requirements models (use case
do diagrams, class diagrams, etc.)
Design Specify HOW the system will be built Design models (package diagrams,
component diagrams, DB schema, UI
designs)
Implementation Build the actual system Working software

The five design activities and what they produce:

Design Activity What is Produced

Describe the environment Network/deployment diagrams, communication specs
Design application components Package, component & deployment diagrams
Design user interface Screen layouts, storyboards, prototypes
Design database Database schema, ERD, table definitions
Design software classes & methods Design class diagrams, sequence diagrams, state diagrams

Key Takeaway
Design is the blueprint. Without it, you get cowboy programming — messy, buggy, hard-to-
maintain code.
Analysis tells you WHAT. Design tells you HOW. Implementation builds it.