MIT821: Software Systems

Lecturers:
Prof. Charles O. Uwadia
Dr. Ufuoma C. Ogude

Department of Computer Sciences

University of Lagos

•Lectures:
– E303, Saturdays 3:00 pm to 5:00 pm
Objectives
Understand general systems theory and its application in business environment.

Understand what software systems architecture is about and why your role is
vitally important to successful project delivery.

Understand how to determine who is interested in your architecture (your

stakeholders), understand what is important to them (their concerns), and design
an architecture that reflects and balances their different needs.

Understand how to communicate your architecture to your stakeholders in an

understandable way that demonstrates that you have met their concerns (the
architectural description)
Objectives cont.
Understand how to focus on what is architecturally significant, safely leaving
other aspects of the design to your designers, without neglecting issues like
performance, resilience, and location.

Understand what important activities you most need to undertake as an

architect, such as identifying and engaging stakeholders, using scenarios, creating
models, and documenting and validating your architecture .
Course Outline
Architecture Fundamentals
Software Architecture Concepts

Viewpoints and Views

Architectural Perspectives

The Role of the Software Architect

The Process of Software Architecture
Introduction to the Software Architecture Process

The Architecture Definition Process

Concerns, Principles, and Decisions

Identifying and Engaging Stakeholders

Identifying and using Scenarios

Using Styles and Patterns

Producing Architectural Models

Creating the Architectural Description

Evaluating the Architecture

 A Viewpoint Catalog  The Perspective Catalog
 Introduction to the Viewpoint Catalog  Introduction to the Perspective

 Catalog
The Context Viewpoint
 The Security Perspective
 The Functional Viewpoint
 The Performance and Scalability
 The Information Viewpoint
Perspective
 The Concurrency Viewpoint
 The Availability and Resilience
 The Development Viewpoint Perspective
 The Deployment Viewpoint  The Evolution Perspective
 The Operational Viewpoint  Putting it all Together
 Achieving Consistency Across Views  Working as a Software Architect
 Other Viewpoint Sets
 Grading System
Final Examination: 70%
 Six Questions:
• Attempt Question One (1) = 34marks
• Any other three (3) Questions = 3x12 = 36marks

Continuous Assessment: 30%

 group work/project
 written test/seminar
 Assignments

Note:
A student can choose between:
 Written test (application of theoretic concepts)
 Seminar presentation
Presentation Outline: Architecture Fundamentals
Learning Objective
To understand the basic concepts of software architectures (e.g.

stakeholder, architectural description, viewpoint, and perspective) and

describes the role of the software architect

Architecture in Civil Engineering
Design at the highest level

Examples: Bridge architectures

Why do civil
engineers talk about
bridge architectures?

Arch Beam Suspension Cable-stayed

 Definition in Civil Engineering
– The art and science of designing and erecting buildings

– Fundamental underlying design of buildings

– Style and method of design and construction of buildings

 Buildings and other structures

Introduction
Computers can be found everywhere in modern society—not just in data

centers or on desks but also in cars, washing machines, cell phones, and

credit cards.

Whether they are big or small, simple or complex, all computer systems

are made up of the same three fundamental parts:

software (e.g., programs or libraries)

data, which may be either transient (in memory) or persistent (on disk or ROM)

hardware (e.g., processors, memory, disks, network cards)

Definitions
There are many definitions of software architecture, easily
discoverable with a web search, but we focus on the following three
definitions:
•The software architecture of a system is the set of structures needed to reason
about the system, which comprise software elements, relations among them, and
properties of both.

•It is the structure of the system which consists of software components, the
externally visible properties of those components and the relationship between
them.

•Architecture is the fundamental organization of a system embodied in its

components, their relationships to each other, and to the environment, and the
principles guiding its design and evolution. [IEEE 1471]
Software Architecture
The structure or structures of a software system
– software components
– externally visible properties of those components
– the relationships between them

The set of principle design decisions made about a

software system
– System structure
– Functional behavior
– Interaction
– Nonfunctional properties
– Implementation
– System goals, stakeholders, non-technical considerations, etc.
Features
Architecture is a set of software structures
 (program) decomposition structures, component-and-connector structures
