Suggest why it is important to make a distinction consequence of changes to the business, business goals requirements.

requirements. Fundamentally, to provide availability, you

between developing the user requirements and and business policies. Unless the system is adapted to need to have (a) replicated components in the
developing system requirements in the requirements reflect these requirements, its facilities will become out- architecture so that in the event of one component
engineering process. There is a fundamental difference of-step with the facilities needed to support the business failing, you can switch immediately to a backup
between the user and the system requirements that and, hence, it will become less useful. Examples of component. You also need to have several copies of the
mean they should be considered separately. process activities that support change are: 1. Recording data that is being processed. Security requires minimizing
1. The user requirements are intended to describe of requirements rationale so that the reason why a the number of copies of the data and, wherever possible,
the system’s functions and features from a user requirement is included is known. This helps with future adopting an architecture where each component only
perspective and it is essential that users change. 2. Requirements traceability that shows knows as much as it needs to, to do its job. This reduces
understand these requirements. They should be dependencies between requirements and between the the chance of intruders accessing the data. Therefore,
expressed in natural language and may not be requirements and the design/code of the system. 3. there is a fundamental architectural conflict between
expressed in great detail, to allow some Design modeling where the design model documents the availability (replication, several copies) and security
implementation flexibility. The people involved structure of the software. 4. Code refactoring that (specialization, minimal copies). The system architect has
in the process must be able to understand the improves code quality and so makes it more amenable to to find the best compromise between these
user’s environment and application domain. 2. change fundamentally opposing requirements.
The system requirements are much more ATM activity diagram Giving reasons for your answer based on the type of
detailed than the user requirements and are system being developed, suggest the most appropriate
intended to be a precise specification of the generic software process model that might be used as a
system that may be part of a system contract. basis for managing the development of the following
They may also be used in situations where systems:
development is outsourced and the 1. Anti-lock braking system This is a safety-critical system
development team need a complete so requires a lot of up-front analysis before
specification of what should be developed. The implementation. It certainly needs a plan-driven
system requirements are developed after user approach to development with the requirements
requirements have been established. carefully analysed. A waterfall model is therefore the
Explain why change is inevitable in complex systems and most appropriate approach to use, perhaps with formal
give examples (apart from prototyping and incremental transformations between the different development
delivery) of software process activities that help predict stages.
changes and make the software being developed more 2. Virtual reality system This is a system where the
resilient to change requirements will change and there will be an extensive
Systems must change because as they are installed in an user interface components. Incremental development
environment the environment adapts to them and this with, perhaps, some UI prototyping is the most
adaptation naturally generates new/different system Explain why design conflicts might arise when designing appropriate model. An agile process may be used.
requirements. Furthermore, the system's environment is an architecture for which both availability and security 3. University accounting system This is a system whose
dynamic and constantly generates new requirements as a requirements are the most important non-functional requirements are fairly well-known and which will be

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

used in an environment in conjunction with lots of other 3. Client-Server Architecture: Web-based software organize and manage the software development lifecycle
systems such as a research grant management system. typically follows a client-server architecture, where the from inception to deployment and maintenance.
Therefore, a reuse-based approach is likely to be client (web browser or client application) communicates Software process models define the sequence of steps,
appropriate for this. with the server to request and receive data or services. methodologies, and best practices to ensure that
4. Interactive travel planning system System with a This architecture enables the separation of concerns software projects are completed efficiently, effectively,
complex user interface but which must be stable and between the presentation layer (client) and the and with high quality.
application logic and data storage layer (server).
reliable. An incremental development approach is the 1. Waterfall Model: - Description: The Waterfall Model
Engineers must design and implement robust client-
most appropriate as the system requirements will change follows a sequential, linear approach to software
server communication protocols and APIs to facilitate
as real user experience with the system is gained. efficient and secure data exchange between clients and development, where each phase (requirements, design,
discuss the three key characteristics of the engineering servers. They must also consider factors such as load implementation, testing, deployment, maintenance) is
of web-based software engineering? balancing, caching, and session management to optimize completed in a strict order, and progress flows
performance and scalability of the system. downwards like a waterfall When to Use: The Waterfall
1. Distributed Nature: Web-based software applications Model is suitable for projects with well-defined
typically operate in a distributed computing and stable requirements, where changes are
environment, where components of the system are unlikely or minimal. It is best suited for projects
deployed across multiple servers or nodes connected via
with straightforward objectives and technologies,
a network. This distributed nature introduces challenges
where the entire scope can be planned and
related to communication, synchronization, and
coordination between different parts of the application. documented upfront. Examples include
Engineers must design the system architecture and developing simple software applications, legacy
components to work seamlessly in a distributed system upgrades, or projects with regulatory
environment, ensuring reliability, scalability, and fault compliance requirements.
tolerance. 2. Agile Development: Description: Agile
2. Platform Independence: Web-based software Development is an iterative and incremental
applications are designed to be accessed and used approach to software development, emphasizing
through web browsers or other client applications flexibility, adaptability, and collaboration. It
running on diverse platforms and devices. This platform focuses on delivering working software
independence allows users to interact with the software incrementally through short iterations (sprints),
regardless of their operating system, device type, or frequent customer feedback, and continuous
location. Engineers must develop web-based applications
define what is meant by software process model? improvement.Agile Development is ideal for projects with
using technologies and standards that support cross-
Briefly discuss three examples of software process evolving or unclear requirements, where flexibility and
platform compatibility, such as HTML, CSS, JavaScript,
and web APIs. Additionally, they must consider models indicating when each might be used responsiveness to change are essential. It is well-suited
responsive design principles to ensure that the user A software process model is a standardized approach or for dynamic environments, rapid prototyping, and user-
interface adapts and functions correctly across different framework used to structure, plan, and control the centric applications. Examples include web and mobile
screen sizes and devices. development of software systems. It provides a set of application development, software products with
guidelines, phases, activities, and deliverables that help

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

