1. ICS 52: Introduction to Software Engineering
Lecture Notes for Summer Quarter, 2003
Michele Rousseau
Topic 6
Partially based on lecture notes written by Sommerville & Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Todays Lecture
Introduction to Architecture

3. ICS 52 Life Cycle Requirements phase Verify Design phase Verify
Implementation
phase
Test
Testing
phase
Verify

4. Design Architectural design Module design
High-level partitioning of a software system into separate modules (components)
Focus on the interactions among parts (connections)
Focus on structural properties (architecture)
“How does it all fit together?”
Module design
Detailed design of a component
Focus on the internals of a component
Focus on computational properties
“How does it work?”

5. Magician Coder View
Requirements
(Insert Miracle here)
Code

6. Professional View
Requirements
Code

7. Architectural Design
Establishing the overall structure of a software system

8. Topics covered System structuring Control models Modular decomposition
Domain-specific architectures

9. Software architecture
The design process => architectural design
The output of this design process => software architecture
The organization of a system into component subsystems or modules
Driven by non-functional requirements
Divide and conquer

10. Architectural Design Buildings Software Elements Elements Types Types
Components
Interfaces
Connections
Types
Office automation
Games
Space shuttle control
Styles
Pipe and filter
Layered
Implicit invocation
Rules and regulations
Use of interfaces
Methods of change
Elements
Floors
Walls
Rooms
Types
Office building
Villa
Aircraft hanger
Styles
Colonial
Victorian
Southwestern
Rules and regulations
Electrical
Structural

11. Architectural design When? – At the early stage of the design process
Represents the link between specification and design processes
Often carried out in parallel with some specification activities
It involves identifying major system components and their communications

12. Advantages of explicit architecture
Stakeholder communication
Architecture may be used as a focus of discussion by system stakeholders
System analysis
Means that analysis of whether the system can meet its non-functional requirements is possible
Large-scale reuse
The architecture may be reusable across a range of systems

13. Architectural design process
System structuring
Decompose the system into principal sub-systems
identify communications between them
Control modelling
A model of the control relationships between the different parts of the system
Modular decomposition
The identified sub-systems are decomposed into modules

14. Sub-systems and modules
A sub-system
is a system in its own right
operations are independent of the services provided by other sub-systems.
A module
is a simply system component
provides services to other components
not a separate system (not independent)

15. System structuring Decompose system into interacting sub-systems
Block diagram
presents an overview of the system structure
More specific models show…
How sub-systems share data
How they are distributed
How they interface with each other may also be developed

16. Architectural models One shoe does not fit all!
Different architectural models may be produced during the design process
One system – Many views
Each model presents different perspectives on the architecture

17. Architectural models Static structural model Dynamic process model
major system components
Dynamic process model
process structure of the system
Interface model
Defines services through sub-system interfaces
Relationships model
relationships between subsystems
e,.g.data-flow model

18. Models consist of… Defines a class of architectures determined by:
Components (boxes)
A specific system is a collection of computational components
perform some function at runtime
Can correspond to services
Connectors
Communication between components
May have associated semantics
Constraints
Eg topoligical – no cycles

19. Architectural styles
The architectural model of a system may conform to a generic architectural model or style
An awareness of these styles can simplify the problem of defining system architectures
Most systems are heterogeneous
do not follow a single architectural style

20. Packing robot control system

21. Style Has Proven to Help
Architectural styles restrict the way in which components can be connected
Prescribe patterns of interaction
Promote fundamental principles
Rigor, separation of concerns, anticipation of change, generality, incrementality
Low coupling
High cohesion
Architectural styles are based on success stories
Almost all compilers are build as “pipe-and-filter”
Almost all network protocols are build as “layers”

22. Architecture attributes
Performance
Localise operations to minimise sub-system communication
Security
Use a layered architecture with critical assets in inner layers
Safety
Isolate safety-critical components
Availability
Include redundant components in the architecture
Maintainability
Use fine-grain, self-contained components

23. The Repository Model
Sub-systems must exchange data. This may be done in two ways:
a central database or repository and may be accessed by all sub-systems
Each sub-system maintains its own database and passes data explicitly
When large amounts of data are to be shared, the repository model of sharing is most commonly used

24. Repository Components Connectors Central data Structure
Collection of independent Components working on this central repository
Connectors
Define the interaction between the repository and the independent components

25. CASE toolset architecture

26. Repository model characteristics
Advantages
Efficient way to share large amounts of data
Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc.
Sharing model is published as the repository schema
Disadvantages
Sub-systems must agree on a repository data model. Inevitably a compromise
Data evolution is difficult and expensive
Different Subsystems may have different policy requirements (backup, recovery, security)
Becomes a bottleneck

27. Client-server architecture
Distributed system model which shows how data and processing is distributed across a range of components
Set of stand-alone servers which provide specific services such as printing, data management, etc.
Set of clients which call on these services
Network which allows clients to access servers

28. Client-Server Components –
Client: A client will originate the call to the server
Server: serves data to one or more clients
Connectors – control flow is independet except for synchronization to manage requests or receive results

29. Film and picture library

30. Client-server characteristics
Advantages
Distribution of data is straightforward
Makes effective use of networked systems.
Easy to add new servers or upgrade existing servers
Disadvantages
No shared data model so sub-systems use different data organisation. data interchange may be inefficient
Redundant management in each server
No central register of names and services - it may be hard to find out what servers and services are available
Objects must know the identity of the server

31. Abstract machine model (layered Model)
Used to model the interfacing of sub-systems
Organises the system into a set of layers (or abstract machines) each of which provide a set of services
Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected
However, often difficult to structure systems in this way

32. Abstract Machine Model(Layered Model)
Components
Defined by their function within the architecture
Each component is a serves as a client and a server.
Connectors
Each layer communicates with the layer below or above it

33. Abstract Machine /Layering - structure
is client to
Cryptography
File interface
Key management
Authentication
provides
services to
Users

34. Abstract Machine model
hierarchical organisation: each layer
provides a service to the layer above
acts as a client to the layer below
layers may either be
partially opaque (some interaction allowed between non-adjacent layers)
opaque: inner layers are hidden from all except the adjacent outer layer

35. Abstract Machine Pros/Cons
Advantages
Design based on increasing levels of abstraction
complex problem becomes sequence of incremental steps
Supports enhancement
changes to one layer affect at most two other layers
Supports reuse
different interpretations of the same layer can be used interchangeably provided they support the same interfaces
Disadvantages
Not all systems are easily structured in layers
Performance considerations
may need close coupling between logically high-level functions and their low-level impls
Can be difficult to find right level of abstraction
eg. protocols which bridge several OSI layers

36. Control models
Are concerned with the control flow between sub-systems. Distinct from the system decomposition model
Centralised control
One sub-system has overall responsibility for control and starts and stops other sub-systems
Event-based control
Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

37. Centralised control
A control sub-system takes responsibility for managing the execution of other sub-systems
Call-return model
Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems
Manager model
Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement

38. Call-return model

39. Real-time system control

40. Your Tasks
Continue working on Requirements
Ready chapters 10 & 11