1. Software Engineering Architectural Design Chapter 6 Dr.Doaa Samy
Modified from Sommerville’s originals

2. Objectives  Understand the importance of architectural design.2
 Understand the importance of architectural design.
 Introduce to the architectural views.
 Understand the decisions that be made during architectural design.
 Know the architectural patterns that are often used in different types of application system.

3. Architecture 3
 Architecture: Floor plan

4. Software Design The software design process is composed of four main4
The software design process is composed of four main
design activities:
 Architectural design  this chapter.
 Data design.
 Component design.
 Interface design.

5. Software Design Deliverables5
The main deliverables of the Software Design are:
 Software architecture.
 Data structures.
 Pseudo code.
 Interface designs.
 Software Design Document.

6. Software Engineering
Architectural Design

7. UML diagram of system parts
Software Engineering
Architectural Design

8. Software Engineering
Architectural Design

9. Software Engineering
Architectural Design

10. Software Engineering
Architectural Design

11. Software Engineering
Architectural Design

12. Software Engineering
Architectural Design

13. Example: Architectural design for “Packing robot control system”20
Software Engineering
Architectural Design

14. Software Architecture6
 Architectural Design: The design process concerned with understanding how a system should be organized and designing the overall structure of that system.
 Software Architecture model: Output of this design process, describes how the system is organized as a set of communicating components.
 A Software Architecture consists of:
 Elements (components) with certain properties/behaviors.
 Relationships between them.
 Description of permitted and forbidden interactions.

15. Architectural Design 7
 It is the first stage in the software design process.
 It links between specification and design process.
 Often carried out in parallel with some of the specification activities. However, this is not ideally.
 It involves identifying main structural components in a system and the relationships between them.

16. Advantages of Explicit Architecture8
 Three advantages of explicitly designing and documenting software architecture:
Stakeholder communication
 Architecture is a high-level presentation. So, it may be used as a focus of discussion by different stakeholders.
System analysis
 Means that analyzing of whether the system can meet its critical non- functional requirements.
Large-scale reuse
 System architecture is often the same for systems with similar requirements and so can support large-scale software reuse.

17. Architectural Representations9
UML was designed for describing object-oriented systems, it is not concerned with the design process. Object classes are too close to be useful for architectural description.
Simple, informal block diagrams showing components and relationships are the most frequently used method.
Boxes indicate to the components while arrows mean that data and or control signals are passed from component to another in the direction of the arrows.

18. Box and Line Diagrams 10
 Block diagrams are an appropriate way of describing the system architecture during the design process.
 Although they are very abstract, do not show the nature of relationships between components nor the components’ visible properties, they are useful for communication with stakeholders and for project planning.

19. Architectural Views 11
 It is impossible to represent all relevant information about a system’s architecture in a single architectural model.
 Each model only shows one view or perspective of the system such as: logical view, process view, development view, and physical view.
 For both design and documentation, you usually need to present multiple views of the software architecture.

20. You don’t have to reinvent the wheel!
Architectural Styles and Patterns 12
 The architectural model of a system may conform to a generic architectural pattern or style.
 Architectural Patterns/Styles capture the essence of an architecture that used in different software systems.
 An awareness of these styles can simplify the problem of defining system architecture.
 However, most large systems are heterogeneous and do not follow a single architectural style.
You don’t have to reinvent the wheel!

21. Architecture and System Characteristics13
A particular architectural style that you choose for a system should depend on the non-functional requirements (System Characteristics):
 Performance
 If it is critical, use large and few components  less communications.
 Security
 If it is critical, use a layered architecture with critical assets in the innermost layer with high level of validation in this layer.
 Safety
 If it is critical, put safety-critical features in one or small number of sub- systems to reduces costs in the event of failure.
 Availability
 If it is critical, include redundant components  update without stop.
 Maintainability
 If it is critical, use separate components and avoid shared data structure.

22. Architectural Design Decisions.16
 The software architect must make decisions about:
System organization (structure) style.
Decomposition style.
Control style.
 Evaluating different architectures for a software is sometimes refereed to as Tradeoff analysis.

23. 1. System Organization system.17
 Reflects the basic strategy that is used to organize a
system.
 Three architectural styles are widely used:
 An abstract machine or layered style;
 A shared data repository style;
 A client/server style.

24. Layered Architecture  Used to model the interfacing of sub-systems.18
 Used to model the interfacing of sub-systems.
 Organizes 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.
 Each layer provides a set of services to the layer above and serves as a client to the layer below.

25. Layered Architecture 19

26. Example: Abstract machine model for Version management system30
Software Engineering
Architectural Design

27. The Architecture of the LIBSYS System20

28. Advantages & Disadvantages of Layered Style21
 Advantages:
 Supports incremental development.
 Changeable (if a layer changes, only adjacent layers are affected).
 Disadvantages:
 Structuring systems into layers is difficult.
 Inner layers may provides facilities required by all layers (e.g. file management).
 Performance is degraded.

29. Repository Style  Sub-systems must exchange data.22
 Sub-systems must exchange data.
 This may be done in two ways:
Shared data is held in a central database or repository and may be accessed by all sub-systems;
Each sub-system maintains its own database and passes data explicitly to other sub-systems.
 When?
 large amounts of data are to be shared, the repository model of sharing is most commonly used.