frequent updates or enhancements, and projects with software development lifecycle. It aligns development diagrams, or state diagrams, could be used to describe
cross-functional teams working collaboratively. activities with corresponding testing and validation the internal workings of specific modules within the
3. Spiral Model: The Spiral Model combines elements of activities, ensuring that each stage of development is insulin delivery system. These diagrams would provide a
both the Waterfall Model and iterative development, rigorously verified against requirements and design visual representation of how data flows and how
incorporating risk management and prototyping. It specifications. different components interact at a granular level.
consists of multiple cycles (spirals) that include phases for Here's how the stages of the V-Model could be applied to
risk analysis, planning, prototyping, development, and develop the software for the insulin delivery system: 4. Implementation: The implementation stage involves
evaluation.When to Use: The Spiral Model is suitable for 1. Requirements Analysis:In this stage, the requirements writing code based on the design specifications.
projects with high levels of risk and uncertainty, where for the insulin delivery system are elicited, analyzed, and Developers translate the system design into executable
requirements are complex or poorly understood. It is documented. This includes gathering functional code using programming languages and development
often used for large-scale projects, research and requirements (such as insulin dosage calculations, frameworks.While there may not be a specific diagram
development efforts, and projects with significant delivery mechanisms, user interface requirements) and associated with the implementation stage, version
technical challenges. Examples include developing non-functional requirements (such as safety, reliability, control systems (such as Git) and code repositories play a
innovative products, systems with stringent safety or and regulatory compliance).A suitable diagram for this crucial role in managing the codebase and tracking
security requirements, and projects with evolving stage could be a requirements specification document changes made during development.
technologies or regulatory constraints. outlining the system's features, functionalities, and
as a software engineer consultant, discuss the type of constraints. Additionally, a use case diagram could 5. Testing and Validation:Once the code is implemented,
system, and explain (with the aid of a suitable diagram), illustrate the interactions between users (such as patients it undergoes testing and validation to ensure that it
the stages of the software process models you would or healthcare providers) and the insulin delivery system. meets the specified requirements and functions correctly
apply to develop the software for the case study below, 2. System Design:Once the requirements are understood, under various conditions. Testing activities include unit
insulin delivey system the system architecture and design are developed based testing, integration testing, system testing, and
As a software engineering consultant tasked with on those requirements. This stage involves defining the acceptance testing. A test plan document, along with test
developing an insulin delivery system, it's essential to overall system structure, subsystems, interfaces, and data cases and test scripts, guides the
consider the criticality of the system, the potential risks flow. A system architecture diagram, such as a high-level 6. Deployment and Maintenance: After successful testing
involved, and the need for rigorous testing and validation. block diagram or a UML component diagram, could be and validation, the insulin delivery system is deployed in
The insulin delivery system is a safety-critical medical used to illustrate the structure of the insulin delivery a clinical or healthcare setting. Ongoing maintenance and
device that requires careful attention to detail, system and its components. This diagram would show support ensure the system's reliability, performance, and
compliance with regulatory standards (such as FDA how different modules and subsystems interact with each security over time.
regulations in the United States), and a focus on other to achieve the system's functionality. Q1a. WHY WATERFALL MODEL IS LIMITED TO ITERATION
reliability, safety, and user-friendliness. Sequential nature: The waterfall model follows a strict
One suitable software process model for developing the 3. Module Design:In this stage, the detailed design of sequence of phases, such as requirements gathering, design,
insulin delivery system is the V-Model, also known as the individual modules or components of the system is implementation, testing, and maintenance. Each phase depends
on the completion of the previous one. This sequential
Verification and Validation Model. The V-Model is a created. This includes defining the data structures,
approach makes it difficult to incorporate feedback and changes
sequential process model that emphasizes the algorithms, and interfaces for each module.Detailed
once a phase is completed.
importance of testing and validation throughout the design documents, such as UML class diagrams, sequence

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

