Analysis, Design Concepts and Principles Module-3

SYSTEMS ENGINEERING
The term ‘system’ is one that is universally used. We talk about computer systems, operating systems,
payment systems, the education system, the system of government, and so on. These are all obviously
quite different uses of the word ‘system’, although they share the characteristic that, somehow, the
system is more than simply the sum of its parts. Abstract systems, such as the system of government,
are outside the scope. Rather, focus on systems that include computers and that have some specific
purpose such as to enable communication, support navigation, or compute salaries. A useful working
definition of these types of systems is as follows:

A system is a purposeful collection of interrelated components, of different kinds, which work together
to achieve some objective

Systems engineering encompasses all of the activities involved in procuring, specifying, designing,
implementing, validating, deploying, operating, and maintaining sociotechnical systems. Systems
engineers are not just concerned with software but also with hardware and the system’s interactions
with users and its environment. They must think about the services that the system provides, the
constraints under which the system must be built and operated, and the ways in which the system is
used to fulfil its purpose or purposes.

There are three overlapping stages

1. Procurement or acquisition During this stage, the purpose of a system is decided; high-level
system requirements are established; decisions are made on how functionality will be
distributed across hardware, software, and people; and the components that will make up the
system are purchased.

2. Development During this stage, the system is developed. Development processes include all of
the activities involved in system development such as requirements definition, system design,
hardware and software engineering, system integration, and testing. Operational processes are
defined and the training courses for system users are designed.

3. Operation At this stage, the system is deployed, users are trained, and the system is brought
into use. The planned operational processes usually then have to change to reflect the real working
environment where the system is used. Over time, the system evolves as new requirements are
identified. Eventually, the system declines in value and it is decommissioned and replaced.
Professional disciplines involved in systems engineering

1. Different disciplines use the same words to mean different things. Misunderstandings are
common in discussions between engineers from different backgrounds. If these are not
discovered and resolved during system development, they can lead to errors in delivered
systems. For example, an electronic engineer who may know a little bit about C# programming
may not understand that a method in Java is comparable to a function in C.
2. Each discipline makes assumptions about what can or can’t be done by other disciplines. These
are often based on an inadequate understanding of what is actually possible. For example, a
user interface designer may propose a graphical UI for an embedded system that requires a
great deal of processing and so overloads the processor in the system.
3. Disciplines try to protect their professional boundaries and may argue for certain design
decisions because these decisions will call for their professional expertise. Therefore, a
software engineer may argue for a software-based door locking system in a building, although
a mechanical, key-based system may be more reliable.
System procurement

The initial phase of systems engineering is system procurement (sometimes called

system acquisition). At this stage, decisions are made on the scope of a system that
is to be purchased, system budgets and timescales, and the high-level system
requirements. Using this information, further decisions are then made on whether to
procure a system, the type of system required, and the supplier or suppliers of the
system.
The drivers for these decisions are:
1. The state of other organizational systems If the organization has a mixture of
systems that cannot easily communicate or that are expensive to maintain, then
procuring a replacement system may lead to significant business benefits.

2. The need to comply with external regulations Increasingly, businesses are

regulated and have to demonstrate compliance with externally defined regulations
(e.g., Sarbanes-Oxley accounting regulations in the United States). This may
require the replacement of noncompliant systems or the provision of new systems
specifically to monitor compliance.
3. External competition If a business needs to compete more effectively or maintain a
competitive position, investment in new systems that improve the efficiency of
business processes may be advisable. For military systems, the need to improve
capability in the face of new threats is an important reason for procuring new systems.
4. Business reorganization Businesses and other organizations frequently restructure
with the intention of improving efficiency and/or customer service. Reorganizations
lead to changes in business processes that require new systems support.
5. Available budget the budget available is an obvious factor in determining the scope
of new systems that can be procured.
 SYSTEM DEVELOPMENT

The goals of the system development process are to develop or acquire all of the
components of a system and then to integrate these components to create the final
system. The requirements are the bridge between the procurement and the
development processes. During procurement, business and high-level functional and
nonfunctional system requirements are defined:
1. Requirements development the high-level and business requirements identified
during the procurement process have to be developed in more detail. Requirements
may have to be allocated to hardware, software, or processes and prioritized for
implementation.
2. System design This process overlaps significantly with the requirements development
process. It involves establishing the overall architecture of the system, identifying the
different system components and understanding the relationships between them.
3. Subsystem engineering This stage involves developing the software components of the
system; configuring off-the-shelf hardware and software, designing, if necessary,
special-purpose hardware; defining the operational processes for the system; and
redesigning essential business processes.
4. System integration During this stage, the components are put together to create a new
system. Only then do the emergent system properties become apparent.
5. System testing This is usually an extensive, prolonged activity where problems are
discovered. The subsystem engineering and system integration phases are re-entered
to repair these problems, tune the performance of the system, and implement new
requirements. System testing may involve both testing by the system developer and
acceptance/user testing by the organization that has procured the system.
6. System deployment This is the process of making the system available to its users,
transferring data from existing systems, and establishing communications with other
systems in the environment. The process culminates with a ‘go live’ after which users
start to use the system to support their work.
Although the overall process is plan driven, the processes of requirements
development and system design are inextricably linked. The requirements and the
high-level design are developed concurrently. Constraints posed by existing systems
may limit design choices and these choices may be specified in the requirements. You
may have to do some initial design to structure and organize the requirements
engineering process. As the design process continues, you may discover problems with
existing requirements and new requirements may emerge.