30. Advantages & Disadvantages of Repository Style23
 Advantages:
 Efficient way to share large amounts of data;
 Sub-systems need not be concerned with how data is produced;
 Centralized management e.g. backup, security, etc.
 Sharing model is published as the repository schema.
 Disadvantages:
 Sub-systems must agree on a repository data model;
 Data evolution is difficult and expensive;
 No scope for specific management policies;
 Difficult to distribute efficiently.

31. Repository Style for Project24

32. Client-Server Architecture25
 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.
 Client and server exchange data for processing.

33.  Advantages:  Disadvantages:
Advantages & Disadvantages of Client–Server 26
 Advantages:
 Servers can be distributed across a network.
 General functionality (e.g. printing service) can be available to all clients and does not need to be implemented by all services.
 Easy add new server or upgrade existing one.
 Disadvantages:
 Security problem, each server will be suspected if a fault happen.
 Performance may be unpredictable because it depends on the
network as well as the system.
 Management problems with servers owned by different organizations.

34. Client–Server Architecture for a Film Library27

35. Object models decomposition
Software Engineering
Architectural Design

36. Example: Object models for Invoice processing system
Software Engineering
Architectural Design

37. Object models decomposition
Advantages:
Loose coupling ensures that changes in one object class does not affect other objects
Since objects tend to reflect real-world entities, object models are easy to understand
Disadvantages:
Changes to the interface of an object have an impact on other users of the object
Complex entities may be difficult to represent as objects
Software Engineering
Architectural Design

38. Decomposition Styles Not Really suitable to interactive systems.28
 We will cover one modular decomposition models
 Pipe and filter or data-flow model where the system is decomposed into functional modules which transform inputs
to outputs.
Not Really suitable to interactive systems.

39. Pipeline Model 29
Input Function
Output 31

40. Pipe and Filter Architecture30
 Functional transformations process their inputs to
produce outputs.
 The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing.

41. Pipe and Filter 31

42. Invoice Processing System32

43.  Advantages:  Disadvantages: The Pipe and Filter Pattern33
 Advantages:
 Easy to understand and supports transformation reuse.
 Workflow style matches the structure of many business processes.
 Evolution by adding transformations is straightforward.
 Can be implemented as either a sequential or concurrent system.
 Disadvantages:
 Not really suitable for interactive systems.
 Although simple textual input and output can be modeled in this way, graphical user interfaces have more complex I/O formats which difficult to translated into a form compatible with the pipelining model.

44. Control models
Refers to the control flow between sub-systems (not the same as system decomposition model)
Centralized control
One sub-system has overall responsibility for control and to start/shutdown other sub-systems
Event-based control
Each sub-system can respond to externally generated events; these events may come from other sub-systems or the system environment
Software Engineering
Architectural Design

45. Software Engineering
Architectural Design

46. Centralised control
One sub-system is responsible for managing the execution of other sub-systems.
Depending on whether the controlled sub-system executes sequentially or in parallel, the centralized control models may be:
Call-return model: Applicable to sequential systems. Control starts at the top of the hierarchy, and passes to lower level processes via function calls
Manager model: Applicable to concurrent systems. Controlled by a designated manager system component that coordinates other processes
Software Engineering
Architectural Design

47. Centralized control: Call-return control
model
Software Engineering
Architectural Design

48. Software Engineering
Architectural Design

49. Centralized control: Manager control model
Software Engineering
Architectural Design

50. Example: Manager control model for Real-time system control46
Software Engineering
Architectural Design

51. Software Engineering
Architectural Design

52. Event-driven systems: Broadcast model
Software Engineering
Architectural Design

53. Event-driven systems: Selective broadcasting
Software Engineering
Architectural Design

54. Event-driven systems: Interrupt-driven systems
Software Engineering
Architectural Design

55. Event-driven systems: Interrupt-driven control
Software Engineering
Architectural Design

56. The Architectures of Application34
 Application systems are intended to meet a business or organizational needs.
 All businesses have much in in common—they need to hire people, issue invoices, keep accounts, and so on.
 Commonalities led to development of software architectures that describe structure and organization of types of software systems.
 The application architecture may be re-implemented when developing new systems, but many systems application reuse is possible without reimplementation.

57. The Architectures of Application35
 There are many types of application system and, in some cases, they may seem to be very different.
Focus here is on two processing systems:
 Transaction processing systems:
 E-commerce systems.
 Reservation systems.
 Language processing systems:
 Compilers.
 Command interpreters.

58. Example 1: Transaction Processing Systems36
 Process user requests for information from a database or requests to update the database.
 From a user perspective a transaction is:
 Any sequence of operations that satisfies a goal;
 For example - find the times of flights from London to Paris.
 Users make asynchronous requests for service which are then processed by a transaction manager.
 All operations in a transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within the transaction does not lead to inconsistencies in the database

59. Example 2: Language Processing Systems37
Language processing systems are systems in which the user’s intentions are expressed in a formal language. The best-known example for these systems are compilers
Compiler‘s components may implemented using different styles.

60. Summery 38
 A software architecture is a description of how a software system is organized.
 Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used.
 Architectural style are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages.

61. Summary 39
 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 allow information in a database to be remotely accessed and modified by 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.