1 / 43

Introduction to Software Architecture

Introduction to Software Architecture. Csci582 reza@aero.und.edu. Objectives. Software Architecture: A preview The importance of SA Architecture vs. Design The State of the practice The State of Research The issues. Software Engineering (Programming at large).

sawyer
Télécharger la présentation

Introduction to Software Architecture

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 Architecture Csci582 reza@aero.und.edu

  2. Objectives Software Architecture: A preview The importance of SA Architecture vs. Design The State of the practice The State of Research The issues

  3. Software Engineering (Programming at large) • What is Software Engineering? • Producing products (or solving real world problems) in a cost-effective way using scientific knowledge

  4. The waterfall model of Software life cycle Req. analysis & specification Software Architecture & design Coding & unit testing Integration & system testing maintenance

  5. Software Architecture: Design at large • Architecture ? • Refers to the style and method of design and construction of buildings and other physical structures. • The study of software architecture is the study of intermediate abstraction that connect the characteristics of system users need to the characteristics of systems that software engineers can build • This intermediate abstraction then enables the engineer to capitalize on codified principles and experiences to • Specify, • Analyze, • Plan, • Monitor the system under construction

  6. Example: lack of intermediate abstraction • Instructor (user): “Build a basic transactional system to allow the following transactions: withdraw, deposit, balance inquiry • Student(software engineer): “ well, I can put together a set of classes that do searching, validating, sorting, stacking, etc. • Instructor:” Hmm, that's wonderful. But how would those classes fits into the system? ”.

  7. What is Software Architecture? • Definition: • A software system’s architecture is the set of principal design decisionsabout the system • Software architecture is the blueprint for a software system’s construction and evolution • Design decisions encompass every facet of the system under development • Structure • Behavior • Interaction • Non-functional properties

  8. What is “Principal”? • “Principal” implies a degree of importance that grants a design decision “architectural status” • It implies that not all design decisions are architectural • That is, they do not necessarily impact a system’s architecture • How does one define “principal” will depend on what the stakeholders define as the system goals

  9. Other Definitions of Software Architecture • Perry and Wolf • Software Architecture = { Elements, Form, Rationale } what how why • Shaw and Garlan • Software architecture [is a level of design that] involves • the description of elements from which systems are built, • interactions among those elements, • patterns that guide their composition, and • constraints on these patterns. • Kruchten • Software architecture deals with the design and implementation of the high-level structure of software. • Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

  10. Comparison: Building Architecture vs. Software Architecture • the construction of building • requirements gathering and analysis • Design of blueprint • Constructing the building based on blueprint • Residing in the building • The construction of Software intensive system • Requirements elicitation and analysis are performed • Specifications are created • Architectural design and low level design are performed • Code is written to implement low-level design • The system is deployed and used

  11. Point of departure between SE and BE • Structural Engineering is very well established field of engineering • There is a huge body of work about building • The essential nature of software medium is totally different from building architecture • Building is visible and tangible vs software is invisible and intangible • Software is more malleable than physical building • No software construction industry exist comparing with the building industry

  12. Software life cycle with and without SA stakeholders stakeholders requirements quality requirements quality architecture agreement agreement development development

  13. Prescriptive vs. Descriptive Architecture • A system’s prescriptive architecture captures the design decisions made prior to the system’s construction • It is the as-conceived architecture • A system’s descriptive architecture describes how the system has been built • It is the as-implemented architecture

  14. As-Designed vs. As-Implemented Architecture Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

  15. As-Designed vs. As-Implemented Architecture • Which architecture is “correct”? • Are the two architectures consistent with one another? • What criteria are used to establish theconsistency between the two architectures? • On what information is the answer to thepreceding questions based? Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

  16. Software architecture? Complexity

  17. Documenting Software Architecture - Problem • Identify architecturally significant requirements • Actors/Use cases • Non-functional • Constraints (conditions) • Example 1: • The application shall use a layered architecture, whereby each layer may only access the layer directly below it • Example 2: • All software components of the application shall be programmed in the C++ programming language

  18. Architectural Views • Modern system are too complex to grasp all by only one model • At any point, we need to limit our attention to only one structure or view • View? • Represents a coherent set of architectural elements, as written by and read by system stakeholders • It consists of representation of a set of elements and the glue among these elements

  19. Development view Logical View (scenarios) Physical View Process View Views: 4+1 Views: The actual software module organization concurrency and synchronization Mapping of SE (PROCESS) t o HW (NODES)

  20. Availability & Reliability Security Intrusion Integrity Confidentiality MTBF FMEA Hazard analysis ResourceConsumption Data Quality Bandwidth CPU time Power consumption Data precision/accuracy Temporal correctness Confidence Real-timePerformance Execution time/Deadline Deadlock/starvation Latency One model multiple views Architecture Model MBE with AADL Course

  21. Importance of SA: 1 • Understanding: • simplifies our ability to understand large systems using the right level of abstractions • Reuse • Supports reuse at design level • Evolution • Exposes the blueprint of the system, which makes it easier to understand the implications of change

  22. Importance of SA: 2 • Analysis • Provides new opportunities for different types of analysis : • High-level system consistency checking (e.g., type checking) • Conformance to styles (e.g., P/F) • Conformance to system level properties (e.g. Performance)

  23. Importance of SA: 3 • Management issue • The precise specification of SA’s initial operational capability requirements and possible/future growth allows mgt to identify key milestones • Design • Routine Design Vs. Innovative/radical Design

  24. The Current State of the practice: 1 • Much of architectural presentation is informal • Drawings • Boxes: representing processing components • Arrows: representing connections among those components • Useful to present high-level overviews of the software (good) • Useful for commutations (good) • Ambiguous (bad)

  25. SA: Example of informal design

  26. Example: Formal SA in AADL

  27. Performance analysis: AADL code system implementation cc_app.impl subcomponents RR:system RMS.impl; US:device UAV_GPS; GS:device GPARS_RADARS; ABR:device ADS_B_RECEIVER; WS:device WEATHER_STATION; WR: device WEATHER_RADAR; GOI:device GOIDS; RCC: device RCCIDS; WXI:device WXIDS; connections C21: data port US.UAV_GPS_STATUS->RR.uav_input; C22: data port GS.GPARS_RADARS_STATUS->RR.gpar_input; C23: data port ABR.ADS_B_RECEIVER_STATUS->RR.adsb_receiver_input; C24: data port WS.WEATHER_STATION_STATUS->RR.weather_station_input; C25: data port WR.WEATHER_RADAR_STATUS->RR.weather_radar_input; C26: data port RR.goids_output->GOI.GOIDS_STATUS; C27: data port RR.rccids_output->RCC.RCCIDS_STATUS; C28: data port RR.wxids_output->WXI.WXIDS_STATUS; flows F1: end to end flow WR.flow1->C25->RR.weather_radar_flow_1->C28->WXI.Flow1{latency=>300ms;}; F2: end to end flow WS.flow1->C24->RR.weather_station_flow_2->C27->RCC.Flow1{latency=>300ms;}; F3: end to end flow GS.flow1->C22->RR.gpar_flow_3->C26->GOI.flow1{latency=>300ms;}; end cc_app.impl;

  28. “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers” “We have chosen a distributed, object-orientedapproach to managing information” “The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipelinethe execution of the compiler phases over a number of processors…” “Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications” The State of Practice: informal descriptions

  29. Toward the development of Engineering Discipline using Software architecture • Software design level • High level design (Architecture) • Low level design (algorithms & Data Structure) • Code /PL level (1960-1980) • Executable • Hardware design level • Programming level (states and instructions) • Logic design level (registers and switching: RS, JK) • Circuit level (amplifiers, transistors, etc.)

  30. The Importance of Architectural design • Explicit use of architectural design can be seen • Standardized components: • common set of components forms the basis for a set of related operations • Specific systems can be realized by just adding the specializedcomponents • Product family: • common set of components that form the basis to produce a family of closely related producer; • Frameworks (platform): • A generic set of components that forms the basis of a variety of related products; need to be tailored for specific system • E.g. In OO, abstract classes/concrete classes • Domain-specific architectures: • architectural abstractions designed for specific class of systems (e.g., DoD and avionic systems)

  31. The state of research:1 • Architectural Description Languages (ADLs) • Architecture must be (formally) specified so it can verified/evaluated • Main focus is on “glue” for integrating system elements • Formal underpinnings of software architecture • Addresses the imprecision using formal methods • Formal description of non-functionalities (e.g., security) • Theories of architectural connection • Architectural analysis and simulations techniques • Focus is on new technique to test, predicate, or simulate properties of SA • Architectural development methods • Finds better processes and methods to integrate architectural techniques (e.g., model-oriented software architecture)

  32. The state of research:2 • Architectural recovery and re-engineering • Focus is on extraction of architectural design from legacy code • Architectural codification and guidance • Focus is on codifying/documenting architectural expertise using patterns/styles • Tools and environments for architectural design • Focus is on Creation of tool to support various kind of architectural activities • Case studies • Experiences and lessons learned from architectural design and analysis, etc.

  33. Key issues: • Trade off between • Precision vs. understandability • Precision vs. usability • formalism vs. incompleteness and incrementally • identification of a system as an instance of a particular architecture for a given problem • Heterogeneous Architecture vs. Homogenous one • Suitability of one ADL vs. another ADL • Single model/view vs. multiple model/views • …

  34. Distinctive role of architect: Understanding the stakeholders End-users: how dependable is the system? Maintainers: how to change? Management: how to keep track of milestones, budget, etc Acquirers: Neat features, low cost, short time to market Developers: Low cost, timely delivery, not change very often! Software Architect

  35. Architectural styles: 1 • The hallmarks of architectural design is the use of idiomatic patterns of system structures • Many of these patterns have been developed over the years as system designers recognized the value of specific configuration. • This is already done in other mature engineering • Chemical eng.: they use handbooks used also for professional curricula

  36. Architectural style: 2 • Architectural style • Defines a vocabulary of components, connectors types, and a set of constraints governing how they can be composed • Given a style • What is the design vocabulary (i.e., components, connectors, etc.)? • What are the permissible structural patterns? • What are the essential invariants of the style? • What are some common examples of its use? • What are the pros and cons of using that style? • ….

  37. Architectural Style Independent Components Event Systems Communicating Processes Implicit Invocation Explicit Invocation Data Centered Data Flow Batch Sequential Pipes and Filters Repository Blackboard Virtual Machines Call and Return Interpreter Rule-Based System Main Program and Subroutine Object Oriented Layered

  38. Architecture Evaluation: Architectures MUST be evaluated /verified • A team of independent technical experts try to demolish the design by locating the potential problems if any. • Why undertake architecture evaluation? • Architectural decisions have a big bearing on the product quality attributes (performance, evolution, availability,…) • Architecture influences team structure and other project management decisions • Any change in future, can be very costly

  39. Architecture Evaluation :2 • Inputs to an architecture evaluation • As is architecture and supporting documentation • Outputs from an architecture evaluation • Selecting between competing architectures • Ability/inability to meet quality attribute expectations, a risk mitigation approach rather than precise value prediction • Improved representation, more clarity on product quality requirements, architectural hotspots • Who participates in an architecture evaluation? • Evaluators, Development team stakeholders like project manager, architect, tech leads, customers and other stakeholders • When is an architecture evaluation done? • Early: when core requirements are clear and candidate approaches identified • Acquiring/Owning a legacy system • Some of the methods: . ATAM, SAAM

  40. Benefits • Risk mitigation/ Confidence giving • Improves clarity of the architecture being evaluated • Architect explains the architecture to a knowledgeable set of people who are not part of the project, which helps to improve its clarity • In the evaluation, new diagrams may be created, which can be refined to become part of the architecture documentation • Uncovers opportunities for reuse • Evaluators are from other projects, and through this they may be able to spot reuse opportunities for this project from their knowledge • Improves the quality of architectures created in the organization • As many architecture evaluations happen in an organization, people get sensitized to the questions and issues that get raised in these evaluations

  41. What Is a Good Architecture Anyway? • Given a functional specification, the number of architectures that can be created to meet the specification will be too many. But which is the better one? • The architecture that best meets the identified driving qualities…

  42. Examples of Driving Qualities • Not observable at Runtime • Modifiability • Portability • Reusability • Integrability • Testability • Qualities of the Architecture • Conceptual integrity • Correctness and completeness • Buildability • observable at Runtime • Performance • Security • Availability • Reliability • Functionality* • Usability • Business Qualities • Time to market • Cost • Projected lifetime of the system • Targeted market • Rollout schedule • Extensive use of legacy systems

  43. Acknowledgement Some of the slides in this work were originally produced: • by Sergey Baranov, Chief Software Architect at Motorola • by Rich Reitman at Cornell University

More Related