The spiral reflects the reality that requirements affect design decisions and vice versa,
and so it makes sense to interleave these processes. Starting in the center, each round
of the spiral may add detail to the requirements and the design. Some rounds may
focus on requirements, and some on design. Sometimes new knowledge collected
during the requirements and design process means that the problem statement
itself has to be changed.

System operation

Operational processes are the processes that are involved in using the system for its
defined purpose. For example, operators of an air traffic control system follow specific
processes when aircraft enter and leave airspace, when they have to change height or
speed, when an emergency occurs, and so on. For new systems, these operational
processes have to be defined and documented during the system development
process. Operators may have to be trained and other work processes adapted to make
effective use of the new system. Undetected problems may arise at this stage because
the system specification may contain errors or omissions. Although the system may
perform to specification, its functions may not meet the real operational needs.
Consequently, the operators may not use the system as its designers intended. The key
benefit of having system operators is that people have a unique capability of being
able to respond effectively to unexpected situations, even when they have never had
direct experience of these situations. Therefore, when things go wrong, the operators
can often recover the situation although this may sometimes mean that the defined
process is violated. Operators also use their local knowledge to adapt and improve
processes. Normally, the actual operational processes are different from those
anticipated by the system designers.

System evolution

Large, complex systems have a very long lifetime. During their life, they are changed
to correct errors in the original system requirements and to implement new
requirements that have emerged. The system’s computers are likely to be replaced
with new, faster machines. The organization that uses the system may reorganize itself
and hence use the system in a different way. The external environment of the system
may change, forcing changes to the system. Hence evolution, where the system
changes to accommodate environmental change, is a process that runs alongside
normal system operational processes. System evolution involves re-entering the
development process to make changes and extensions to the system’s hardware,
software, and operational processes.
System evolution, like software evolution , is inherently
costly for several reasons:

1. Proposed changes have to be analysed very carefully from a business and a technical
perspective. Changes have to contribute to the goals of the system and should not
simply be technically motivated.
2. Because subsystems are never completely independent, changes to one subsystem
may adversely affect the performance or behaviour of other subsystems. Consequent
changes to these subsystems may therefore be needed.
3. The reasons for original design decisions are often unrecorded. Those responsible
for the system evolution have to work out why particular design decisions were made.
4. As systems age, their structure typically becomes corrupted by change so the
costs of making further changes increases.
Modular Design

Modular design is a fundamental concept in software engineering that involves

breaking down a complex system into smaller, independent modules or components.
These modules are designed to perform specific tasks or functions and can be
developed, tested, and maintained separately. Here are some important notes on
modular design in software engineering:

Definition of Modules:

Modules are self-contained units of software that encapsulate a specific functionality

or set of related functionalities.
They are designed to have well-defined interfaces, making it easier to connect and
interact with other modules.

Benefits of Modular Design:

Reusability: Modules can be reused in different parts of the software or even in other
projects, reducing development time and effort.
Scalability: It allows for easy expansion or modification of the software by adding or
replacing modules as needed.
Maintenance: Modules can be maintained and updated independently, minimizing
the risk of introducing errors in other parts of the software.
Collaboration: Teams can work on different modules concurrently, promoting parallel
development and collaboration.
Testing: Smaller modules are easier to test thoroughly, leading to higher software
quality.
Understanding: Modular design enhances code readability and comprehension by
breaking down complex logic into manageable pieces.

Characteristics of Good Modules:

High Cohesion: Modules should have a clear, single responsibility, and all the elements
within the module should be closely related to that responsibility.
Low Coupling: Modules should have minimal dependencies on other modules,
reducing the impact of changes in one module on others.
Abstraction: Modules should hide internal details and provide a clear, well-defined
interface for interaction.
Independence: Each module should be designed to operate independently without
relying on the internal workings of other modules.

Design Principles:
Single Responsibility Principle (SRP): Each module should have one and only one
reason to change, i.e., it should have a single responsibility.
Open-Closed Principle (OCP): Modules should be open for extension but closed for
modification, allowing new features to be added without changing existing code.
Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base
types, ensuring that modules can be interchanged without affecting the correctness of
the program.
Interface Segregation Principle (ISP): Clients should not be forced to depend on
interfaces they do not use, promoting smaller, more focused interfaces.