High cost of change: Making changes late in the development Most of these systems are games of one kind or another. The this document. User requirements are abstract statements of
process in the waterfall model can be costly and time- quality of the user interaction offered is the most important the system requirements for the customer and end-user of the
consuming. Since each phase builds upon the outputs of the distinguishing characteristic of entertainment systems system; system requirements are a more detailed description of
previous phase, changes in one phase often require rework in Q1c. DISTINGUISH BETWEEN WATERFALL MODEL AND the functionality to be provided.
subsequent phases. This can lead to delays and increased INCREMENTAL MODEL WITH EXAMPLES OF SOFTWARE Requirements validation This activity checks the requirements
project costs. APPLICATION for realism, consistency, and completeness. During this process,
Q1b. DIFFERENT TYPES OF APPLICATION SOFTWARE The waterfall model is a linear and sequential approach to errors in the requirements document are inevitably discovered.
i). Stand-alone applications These are application systems that software development, where each phase flows downward like It must then be modified to correct these problems.
run on a local computer, such as a PC. They include all necessary a waterfall, and progress is made from one phase to the next in
functionality and do not need to be connected to a network. a predefined order (requirements, design, implementation,
Examples of such applications are office applications on a PC, testing, deployment, maintenance). example Application:
CAD programs, photo manipulation software, etc. Enterprise Resource Planning (ERP) System while the
ii). Interactive transaction-based applications These are incremental model breaks down the software development
applications that execute on a remote computer and that are process into smaller, incremental builds or iterations. Each
accessed by users from their own PCs or terminals. Obviously, iteration adds new functionality to the system, building upon
these include web applications such as e-commerce the previous increments, and allowing for feedback and
applications where you can interact with a remote system to adjustments throughout the development lifecycle. Example
buy goods and services. This class of application also includes Application: Mobile Application Development
business systems, where a business provides access to its
systems through a web browser or special-purpose client Q2b PRINCIPAL STAGES OF REQUIREMENT ENGINEERING
program and cloud-based services, such as mail and photo PROCESS WITH SUITABLE DIAGRAM
sharing. Interactive applications often incorporate a large data Feasibility study: An estimate is made of whether the identified Q3. USE CASE FOR LUTH
store that is accessed and updated in each transaction. user needs may be satisfied using current software and Q3b INCREMENTAL MODEL
iii). Embedded control systems These are software control hardware technologies. The study considers whether the Incremental approach is most approach because each service
systems that control and manage hardware devices. proposed system will be cost-effective from a business point of will be created, tested and evaluated by users before other
Numerically, there are probably more embedded systems than view and if it can be developed within existing budgetary features are also designed. this allows for maximum user
any other type of system. Examples of embedded systems constraints. A feasibility study should be relatively cheap and cooperation and requirement determination. The stages of the
include the software in a mobile (cell) phone, software that quick. The result should inform the decision of whether or not incremental model are as follows:
controls anti-lock braking in a car, and software in a microwave to go ahead with a more detailed analysis. Specification (Initial Version): This phase involves gathering and
oven to control the cooking process. Requirements elicitation and analysis This is the process of defining the requirements for the software. The goal is to create
iv). Batch processing systems These are business systems that deriving the system requirements through observation of a clear and comprehensive specification that outlines what the
are designed to process data in large batches. They process existing systems, discussions with potential users and procurers, software is supposed to achieve.
large numbers of individual inputs to create corresponding task analysis, and so on. This may involve the development of Development (Intermediate Versions): In this phase, the
outputs. Examples of batch systems include periodic billing one or more system models and prototypes. These help you software is developed in increments or smaller iterations.
understand the system to be specified. Instead of creating the entire system at once, developers work
systems, such as phone billing systems, and salary payment
Requirements specification Requirements specification is the on smaller, manageable portions. Each increment typically adds
systems.
activity of translating the information gathered during the new functionality or refines existing features.
v. Entertainment systems These are systems that are primarily
analysis activity into a document that defines a set of Validation (Final Version): After each increment is developed, it
for personal use and which are intended to entertain the user.
requirements. Two types of requirements may be included in undergoes validation to ensure that it meets the specified

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

