10 Software Architecture

CSCU 411 Software Engineering

LEARNING OBJECTIVES

• To appreciate the role of software architecture in Software development

• To be able to characterize some Important software architectural styles

• To be able to distinguish different architectures for one and the same problem situation and recognize how these architectures can be used to evaluate early design decisions

• To understand the role of design patterns and be able to illustrate their properties

What is Software Architecture

• It is a vehicle for communication among stakeholders

• It captures early design decisions

• It is a transferable abstraction of a system

Influences on Software Architecture

• The Architecture is influenced by the development organization

• Architecture is influenced by the background and expertise of the architect

• Architecture is influenced by its technical and organizational environment

Define Software Architecture

• Years ago software architecture was defined as:– The architecture of a software system defines that system

in terms of computational components and interactions among those components.

• More recent definition is: – The software architecture of a program or computing

system is the structure or structures of the system, which comprise software components, the externally visible the externally visible properties of those components, and the relationships among them.

Architecture Views for Software• Typically at least the following views are recognized:

– A conceptual, or logical view, which describes the system in terms of major design elements and their interactions

– An implementation view, which gives a view of the system in terms of modules or packages and layers

– A Process view which describes the dynamic structure of the system in terms of tasks, processes, their communication, and the

– Allocation of functionality to run-time elements. This view is only needed if the system has a significant degree of concurrency;

– A deployment view, which contains the allocation of tasks to physical nodes. This view is only needed if the system is distributed.

10.1 AN EXAMPLE: PRODUCING A KWIC-INDEX• You want to look up a book with the title “Software

engineering should be a compulsory topic” • The following titles will be produced for look up.

Software engineering should be a compulsory topicengineering should be a compulsory topic Softwarebe a compulsory topic Software engineering shoulda compulsory topic Software engineering should becompulsory topic Software engineering should be atopic Software engineering should be a compulsory

• The output is a KWIC-index. KWIC stands for Key Word In Context.

Main Program and Subroutines with Shared Data

• Main Program and Subroutines with Shared Data

1. Read and store the input;

2. Determine all shifts;

3. Sort the shifts;

4. Write out the sorted shifts

Using that Idea

• Following this line of thought we may distinguish the following modules in our first decomposition:

– Module 1: Input This module reads the input then stores it.– Module 2: Shift The shift module is called after all input lines have

been read and stored.– Module 3: Sort This module uses the tables produced by modules 1

and 2. and creates a new sorted table.– Module 4: Output The output module uses the tables from modules 1

and 3 to produce a neat output of the sorted shifts.– Module 5: Control The control module does little more than call the

other modules in the appropriate order. It may also take care of error messages, memory organization and other bookkeeping duties.

Main Program and Subroutines with Shared Data

10.1.2 Abstract Data Types

• Module 1: Store

• Module 2: Input

• Module 3: Shift

• Module 4: Sort

10.1.3 Implicit Invocation

10.1.4 Pipes and Filters• Pipes are mostly a UNIX thing

Input < Input | Shift | Sort | Output > Output

Evaluation

Architectural Styles

• The classical field of architecture provides some further interesting insights for software architecture. – These insights concern:

• the notion of architectural style,

• the relationship between style and engineering, and

• the relationship between style and materials.

Different Architectural Styles

• Different engineering principles apply to different architectural styles. – Problem A description of the type of problem this style

addresses. – Context A designer will be constrained in the use of a

style by certain characteristics of the environment. – Solution A description of tile solution chosen. – Variants Architectural styles give a rather general

description. – Examples One should include references to real

examples of a style.

Functionality

• Main guidelines drive the assignment of functionality to layers in Architecture : – Hardware-dependent functionality should be

placed in lower-level layers than application-dependent functionality.

– Generic functionality should be placed in lower layers than specific Functionality.

Functionality

• The resulting architecture has four layers: – Operating system– Equipment Maintenance– Logical Resource Management– Service Management

Design Patterns

• See section 10.3

10.4 VERIFICATION AND VALIDATION

• Reviews and inspection can be used earlier than previous techniques

• Scenarios can be used sooner

• Testing can be developed starting at the skeletal level (can not perform the test but can plan)

• May be able to do incremental testing

Mid Term