(C&C), allocation structures

Architecture is an abstraction
 Model of a software system

Every software system has a software architecture i.e. every system

has its own architecture but they are not identical
 documented or undocumented

Architecture includes behavior

 (external) behaviors/properties of architectural elements are part of
architecture

Not all architectures are good architectures

• determined by architecture’s quality attributes
Goal – Why?
Software architecture is important to the successful development of a
software system
Software systems are constructed to satisfy organizations' business goals.

Architecture is a bridge between business goals (often abstract) and the

final (concrete) resulting system.
The path from abstract goals to concrete systems can be complex
Software is increasingly complex.

Software is evolving, reused in new contexts.

The promise of off-the-shelf components with easy reuse

We need to adapt, wrap or modify the off-the-shelf components.

Too many components in software products.

Large number of connections/dependencies between these components

Goal – Why?
Good software architectures can be designed, analyzed, documented, and

implemented using known techniques that will support the achievement of

these business and mission goals.

The complexity can be tamed, made tractable.

How to make sure that SW development reaches the

intended goals of a project.
Elements of Software Architecture
Components

Connectors

Configuration topologies

System models
Components
Elements that encapsulate processing and data in a system’s
architecture
An architectural entity that
– encapsulates a subset of the system’s functionality and/or data,

– restricts access to that subset via an explicitly defined interface,

and
– had explicitly defined dependencies on its required execution
context.

Often represented as boxes in diagrams.

Connectors
Elements that are tasked with effecting and regulating
interactions among components.
Application independent.

Often represented as lines in diagrams.

connector component
Configuration Topology
A set of specific associations between the components and
connectors of a software system’s architecture.
System Models
An artifact that captures some or all of the design decisions that
comprise a system’s architecture.
Architectural modeling is the reification and documentation of
those design decisions.
Different models:
– structural vs. behavioral
– static vs. dynamic
– Scope

Q: Key constraints of layered model?

 “A software architect is responsible for designing, documenting, and
leading the construction of a system that meets the needs of all its
stakeholders”.
 Identify four aspects to carry out this role of a software architect.
Prepare a pro forma list of responsibilities for a software system
architect.

 You have consequently been charged with planning, developing, applying,

and delivering advanced information systems, architectural solutions,
and programming products.
“A software architect is responsible for designing, documenting,
and leading the construction of a system that meets the needs
of all its stakeholders”.

Roles of Software Architect

Design Expertise
Domain Expertise
Technology Expertise
Methodological Expertise (SDLC)
Assignment1
You are an architect who have just joined a large team maintaining a

legacy software. While trying to understand the architecture of the

software, you find that the architecture is well documented.

However, when you discuss with the developers working in the project, you

find that the actual architecture is different from the documented

architecture – over the last decade, the software has changed but the

documentation has not been updated.

Explain the architecture of the software scenario.

Assignment2
You are working on a financial application that is an event-driven system.
The team is having difficulty in testing and debugging the software and
want to be able to replay the events. Also, the application has recently
been a target of security attacks. With lack of audit trail, it is difficult to
prosecute attackers.

What is more, the management also wants predictive analytics for

improving profitability of the business.

Discuss the best pattern that can help directly address this situation

 
 QU. You are an architect for a signal processing application. You have

designed the application in such a way that the front-end component

receives sensor data from devices, and the data flows from one

component to the following component. Each component subsequently

transforms the data it receives and passes the transformed data to the

next component. The final component passes the data to a modeling and

visualization unit that renders the data to the end-users.

Discuss the best architecture style you will use in this application.
Stakeholders in a System’s Architecture
Architects

Developers

Testers

Managers

Customers

Users

Vendors
 Outline

 What’s software architecture?

 Elements of software architecture
• Architectural styles
 Architectural Styles
• A named collection of architectural design decisions
that:
– are applicable in a given development context,
– constrain architectural design decisions that are specific to
a particular system with that context, and
– elicit beneficial qualities in each resulting system.
• Not about: specific systems, components, interaction
mechanisms, or configurations.
 An Architectural Style Example