requirements and functions as intended. This phase involves
testing and quality assurance to identify and fix any issues.
Repeat (Cycle): The development, validation, and specification
phases are repeated for each increment until the complete
system is built. Each cycle adds new features or refines existing
ones based on feedback from previous increments.
Q3c. TYPES OF SOFTWARE FOR LUTH HMS
Information System: This system will take inputs such as
patient data, bed availability data, and other information from
users (LUTH staff) and store them in the system's database. It
should also be able to output this data to users from the
database. This characteristic mentioned here is a clear example
of an information system.
Data collection system: As a data collection system, this system
will integrate with blood analyzers and other laboratory devices
to capture patient data, facilitating remote upload directly into
the patient medical record database.

Q3d. NON-FUNCTIONAL ATTRIBUTE FOR LUTH HMS

security: the system should handle sensitive patient
information, including medical records and personal data.
Ensuring robust security measures, such as encryption, access
controls, and secure authentication, is essential to protect
patient privacy and comply with regulations like HIPAA (Health
Insurance Portability and Accountability Act).
Reliability: The system must be highly reliable to support critical
healthcare operations. Unplanned downtime or system failures
can disrupt essential functions. High reliability ensures
uninterrupted access to patient records and services,
minimizing the risk of adverse impacts on patient care
Performance: The system deal with a large volume of
transactions and data, including patient information, bed
availability, and patient invoices. The system must perform
efficiently to handle these tasks in a timely manner, ensuring
smooth operations and minimizing delays in patient care.
Usability: The system should have a user-friendly interface and
easy-to-use features that will enable the users find their way
around the system at a fast pace and minimize errors in data
entry and retrieval.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 Software Development Cycle
STEP 1: SOFTWARE SPECIFICATION
(PROGRAM DEFINITION)
i. Program Objectives – What exactly does the user want
ii. Output - What kind of results is the program expected to generate or
produce
iii. Input Data - What inputs can generate the expected output
iii. Processing – What instructions can generate the expected output
from the input data
iv. Specification document – all the above must be document for
Reference
STEP 2: SOFTWARE DEVELOPMENT or IMPLEMENTATION
This involves using the software specification to develop the required
software for the client
- Program Design : Deals with the design of the solution using any of
the following:
-Top-Down design (use of modules/subprograms)
-Pseudocode/Algorithms (Using English and Mathematical expressions
in writing the logical set of instructions)
-Flowcharts (A graphical/pictorial representation of the logical set of
instructions)
- Program code – Conversion of the algorithm/flowchart into a
language that the computer can understand (programming languages)
- Development documentation
STEP 3: SOFTWARE VALIDATION
The main aim of this step is to validate the software to see if it does
exactly what the customer wants. To do this basically involved two
things namely: Program testing : Using sample input data to see if the
output generated is what is expected. The sample data must be a data
whose manual output is known.
• Debugging: Usually carried out if the testing produce wrong output. It
involves locating the error and correcting it.
• Validation documentation
STEP 4: SOFTWARE EVOLUTION
- Maintenance : Is done to ensure that the software meets the changing
need of the customers. This is because customer needs do change over
time.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

- Documentation: To provide description of the program and the
procedures used.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 Ambiguities include: 1. Can a customer buy several
tickets for the same destination together or must
they be bought one at a time? 2. Can customers
cancel a request if a mistake has been made? 3.
How should the system respond if an invalid card is
input? 4. What happens if customers try to put their
card in before selecting a destination (as they would
in ATM machines)? 5. Must the user press the start
button again if they wish to buy another ticket to a
different destination? 6. Should the system only sell

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