Module Communication:

Modules communicate through well-defined interfaces and APIs. Common

communication mechanisms include function/method calls, events, and message
passing.

Examples of Modular Design Techniques:

• Object-Oriented Programming (OOP) encourages the use of classes and objects

as modules.
• Functional programming promotes the use of functions as modules.
• Design patterns, such as the Factory, Singleton, and Observer patterns,
facilitate modular design.

Tools and Practices:

• Version control systems (e.g., Git) help manage and coordinate changes across
modules.
• Automated testing frameworks assist in verifying the correctness of individual
modules.
• Documentation is crucial for describing module interfaces and usage.
•
In summary, modular design in software engineering is about breaking down complex
systems into manageable, independent modules with clear responsibilities and
interfaces. It promotes reusability, maintainability, and collaboration while adhering to
key design principles.

Architectural design

Architectural design is concerned with understanding how a system should be

organized and designing the overall structure of that system architectural design is the
first stage in the software design process. It is the critical link between design and
requirements engineering, as it identifies the main structural components in a system
and the relationships between them. The output of the architectural design process is
an architectural model that describes how the system is organized as a set of
communicating components. In agile processes, it is generally accepted that an early
stage of the development process should be concerned with establishing an overall
system architecture. Incremental development of architectures is not usually
successful. While refactoring components in response to changes is usually relatively
easy, refactoring a system architecture is likely to be expensive.

We can design software architectures at two levels of abstraction,

1. Architecture in the small is concerned with the architecture of individual

programs.
At this level, we are concerned with the way that an individual program is decomposed
into components.

2. Architecture in the large is concerned with the architecture of complex enterprise

systems that include other systems, programs, and program components. These
enterprise systems are distributed over different computers, which may be owned and
managed by different companies

The architecture of a packing robot control system

 Software architecture is important because it affects the performance, robustness,
disreputability, and maintainability of a system. As Bosch discusses, individual
components implement the functional system requirements. The nonfunctional
requirements depend on the system architecture—the way in which these
components are organized and communicate. In many systems, non-functional
requirements are also influenced by individual components, but there is no doubt that
the architecture of the system is the dominant influence.

Three advantages of explicitly designing and documenting software architecture:

1. Stakeholder communication the architecture is a high-level presentation of the

system that may be used as a focus for discussion by a range of different stakeholders.
2. System analysis Making the system architecture explicit at an early stage in the
system development requires some analysis. Architectural design decisions have a
profound effect on whether or not the system can meet critical requirements such as
performance, reliability, and maintainability.
3. Large-scale reuse A model of a system architecture is a compact, manageable
description of how a system is organized and how the components interoperate.
The system architecture is often the same for systems with similar requirements
and so can support large-scale software reuse.

Architectural design decisions

Architectural design is a creative process where you design a system organization that will
satisfy the functional and non-functional requirements of a system. Because it is a creative
process, the activities within the process depend on the type of system being developed, the
background and experience of the system architect, and the specific requirements for the
system. It is therefore useful to think of architectural design as a series of decisions to be made
rather than a sequence of activities.
During the architectural design process, system architects have to make a number of structural
decisions that profoundly affect the system and its development process. Based on their
knowledge and experience, they have to consider the following fundamental questions about
the system:
1. Is there a generic application architecture that can act as a template for the system
that is being designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements
of the system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?

Architectural views
It is impossible to represent all relevant information about a system’s architecture in a single
architectural model, as each model only shows one view or perspective of the system. It might
show how a system is decomposed into modules, how the run-time processes interact, or the
different ways in which system components are distributed across a network. All of these are
useful at different times so, for both design and documentation, you usually need to present
multiple views of the software architecture.
There are different opinions as to what views are required. Krutchen (1995), in his well-known
4+1 view model of software architecture, suggests that there should be four fundamental
architectural views, which are related using use cases or scenarios.
The views that he suggests are:
1. A logical view, which shows the key abstractions in the system as objects or object
classes. It should be possible to relate the system requirements to entities in this
logical view.
2. A process view, which shows how, at run-time, the system is composed of interacting
processes. This view is useful for making judgments about nonfunctional system
characteristics such as performance and availability.
3. A development view, which shows how the software is decomposed for development,
that is, it shows the breakdown of the software into components that are implemented by
a single developer or development team. This view is useful for software managers and
programmers.
4. A physical view, which shows the system hardware and how software components are
distributed across the processors in the system. This view is useful for systems engineers
planning a system deployment.
Architectural patterns

The idea of patterns as a way of presenting, sharing, and reusing knowledge about
software systems are now widely used. The trigger for this was the publication of
a book on object-oriented design patterns, which prompted the development of
other types of patterns, such as patterns for organizational design, usability
patterns, interaction, configuration management

