1. 10 Software Architecture CSCU 411 Software Engineering

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

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

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

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

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

7. 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 topic engineering should be a compulsory topic Software be a compulsory topic Software engineering should a compulsory topic Software engineering should be compulsory topic Software engineering should be a topic Software engineering should be a compulsory The output is a KWIC-index. KWIC stands for Key Word In Context.

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

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

10. Main Program and Subroutines with Shared Data

11. 10.1.2 Abstract Data Types Module 1: Store Module 2: Input Module 3: Shift Module 4: Sort

12. 10.1.3 Implicit Invocation

13. 10.1.4 Pipes and Filters Pipes are mostly a UNIX thing Input Output

14. Evaluation

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

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

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

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

19. Design Patterns See section 10.3

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

21. Mid Term