1 / 54

Introduction to Software Architectures

This course provides an overview of software architectures, including standards, modeling, documentation, design, analysis, and evaluation. Learn why software architecture is important and how it impacts software quality.

clairem
Télécharger la présentation

Introduction to Software Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. بسم الله الرحمن الرحيم الحمد لله ، والصلاة والسلام على رسول الله Introduction to Software Architectures Hany H. Ammar, Professor, LANE Department of Computer Science and Electrical EngineeringWest Virginia University, Morgantown, West Virginia, USA, and Faculty of Computers and Information, Cairo University, Cairo, Egypt Software Architectures Course Overview

  2. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Line Architectures • Software Architecture Evaluation Software Architectures Course Overview

  3. Introduction to Software Architectures Software Architectures Course Overview

  4. Why Software Architecture ? Software architecture is a major determinant of software quality (performance, deployment, maintenance and product evolution) “Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and tradeoffs” - The Rational Unified Process, 2002 Software Architectures Course Overview

  5. Why Software Architecture ? • The Carnegie Mellon Software Engineering Institute (SEI) developed the Architectural Tradeoff Analysis Method (ATAM) for qualitative evaluation of architectures by expert evaluators and validated its usefulness in practice. • This process not only permits evaluation of specific architecture quality attributes (e.g., modifiability, performance, security, and reliability) but also allows engineering tradeoffs to be made among possibly conflicting quality goals. Software Architectures Course Overview

  6. Software Architecture Views • Architecture viewsprovide the basis for reasoning about the appropriateness and quality of the architecture for achieving system quality goals. • Some common architectural views include • the logical view, which represents system functions; key system abstractions and their dependencies; and data flows • the module decomposition view, which represents the hierarchical decomposition of the system's functionality into units of implementation. This decomposition can include objects, procedures, functions, and their relationships. • the communicating-processes view, which represents processing threads, their synchronization, and the data flows between them • the deployment view, which shows how the software is allocated to hardware including processors, storage, and external devices or sensors, along with the communications paths that connect them Software Architectures Course Overview

  7. More on Views • Views serve as the primary vehicle for communicating the architecture to its stakeholders, the primary engineering handle for designing quality attributes into the system, and the primary window into the architecture for evaluators who are checking it for fitness of purpose. Software Architectures Course Overview

  8. What is software architecture ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution Software Architectures Course Overview

  9. What is software architecture A simplified Definition A software architecture is defined by a configuration of architectural elements--components, connectors, and data--constrained in their relationships in order to achieve a desired set of architectural properties. Software Architectures Course Overview

  10. Software Architecture Elements • A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface • A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components. Software Architectures Course Overview

  11. Software Architecture Elements • A datum is an element of information that is transferred from a component, or received by a component, via a connector. • A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time. • An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. • Detailed example: http://sunset.usc.edu/SSCS/toc.html Standard Satellite Control SegmentReference Architecture Software Architectures Course Overview

  12. Example of an Architecture Development Process Software Architectures Course Overview

  13. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Lines • Software Architecture Evaluation Software Architectures Course Overview

  14. Software Architectures Standardshttp://www.sei.cmu.edu/architecture/IEEE_1471.html • IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems • One hallmark of the maturity of a discipline is the development of standards codifying concepts, terms and practices that have become understood and widely applied within that discipline. • In 2001, ANSI adopted it as an American standard. Most recently, ISO recently adopted IEEE 1471:2000 as ISO/IEC 42010:2007, Systems and Software Engineering—Architectural Description. Software Architectures Course Overview

  15. IEEE 1471 Goals and Objectives • Define direction for incorporating architectural thinking into IEEE standards • ¨ Take a “wide scope” interpretation of architecture as applicable to software-intensive systems • ¨ Establish a conceptual framework and vocabulary for describing architectural issues of systems. • ¨ Identify and promulgate sound architectural practices • ¨ Allow for the evolution of those practices as relevant technologies mature Software Architectures Course Overview

  16. Software Architectures Course Overview

  17. Software Architectures Course Overview

  18. IEEE 1471 Conceptual Framework • An architectural description (or AD) is organized into a set of architectural views. • Each view addresses one or more architectural concerns held by the system stakeholders interested in that architecture. • An architectural concern is any area of interest in the system's construction, deployment, use or other factors which could affect its architecture. • An AD is incomplete when there are identified architectural concerns which are not addressed in at least one view. • An architectural view is a set of architectural models. The notations, techniques and rules for constructing and interpreting those models must be documented to enable architects to create – and stakeholders to understand – a conforming architectural view. • The notations, techniques and rules are described in an architectural viewpoint. Software Architectures Course Overview

  19. Software Architectures Course Overview

  20. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Lines • Software Architecture Evaluation Software Architectures Course Overview

  21. A Simple Example of Software Architecture Using UML2 • EXAMPLE: SATELLITE CONTROL SYSTEM Use-Case Diagram Software Architectures Course Overview

  22. A Simple Example of Software Architecture Using UML2 • SATELLITE CONTROL SYSTEM Architecture composition Software Architectures Course Overview

  23. A Simple Example of Software Architecture Using UML2 • SATELLITE CONTROL SYSTEM Architecture structure Software Architectures Course Overview

  24. A Simple Example of Software Architecture Using UML2 • SATELLITE CONTROL SYSTEM Architectural behavior Software Architectures Course Overview

  25. . Architectural Description languages Software Architectures Course Overview

  26. Architectural Description Languages Software Architectures Course Overview

  27. Architectural Description Languages Software Architectures Course Overview

  28. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Lines • Software Architecture Evaluation Software Architectures Course Overview

  29. Architecture Development Software Architectures Course Overview

  30. The outline of the architecting method framework submethods Quality Attributes explore specific details Software Architectures Course Overview

  31. Iterative Architecting Process Software Architectures Course Overview

  32. Designing Architectures: Attribute-Driven Design (ADD)http://www.sei.cmu.edu/architecture/add_method.htmlhttp://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr023.pdf • A method of designing an architecture to achieve quality and functional needs • In ADD, architecture design is developed by taking sets of quality attribute scenario inputs and using knowledge of relationship between quality attribute access and architecture. • Develops a software architecture based on process decomposition, stepwise refinement and fulfillment of attribute qualities. • It is a recursive process where at each repetition, tactics and an architecture style or pattern is chosen to fulfill quality attribute needs. Software Architectures Course Overview

  33. ADD Steps These steps form an iterative stepwise refinement process • Choose a component to decompose • Refine the component based on these steps: a. Choose architecture driver b. Choose architecture style or pattern c. Instantiate component and place functions using different views d. Create interface on sub-components e. Identify and enhance use case and quality scenario to be used as constraint for sub-components 3. Repeat all the steps above for each component that needs to be decomposed. Software Architectures Course Overview

  34. Architectural Styles • An architectural style is a class of architectures characterized by: • Components types: are component classes characterized by either SW packaging properties or functional or computational roles within an application. • Communication patterns between the components: the communication protocols between the component types. • Semantic constraints, indicating the behavioral properties of the components individually, and in the context of their interactions. • A set of connectors, SW artifacts that enable us to implement the communication between the components in a way that satisfies the semantic constraints. Software Architectures Course Overview

  35. Architectural styles grouped into families • Independent Components. SW system is viewed a set of independent processes or objects or components that communicate through messages. Two subfamilies: • Event based systems (implicit and direct invocation style) and • Communicating processes family (client-server style). Software Architectures Course Overview

  36. Architectural Styles: Event-Based Architectures Software Architectures Course Overview

  37. Architectural Styles: Virtual Machines 2. Virtual Machines. User programs are treated as data by a virtual machine, which is an abstract machine implemented entirely in software, that runs on top of the actual hardware machine.ex rule-based style. Software Architectures Course Overview

  38. Architectural Styles: Data Flow 3. Data Flow. Include batch sequential systems and pipes and filters. BSS, different components take turns at processing a batch of data, each saving the result of their processing in a shared repository that the next component can access. PF, we have stream of data through a more or less complex structure of process (filters). Ex, UNIX. Software Architectures Course Overview

  39. Architectural Styles: Data Centered 4. Data-Centered Systems. Consist of having different components communicate through shared data repositories. When data repository is an active repository that notifies registered components of changes in it then-blackboard style. Software Architectures Course Overview

  40. SW Systems-Mix of Architecture Styles • Most SW systems use a mix of architecture styles. Ex, personnel management system with a scheduling component, implemented using the independent component style, and a payroll component, using the batch sequential style. • Choosing a style to implement a particular system depends on several factors. The technical factors concern the level of quality attributes that each style enables us to attain. • Event-based systems-achieve very high level of evolvability, at the expense of performance and complexity. • Virtual-machine style-achieve very high level of portability, at expense of performance and perhaps even testability. Software Architectures Course Overview

  41. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Lines • Software Architecture Evaluation Software Architectures Course Overview

  42. What is software Product Line? • Re-use of asset architecture for some systems can maximize company investment. • Mature organization keeps their architecture as an intellectual asset which is very valuable and able to increase turn over and reduce cost. • Software Product Line – discipline, and re-use strategy sharing of asset in producing a group of products. • Objective – able to re-use asset from the previous projects such as basic architecture, the same element, designs, documentations, user manual, artifact project management such as budgeting and scheduling, and test plan & test cases. • When the product line produced, the assets will be kept in asset library to be used for other projects. Software Architectures Course Overview

  43. What is Software Product Line? • Software product line is defined as “A set of software-intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission” • These Systems are developed from a common core of assets (e.g. a common architecture) in a prescribed way. Software Architectures Course Overview

  44. Product Line Architecture • Software architecture is the most important asset in a product line. • There are three important things that need to be acknowledging by the architecture in product line: • Identifying variation point. • Supporting variation point. • Evaluate the suitable architecture for the product line. Software Architectures Course Overview

  45. Supporting Variation Point • Architecture will support variation point the form of: • Using or eliminating elements. • Using the same elements with variant attributes. • Choosing the element which has same interface but different implementation or different quality attribute. • Techniques: • In OO system, the use of specialization and generalization for class. • Developing extension points at the element. • Using the same parameter with in the component. • Over loading – using the same function in different type of data. Software Architectures Course Overview

  46. Example 1: PLA for a Microwave Oven Software Architectures Course Overview

  47. Definition of Terms Used in the Example Class Diagram • Kernel: Kernel in product lines represents the mandatory features for the product line members. i.e.: they cannot be omitted in products. The stereotype <<kernel>> is used to specify Kernel in UML class diagrams. • Optional: Optionality in product lines means that some features are elective for the product line members, which means they can be omitted in some products and included in others. The stereotype <<optional>> is used to specify optionality in UML class diagrams. The optionality can concern classes, packages, attributes or operations. • Variant: Variant classes are modeled using UML inheritance and stereotypes. Each variation point will be defined by an abstract class and a set of subclasses. The abstract class will be defined with the stereotype <<variant>> and each subclass will be stereotyped <<variant>>, or <<optional>>, the default value being variant. Software Architectures Course Overview

  48. Example 1(cont.): Microwave Sample Sequence Diagram Software Architectures Course Overview

  49. OUTLINE • Introduction to Software Architectures • Software Architectures Standards • Modeling and Documenting Software Architectures • Software Architecture Design and Analysis • Software Product Lines • Software Architecture Evaluation Software Architectures Course Overview

  50. Software Architecture Evaluation The Architecture Tradeoff Analysis Method (ATAM) The following diagram displays a conceptual flow of the ATAM. http://www.sei.cmu.edu/architecture/ata_method.html Software Architectures Course Overview

More Related