The organization of the MVC

 Web application architecture using the MVC pattern

LAYERED ARCHITECTURE
A generic layered architecture
Repository architecture

A repository architecture for an IDE

Client–server architecture

A client— server architecture for a film library

Pipe and filter architecture

An example of the pipe and filter architecture

Application architectures

Application systems are intended to meet a business or organizational need. All

businesses have much in common—they need to hire people, issue invoices, keep
accounts, and so on. Businesses operating in the same sector use common sector
specific applications. Therefore, as well as general business functions, all phone
companies need systems to connect calls, manage their network, issue bills to
customers, etc. Consequently, the application systems used by these businesses
also have much in common.
As a software designer, you can use models of application architectures in a
number
of ways:
 1. As a starting point for the architectural design process If you are unfamiliar with
the type of application that you are developing, you can base your initial design
on a generic application architecture. Of course, this will have to be specialized
for the specific system being developed, but it is a good starting point for design.

2. As a design checklist If you have developed an architectural design for an

application system, you can compare this with the generic application architecture.
You can check that your design is consistent with the generic architecture.

3. As a way of organizing the work of the development team the application

architectures identify stable structural features of the system architectures and in
many cases, it is possible to develop these in parallel. You can assign work to group
members to implement different components within the architecture.

4. As a means of assessing components for reuse If you have components, you

might be able to reuse, you can compare these with the generic structures to see
whether there are comparable components in the application architecture.

4. As a vocabulary for talking about types of applications If you are discussing a

specific application or trying to compare applications of the same types, then you
can use the concepts identified in the generic architecture to talk about the
applications

The Database structure of transaction processing applications

User Interface Design

User Interface (UI) design in software engineering plays a critical role in ensuring
that software applications are user-friendly, intuitive, and efficient to use. Here are
some important notes on User Interface Design:

Definition of User Interface (UI):

UI is the point of interaction between the user and the software system.It
encompasses all elements that users see, touch, and interact with, including
screens, buttons, menus, and forms.
Importance of UI Design:

• A well-designed UI enhances user satisfaction, leading to a positive user

experience (UX).
• It reduces the learning curve, allowing users to quickly understand and use
the software.
• Good UI design can boost productivity and efficiency by streamlining user
tasks.
• Aesthetically pleasing UI can create a favourable impression and build user
trust.
User-Cantered Design:

UI design should be based on an understanding of user needs, preferences, and

behaviour. Techniques such as user research, personas, and user testing help in
designing interfaces that align with user expectations.

Principles of UI Design:

Visibility: Important elements and options should be easily visible and accessible.
Consistency: UI elements should behave predictably and have a uniform design.
Feedback: Users should receive feedback for their actions, such as button clicks or
form submissions.
Simplicity: Keep the UI simple and uncluttered to avoid overwhelming users.
Efficiency: Design the UI to allow users to complete tasks quickly and with minimal
steps.
Error Prevention and Handling: Anticipate and prevent errors where possible, and
provide clear error messages when they occur.

User Interface Elements:

Widgets: UI components like buttons, text fields, checkboxes, and sliders.

Layout: Arrangement of widgets, text, and images on the screen.
Navigation: The structure that allows users to move between screens or sections.
Typography: Choice of fonts, sizes, and styles for text.
Color: Selection of a color scheme to convey information and enhance aesthetics.
Images and Icons: Use of visuals to represent information or actions.

Responsive Design:

Designing interfaces to adapt to various screen sizes and devices, including

desktops, tablets, and smartphones. Ensures a consistent user experience across
different platforms.
Accessibility:

Designing UIs that are accessible to individuals with disabilities, including those
who use screen readers or have mobility impairments. Compliance with
accessibility standards such as WCAG (Web Content Accessibility Guidelines) is
essential.
Prototyping and Wireframing:

Prototyping tools and wireframes are used to create low-fidelity representations

of the UI to test and refine design concepts. They help in visualizing layout,
navigation, and user flows.

User Testing:

Conducting usability testing with real users to gather feedback and make iterative
improvements to the UI. User feedback is invaluable for identifying usability issues
and optimizing the UI.

UI Design Tools:

Popular UI design tools include Adobe XD, Sketch, Figma, and Invision, which
facilitate the creation of high-fidelity mock-ups and prototypes.
Internationalization (I18N) and Localization (L10N):

Consideration of global audiences by designing UIs that support multiple

languages and cultural preferences.

Continuous Improvement:

UI design is an iterative process, and improvements should be made based on user

feedback and changing requirements.

In conclusion, User Interface Design in software engineering is a multifaceted

discipline that involves understanding user needs, applying design principles,
creating visually appealing and user-friendly interfaces, and continuously refining
the design through feedback and testing. A well-designed UI enhances the overall
user experience and contributes to the success of software applications.