tickets between the station where the machine is Sommerville 2010 34 Other factors may account for anomalies
so these should be looked for in the problem components.
situated and direct connections or should it include
all possible destinations? Software Engineering 9.5 Briefly describe the three main types of software
2.Write a set of non-functional requirements for the maintenance. Why is it sometimes difficult to distinguish
between them? The three main types of software maintenance
ticket-issuing system, setting out its expected
are: 1. Corrective maintenance or fault repair. The changes
reliability and response time. Possible non- Explain why a software system that is used in a real-world made to the system are to repair reported faults which may be
functional requirements for the ticket issuing system environment must change or become progressively less useful. program bugs or specification errors or omissions. 2. Adaptive
include: 1. Between 0600 and 2300 in any one day, Systems must change or become progressively less useful for a maintenance or environmental adaptation. Changing the
number of reasons: 1. The presence of the system changes the software to adapt it to changes in its environment e.g. changes
the total system down time should not exceed 5
ways of working in its environment and this generates new to other software systems. 3. Perfective maintenance or
minutes. 2. Between 0600 and 2300 in any one day, requirements. If these are not satisfied, the usefulness of the functionality addition. This involves adding new functionality or
the recovery time after a system failure should not system declines. 2. The business in which the system is used features to the system. They are sometimes difficult to
exceed 2 minutes. 3. Between 2300 and 0600 in any changes in response to market forces and this also generates distinguish because the same set of changes may cover all three
one day, the total system down time should not new system requirements. 3. The external legal and political types of maintenance. For example, a reported fault in the
environment for the system changes and generates new system may be repaired by upgrading some other software and
exceed 20 minutes. All these are availability requirements. 4. New technologies become available that offer then adapting the system to use this new version (corrective +
requirements – note that these vary according to significant benefits and the system must change to take adaptive). The new software may have additional functionality
the time of day. Failures when most people are advantage of them. and as part of the adaptive maintenance, new features may be
traveling are less acceptable than failures when 9.4 As a software project manager in a company that specializes
added to take advantage of this.
there are few customers. 4. After the customer in the development of software for the offshore oil industry, you 9.7 Under what circumstances might an organization decide to
presses a button on the machine, the display should have been given the task of discovering the factors that affect scrap a system when the system assessment suggests that it is
be updated within 0.5 seconds. 5. The ticket issuing the maintainability of the systems developed by your company. of high quality and high business value? Examples of where
Suggest how you might set up a program to analyze the software might be scrapped and rewritten are: 1. When the cost
time after credit card validation has been received
maintenance process and determine appropriate of maintenance is high and the organisation has decided to
should not exceed 10 seconds. 6. When validating maintainability metrics for the company. This is a very open invest in new hardware. This will involve significant conversion
credit cards, the display should provide a status question, where there are many possible answers. Basically, the costs anyway so the opportunity might be taken to rewrite the
message for customers indicating that activity is students should identify factors which affect maintainability software. 2. When a business process is changed and new
taking place. This tells the customer that the such as (program and data complexity, use of meaningful software is required to support the process. 3. When support
identifiers, programming language, program documentation for the tools and language used to develop the software is
potentially time consuming activity of validation is etc.). They should then suggest how these can be evaluated in unavailable. This is a particular problem with early 4GLs where,
still in progress and that the system has not simply existing systems whose maintenance cost is known and discuss in many cases, the vendors are no longer in business
failed. 7. The maximum acceptable failure rate for problems of interaction. The approach should be to discover
those program units which have particularly high maintenance 9.8 What are the strategic options for legacy system evolution?
ticket issue requests is 1: 10000
costs and to evaluate the cost factors for these components and When would you normally replace all or part of a system rather
for other components. Then check for correlations. Software than continue maintenance of the software? The strategic
Engineering 9 – Solutions Manual Introduction ©Ian options for legacy system evolution are: 1. Abandon
maintenance of the system and replace it with a new system. 2.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

