1. Software Architecture premaster course 1

2.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2

3.  Introduction  Representations  Styles  Architecture description language  Conclusion 3

4.  Introduction  Representations  Styles  Architecture description language  Conclusion 4

5.  Is the study of the structure of large software systems.  It concerns itself with achieving non- functional qualities in large systems. 5

6.  Introduction  Representations  Styles  Architecture description language  Conclusion 6

7.  ADD method  ATAM method 7

8.  It is Attribute-Driven Design approach to defining a software architecture in which the design process is based on the software’s quality attribute requirements.  The method has been used for designing the software architecture of products ranging from embedded to information systems. 8

9.  ADD follows a recursive design process that decomposes a system by applying architectural tactics and patterns that satisfy its driving requirements.  This method is based on understanding the relationship between software qualities and the architecture mechanisms used to achieve these qualities. 9

10.  Supporting the earliest stages of the design process where the ability to achieve desired quality attributes is determined.  Allowing design to begin early enough in the life cycle to support modern time-to-market requirements. 10

11. PlanDoCheck 11

12. 12

13.  Architecture Tradeoff Analysis Method (ATAM) is a risk-mitigation process  ATAM is used early in the software development life cycle 13

14.  Clarified quality attribute requirements  Improved architecture documentation  Documented basis for architectural decisions  Identified risks early in the life-cycle  Increased communication among stakeholders 14

15. 15

16. 1. Present ATAM - Present the concept of ATAM to the stakeholders, and answer any questions about the process. 2. Present Business Drivers - Everyone in the process presents and evaluates the business drivers for the system in question. 3. Present the Architecture - The architect presents the high level architecture to the team, with an 'appropriate level of detail. 16

17. 4. Identify Architectural Approaches - Different architectural approaches to the system are presented by the team, and discussed. 5. Generate Quality Attribute Utility Tree - Define the core business and technical requirements of the system, and map them to an appropriate architectural property. Present a scenario for this given requirement. 17

18. 6. Analyze architectural approaches - Analyze each scenario, rating them by priority. The architecture is then evaluated against each scenario. 7. Brainstorm and prioritize scenarios - among the larger stakeholder group, present the current scenarios, and expand. 8. Analyze architectural approaches - Perform step 6 again with the added knowledge of the larger stakeholder community. 9. Present results - provide all documentation to the stakeholders. 18

19.  Introduction  Representations  Styles  Architecture description language  Conclusion

20.  It provides a framework on which to base design  Style of software architecture is an established pattern of components with a name, such as client-server architecture

21. 1- Pipe and filter:

23. 2- Object-oriented Architecture:  The focus is on the different items in the system, modeled as objects, classes etc.  Object orientation is one of the most widely spread architectural styles, both in education, industrial practice and science.

24. 3- Layered Architecture:

25. 4- Blackboard Architecture:

27. 5- Client-Server Architecture:

28. 6- Process Control:  Real-world systems often control a physical reality, such as control systems in a power plant.  There are a number of software paradigms for process control.  The significant properties are that the software takes its input from sensors and perform control actions.  The control loop may be of feedback or feed-forward type.

29. 7- State Machine:

30.  Introduction  Representations  Styles  Architecture description language  Conclusion

31.  provides features for modeling a software system’s conceptual architecture, distinguished from the system’s implementation.  capture and represent details of software systems at the architectural level.

32.  DAOP-ADL  ACME

33.  Description language used to describe components and aspects, together with the composition rules that govern the weaving of components and aspects.  The visual notation of the DAOP-ADL language is CAM (Component-Aspect Model).

35.  Architecture descriptions using DAOP-ADL comprises of the two parts: - Defines standalone components and aspects - Composition specification.

37.  It is an ADL (Architecture Description Language) that was developed to create a common interchange format in the software engineering community.  Provides the following key features: o An architectural ontology consisting of basic architectural design elements.

38. o A flexible annotation mechanism supporting association of non-structural information using externally defined sublanguages. o A type mechanism for abstracting common, reusable architectural idioms and styles. o An open semantic framework for reasoning about architectural descriptions.

39.  A trivial architectural drawing containing a client and server component, connected by an RPC connector.

40.  Acme supports the hierarchical description of architectures any component or connector can be represented by one or more detailed, lower-level descriptions.

41.  Introduction  Representations  Styles  Architecture description language  Conclusion

42.  Architecture of a software system is its structures comprising of elements, their external properties, and relationships.  Architecture is a high level design.  Architecture can be analyzed for various non- functional attributes like performance, reliability, security, etc.