• Physically separate the software components used to request services from the
components that provide the services, to allow for proper distribution and scaling
up, both in the number of service providers and service requesters.
• Make the service providers unaware of the requesters’ identity to allow the
providers to service transparently many, possibly changing requestors.
• Insulate the requesters from one another to allow for their independent addition,
removal, and modification. Make the requesters dependent only on the service
providers.
• Allow for multiple service providers to emerge dynamically to off-load the existing
providers should the demand for services increase above a given threshold.
Example: Client-Server
 More on Architectural Styles

Advantages
• Each style emphasizes one or more of the quality attributes, such as
usability, availability, security, performance, maintainability, flexibility,
portability, etc.
Remarks:
• Each style has its own advantages and drawbacks.
• An application may require several architectural views.
• Choosing the right views is a key factor in having a good design.
The Repertoire of Architecture Styles

Client-Server Architecture Style

 Application context:
 Clients request services from a server
 Centralization of computation and data at the server
 Separation of user interface tasks from computation and data
management and storage
 Q: Any examples?
 Style: Client-Server

• Components: Clients and server

• Connectors: Remote procedure call, network protocols
• Data elements: Parameters and return values are sent by the connectors
• Topology: Two-level, with multi-clients
• Qualities yielded: Centralization of computation and data at the server,
with the information made available to remote clients. A single powerful
server can service many clients.
• Cautions: Network bandwidth.
 Style: Three-Tier or N-Tier

• Application context:
– Client-Server architecture style
– Multi-level services are needed
• Q: Examples?
 Style: Layered

• Application context:
– Ordered layered services are necessary
– Insulate upper layer from lower layer
• Q: Examples?
 Layered (Cont.)

• Components: Layers, offering a set of services to other layers, typically

comprising several programs or subprograms
• Connectors: Procedure call
• Data elements: Parameters and return values are sent by the connectors
• Topology: Linear, for strict virtual machine; a directed acyclic graph in
looser interpretations
• Qualities yielded: Clear dependence structure; Software at upper levels
immune to changes of implementation within lower levels as long as the
service specification are invariant; Software at lower levels fully
independent of upper levels.
• Cautions: Efficiency
 Style: Repository

• Application context:
– Collaborate and communicate through a shared repository
• A.k.a. shared state, blackboard, whiteboard
• Q: Examples?
Repository (Cont.)

•Components: ?
•Connectors: ?
•Data elements: ?
•Topology: ?
•Qualities yielded: ?
•Cautions: ?
 Style: Batch Sequential
• Application context:
– A series of dedicated and independent components that
transforms data in a sequential manner.
– Each component needs to finish its task before the next one can
start.
• Q: Examples?
 Batch Sequential (Cont.)
• Components: Independent programs responsible for a particular task or
transformation
• Connectors: Procedure call
• Data elements: Intermediate data produced or transformed
• Topology: Linear or ordered
• Qualities yielded: Solve complex task by dividing it into several easier
tasks; obtain modifiability/maintainability, reusability, and flexibility
• Cautions: Error handling; efficiency
 Style: Pipes and Filters
• Application context:
– A series of independent, sequential transformations on
ordered data
– Consists of filters transforming data and pipes transferring
data
• Q: Examples?
% ps | grep bash | sort | more
 More Architectural Styles
• Client server
• Three-tier • Event driven
• Layered • Interpreter
• Repository • Peer-to-peer
• Batch sequential • Plug-in
• Pipe and filter • Service-oriented
• Publish-subscribe
• Rule-based
• Mobile code
• …
 In-Class and Assignment:
• Study two architectural styles per team
• Prepare a 10-minute presentation for the next class
• You will present:
– What is it?
– What problem does it solve?
– How does it solve the problem?
– Who are the actors (i.e., main elements)?
– How do they relate to each other?
– What’re the strengths and drawbacks?
– Example applications?
– Include your sources (e.g., websites)
 Project Life-cycle Context
• Software development processes are standard
approaches for developing software systems.
• They impose a discipline on software engineers and,
more important, teams of software engineers.
• They tell the members of the team what to do next.
• There are four dominant software development
processes:
– Waterfall
– Iterative
– Agile
– Model-driven development
 Context of Software Architecture
• Requirements
• Design
• Implementation
• Analysis and Testing
• Evolution
• Development Process