Continue maintaining the system as it is. 3. Perform some re- Motivation for Project Driven by a commitment to inclusive
engineering (system improvement) that makes the system design and accessibility. Aims to set a new standard for inclusive
easier to maintain and continue maintenance. 4. Encapsulate practices in technology.
the existing functionality of the system in a wrapper and add Project Scope Encompasses the entire development lifecycle of
new functionality by writing new code which calls on the a voice-based email app. Includes requirements gathering,
existing system as a component. 5. Decompose the system into design, development, testing, and deployment. Compatible
separate units and wrap them as components. This is similar to with popular email providers and accessible across devices.
the solution above but gives more flexibility in how the system Project Method Follows an iterative, user-centered
is used. You would normally choose the replacement option in development process. Utilizes modern development tools and
situations where the hardware platform for the system is being frameworks. Integrates speech recognition APIs, email
replaced, where the company wishes to standardize on some functionality, news briefing, and calendar services. Conducts
approach to development that is not consistent with the testing, feedback, and refinement phases.
current system, where some major sub-system is being replaced Conclusion Represents a significant step towards digital
(e.g. a database system) or where the technical quality of the inclusion and empowerment. Addresses unique challenges
existing system is low and there are no current tools for re- faced by blind individuals in accessing and managing email. Sets
engineering. the foundation for a future of inclusive technology empowering
individuals of all abilities.
Introduction Acknowledges the rise of electronic
communication. Highlights the struggle faced by visually
impaired individuals in accessing email. Proposes a voice-based
email application for the blind.
Problem Statement Visual interfaces of traditional email
applications pose challenges for blind users. Screen readers
struggle with complex layouts, leading to a disjointed user
experience.
Project Aim Develop a highly accessible voice-based email app
for blind users. Empower blind individuals to manage emails
independently using voice commands.
Specific Objectives Conduct user research to understand blind
users' needs. Design an intuitive interface optimized for voice
interaction. Implement robust voice recognition technology.
Develop core features for email management via voice
commands. Integrate news briefing and calendar
functionalities.
Justification for Project Promotes digital inclusion and
accessibility for blind individuals. Enhances autonomy, privacy,
and efficiency in communication.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 Lecture 6 Architectural design

Topics covered

 Architectural design decisions

 Architectural views
 Architectural patterns
 Application architectures

Lecture 6 Architectural design 2

Software architecture

 The design process for identifying the sub-

systems making up a system and the framework for
sub-system control and communication is architectural
design.
 The output of this design process is a description
Lecture 6 – Architectural Design of the software architecture.

Part 1

Lecture 6 Architectural design 3

Source : https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Presentations/index.html
Architectural design  Often carried out in parallel with some Lecture 6 Architectural design 4

specification activities.
 An early stage of the system design process.  It involves identifying major system components
and their communications.
 Represents the link between specification and
design processes.

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 Lecture 6 Architectural design 5 Lecture 6 Architectural design 6
The architecture of a packing robot control
system Architectural abstraction

 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.
 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.

Advantages of explicit architecture  Depends on the use of architectural models. The because it is not cluttered with detail. Stakeholders can relate to
requirements for model semantics depends on how the it and understand an abstract view of the system. They can
then discuss the system as a whole without being confused by
models are used. detail.
 Stakeholder communication
▪ Architecture may be used as a focus of discussion by  As a way of documenting an architecture that has
system stakeholders. 8
been designed
Box and line diagrams
 System analysis ▪ The aim here is to produce a complete system model that
▪ Means that analysis of whether the system can meet its shows the different components in a system, their interfaces
nonfunctional requirements is possible. and their connections.
 Very abstract - they do not show the nature of
 Large-scale reuse component relationships nor the externally visible Lecture 6 Architectural design 10
▪ The architecture may be reusable across a range of properties of the sub-systems. Architectural design decisions
systems ▪ Product-line architectures may be developed.
 However, useful for communication with
stakeholders and for project planning.
 Architectural design is a creative process so the
process differs depending on the type of system being
developed.
7

Architectural representations  However, a number of common decisions span

all design processes and these decisions affect the
nonfunctional characteristics of the system.
 Simple, informal block diagrams showing entities
and relationships are the most frequently used method 9

for documenting software architectures. Use of architectural models

 But these have been criticized because they lack
semantics, do not show the types of relationships  As a way of facilitating discussion about the
between entities nor the visible properties of entities in system design
Lecture 6 Architectural design 11
the architecture. ▪ A high-level architectural view of a system is useful for
communication with system stakeholders and project planning

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 Architectural design decisions  What architectural styles are appropriate?  What control strategy should be used?
 What approach will be used to structure the  How will the architectural design be evaluated?
 Is there a generic application architecture that system?
 How should the architecture be documented?
can be used?  How will the system be decomposed into Lecture 6 Architectural design 12
 How will the system be distributed? modules?
Lecture 6 Architectural design 14
Architecture reuse Architecture and system characteristics
Architectural views

 Systems in the same domain often have similar  Performance

architectures that reflect domain concepts.  What views or perspectives are useful when
▪ Localize critical operations and minimize communications.
Use large rather than fine-grain components. designing and documenting a system’s architecture?
 Application product lines are built around a core
architecture with variants that satisfy particular customer  Security  What notations should be used for describing
requirements. ▪ Use a layered architecture with critical assets in the inner architectural models?
layers.
 The architecture of a system may be designed  Each architectural model only shows one view or
around one of more architectural patterns or ‘styles’.  Safety perspective of the system.
▪ Localize safety-critical features in a small number of ▪ It might show how a system is decomposed into modules, how
▪ These capture the essence of an architecture and can be
subsystems. the run-time processes interact or the different ways in which
instantiated in different ways.
system components are distributed across a network. For both
▪ Discussed later in this Part.  Availability
design and documentation, you usually need to present multiple
▪ Include redundant components and mechanisms for fault views of the software architecture.
tolerance.
Lecture 6 Architectural design 13
 Maintainability ▪ Use fine-grain, replaceable Lecture 6 Architectural design 15

components.
+ 1 view model of software architecture  Related using use cases or scenarios (+1)  Patterns should include information about when
they are and when the are not useful.
16

 A logical view, which shows the key abstractions Architectural patterns  Patterns may be represented using tabular and
in the system as objects or object classes. graphical descriptions.
 A process view, which shows how, at run-time,  Patterns are a means of representing, sharing
the system is composed of interacting processes. and reusing knowledge. 17

 A development view, which shows how the  An architectural pattern is a stylized description The Model-View-Controller (MVC) pattern
software is decomposed for development. of good design practice, which has been tried and
 A physical view, which shows the system tested in different environments. 18

Name MVC (Model-View-Controller)

hardware and how software components are distributed
across the processors in the system. Description Separates presentation and interaction from the system data. The system
is structured into three logical components that interact with each other.
Web application architecture using the MVC The Model component manages the system data and associated
The organization of the Model-View-Controller Layered architecture
operations on that data. The View component defines and manages how
the data is presented to the user. The Controller component manages
pattern user interaction (e.g., key presses, mouse clicks, etc.) and passes these
interactions to the View and the Model. See Figure 6.3.
Example Figure 6.4 shows the architecture of a web-based application system
organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also
used when the future requirements for interaction and presentation of
data are unknown.
Advantages Allows the data to change independently of its representation and vice
versa. Supports presentation of the same data in different ways with
changes made in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model
Lecture 6 Architectural design Lecture 6 Architectural design
and interactionsLecture
are simple.
6 Architectural design
  Used to model the interfacing-systems.
of sub
 Organises the system into a set of layers (or abstract
machines) each of which provide a set of services.
 Supports the incremental development -systems
of subin
different layers. When a layer interface changes, only the
adjacent layer is affected.
 However, often artificial to structure systems in this way.

Lecture 6 Architectural design 19 Lecture 6 Architectural design 20 Lecture 6 Architectural design 21

The Layered architecture A generic layered The architecture of the LIBSYS

Name Layeredarchitecture
Description Organizesthe system into layers with related functionalityassociated
with each layer. A layer providesservicesto the layer above it so the
lowest-level layers representcore services that are likely to be used
throughoutthe system. See Figure6.6.
Example A layered model of a system for sharing copyrightdocumentsheld in
differentlibraries,as shownin Figure6.7.
Whenused Used when buildingnew facilitieson top of existingsystems; when the
development is spread across several teams with each team
responsibilityfor a layer of functionality
; whenthere is a requirementfor
multi-levelsecurity.
Advantages Allows replacement of entire layers so long as the interface is
maintained . Redundantfacilities(e.g., authentication)can be providedin
eachlayerto increasethe dependabilityof the system.
Disadvantages In practice, providing a clean separation between layers is often difficult
and a high-level layer may have to interact directly with lower
-level
layers rather than through the layer immediately below it. Performance
can be a problem because of multiple levels of interpretation of a
service request as it is processed at each .layer
Lecture 6 Architectural design 22 Lecture 6 Architectural design 23 Lecture 6 Architectural design 24

Key points  Architectures may be documented from several different perspectives or viewssuch as a conceptual view, a logical
view, a process view, and a development view.
 A software architecture is a description of how a  Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the
software system is organized. architecture, explain when it may be used and describe its advantages and disadvantages.
25

 Architectural design decisions include decisions Repository architecture

on the type of application, the distribution of the system,
the architectural styles to be used.
 Sub-systems must exchange data. This may be done in two ways:
▪ Shared data is held in a central database or repository and may
Lecture 6 – Architectural Design be accessed by all sub-systems;

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 ▪ Each sub-  When large amounts of data are to be shared, the
system maintains its own
database and passes data Part 2 repository model of sharing is most commonly used a
explicitly to other sub- this is an efficient data sharing mechanism.
systems.

26 27

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design
 Lecture 6 Architectural design 37 Lecture 6 Architectural design 38
Use of application architectures
Examples of application types Application type examples

 As a starting point for architectural design.

 Data processing applications  Focus here is on transaction processing and
 As a design checklist. ▪ Data driven applications that process data in batches language processing systems.
 As a way of organising the work of the without explicit user intervention during the processing.  Transaction processing systems
development team.  Transaction processing applications ▪ E-commerce systems; ▪
Reservation systems.
 As a means of assessing components for reuse. ▪ Data-centred applications that process user requests and
update information in a system database.  Language processing systems
 As a vocabulary for talking about application ▪ Compilers; ▪ Command
 Event processing systems
types. interpreters.
▪ Applications where system actions depend on interpreting
events from the system’s environment.

 Language processing systems

▪ Applications where the users’ intentions are specified in a
formal language that is processed and interpreted by the Lecture 6 Architectural design 39
system.
Transaction processing systems ▪ For example - find the times of flights from London to Lecture 6 Architectural design 40

Paris. The structure of transaction processing

applications
 Users make asynchronous requests for service
 Process user requests for information from a
which are then processed by a transaction manager.
database or requests to update the database. Lecture 6 Architectural design 41

 From a user perspective a transaction is: The software architecture of an ATM system
▪ Any coherent sequence of operations that satisfies a goal;

Lecture 6 Architectural design 42

43
Information systems architecture Layered information system architecture

 Information systems have a generic architecture

that can be organized as a layered architecture.
 These are transaction-based systems as
interaction with these systems generally involves
database transactions.
 Layers include:
▪ The user interface
▪ User communications
▪ Information retrieval
▪ System database

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

 45
▪ The application server is responsible for implementing
Web-based information systems application-specific logic as well as information storage and
retrieval requests;
▪ The database server moves information to and from the
 Information and resource management systems database and handles transaction management.
are now usually web-based systems where the user
interfaces are implemented using a web browser.
 For example, e-commerce systems are Internet-
based resource management systems that accept
Lecture 6 Architectural design 47
electronic orders for goods or services and then
Language processing systems
arrange delivery of these goods or services to the
customer.
 In an e-commerce system, the application-  Accept a natural or artificial language as input and
44
generate some other representation of that language.
The architecture of the MHC-PMS specific layer includes additional functionality
supporting a ‘shopping cart’ in which users can place a  May include an interpreter to act on the instructions
number of items in separate transactions, then pay for in the language that is being processed.
them all together in a single transaction.  Used in situations where the easiest way to solve a
Lecture 6 Architectural design 46
problem is to describe an algorithm or describe the system
Server implementation
data
▪ Meta-case tools process tool descriptions, method rules, etc
 These systems are often implemented as multi-tier and generate tools.
client server/architectures (discussed in Lecture 18)
▪ The web server is responsible for all user communications,
with the user interface implemented using a web browser;
Lecture 6 Architectural design 48

Lecture 6 Architectural design 50

The architecture of a language processing system Compiler components
Compiler components

 A lexical analyzer, which takes input language

tokens and converts them to an internal form.  A semantic analyzer that uses information from
the syntax tree and the symbol table to check the
 A symbol table, which holds information about semantic correctness of the input language text.
the names of entities (variables, class names, object
names, etc.) used in the text that is being translated.  A code generator that ‘walks’ the syntax tree and
generates abstract machine code.
 A syntax analyzer, which checks the syntax of
the language being translated.
 A syntax tree, which is an internal structure
representing the program being compiled.
Lecture 6 Architectural design 49

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

Lecture 6 Architectural design 51

Lecture 6 Architectural design Lecture 6 Architectural design Lecture 6 Architectural design

A pipe and filter compiler architecture

52

A repository architecture for a language processing system

53

Key points

 Models of application systems architectures help us understand and compare applications, validate
application system designs and assess large-scale components for reuse.
 Transaction processing systems are interactive systems that allow information in a database to be remotely
accessed and modified by a number of users.
 Language processing systems are used to translate texts from one language into another and to carry out
the instructions specified in the input language. They include a translator and an abstract machine that executes
the generated language.
54

20