CS 551 - Architecture

download CS 551 - Architecture

of 67

  • date post

    22-Jan-2016
  • Category

    Documents

  • view

    27
  • download

    0

Embed Size (px)

description

CS 551 - Architecture. P. E. R. F. O. O. A. R. &. M. M. A. ERROR RECOVERY. N. C. E. PROBLEM. REQUIRE. REQUIRE. MENTS. MENTS. Systems Architecture. CS 551 Lecture 5. Software Architecture Lessons. - PowerPoint PPT Presentation

Transcript of CS 551 - Architecture

  • CS 551 - Architecture

    CS 564a Fall 004

  • Systems ArchitectureCS 551 Lecture 5

    CS 564a Fall 004

  • Software Architecture LessonsA good software architecture may be the single most important characteristic for a successful software development.It is the key framework for all technical decisions.It has a profound influence on the organization of the project.The architecture of the system should be documented in a clear and concise way and communicated to everyone on the project.Use architecture reviews to make sure that the integrity of the architecture is preserved as new features and functions are added.Periodically renew the architecture.

    CS 564a Fall 004

  • What is Software Architecture?The framework for all technical decisions.A coherent, justified collection of design decisions.Technology and platform selection to match the problem. A vehicle for communication among stakeholders.A balance between features, cost and schedule.A reusable and transferable abstraction of a system. The basis for a product line or product family.A mechanism to insure that the system meets the reliability, capacity, response time and throughput requirements.Simplest satisfactory solution.

    CS 564a Fall 004

  • Benefits of Good Software ArchitecturesHelps identify and isolate reusable components that can speed implementation and improve system quality.Assists in measuring project impacts of inevitable ongoing technical and business decisions and compromises.Leads to clearly defined organizations with inherent project efficiencies, good communications and decision making.

    CS 564a Fall 004

  • Architecture in a Projects Life CycleDiscoveryPlanning andArchitectureReviewReviewArchitecture PhaseLowLevelDesign

    CS 564a Fall 004

  • What we look for in an ArchitectureThe purpose the system is intended to satisfy.The major functional components and/or platforms.The relationship between the components.The fit to function.The dynamic interplay of control and communication between these components.The systems ease of use.The data storage and flow of data among these components.The resources which are consumed by each component in the performance of its task.

    CS 564a Fall 004

  • Kruchtens 4 + 1Model for Developing Software Architecture+ 1 Business Scenario+ 1 BusinessScenario+ 1 Business ScenarioView 1Logical--End UsersView 2Process--System IntegratorsView 3Physical--EngineersView 4Execution--ProgrammersThis is an innovative andcomprehensive integrationof the abstractions needed to design the structure for writingsystem requirements.

    CS 564a Fall 004

  • Cost of Modifying Modules for Reuse -- NASA Data for 2954 ModulesAmount ModifiedRelativeCost

    CS 564a Fall 004

  • Open Systems Interconnection Model The Foundation for Distributed Software Systems

    CS 564a Fall 004

  • ARCHITECTURE REVIEWS Found:Problem Areas

    CS 564a Fall 004

  • Project Management Findings1. Aggressive schedule forcing inadequate time and focus on fundamental architecture issuesAttempts at working issues in parallel with development often leads to major rework or complete failure2. Lack of central management or architecture consistency for projects attempting to integrate multiple systems3. No clear success criteria - multiple, subjective views of customer expectations4. No clear problem statement - multiple, or conflicting goals5. No architect (or architecture effort); no central coordination and record of system wide technical decisions6. Lack of buy-in from all stakeholders on requirements or architecture issues

    CS 564a Fall 004

  • Requirements FindingsApproximate Occurrences

    CS 564a Fall 004

  • Requirements Findings1. Lack of Functional RequirementsNo requirements have been written in key areasUsage scenarios not understood and documentedFunctionality of the system incompleteCustomer unknown or not contactedNo acceptance criteria for the system2. Lack of Performance & Capacity RequirementsNumber and/or types of users undocumentedTransaction and data volumes unknownNight or batch processing unknown3. Lack of OA&M RequirementsNo OA&M requirements documentedNo availability requirements documentedAvailability requirements not tied to customer needs (e.g. 7 X 24)

    CS 564a Fall 004

  • Design FindingsApproximate Occurrences

    CS 564a Fall 004

  • Design Findings1. Performance EngineeringOften the performance requirements are not fully understood.Build it now, tune it later Processing, memory, disk utilization (such as database transactions) needs are not well understood by the architects.Assumption that the system will scale linearly as the load grows No performance budgets2. Operations, Administration, Maintenance and Provisioning (OAM&P)These components include installing the system, booting/rebooting, backup and recovery, remote maintenance and diagnostics, initializing the data needed for the system to operate, and tools to provision the growth of the system.Design and implementation often underestimated.Design done late in cycle and inconsistent with remainder of system features. 3. Error Handling and RecoveryLack of a system error strategy for catching, reporting and recovering from both hardware and software failures.Error strategy design is the process to examine error scenarios.

    CS 564a Fall 004

  • Service Capacity Planning

    CS 564a Fall 004

  • GoalsTo support and drive service scalability targets.To identify early architecture and network issues.To communicate between business management and the technical community.

    CS 564a Fall 004

  • Scalability OverviewCapacity modeling before service deploymentPeriodic usage reporting as service deployedCapacity management as service deployedMonitoringGrowth Planning and Implementation

    CS 564a Fall 004

  • Capacity Modeling

    CS 564a Fall 004

  • Load Projections ExampleTotal Users50,000

    CS 564a Fall 004

    Market Segment

    Percent of users

    Number of users

    Monthly hours per user

    User hours per day

    Busy Hour Load

    Busy Hour Users

    Busy Hour (EST)

    City 1 POP

    20%

    10,000

    7.7

    2800

    11%

    311

    2:00 PM

    City 2 POP

    14%

    7,000

    5.2

    3000

    10%

    250

    4:00 PM

    Services

    Number per day

    Elapsed time per service in minutes

    Number of transactions per user

    Av. Number of Kbytes per transaction

    Login

    150000

    .01

    1

    0. 3

    email

    750000

    20

    25

    150

    netnews

    35000

    Web Hosting

    10000

    Access to Portal

    60000

  • AcknowledgementThanks to Joe Maranzano, he is the class of software architects.

    CS 564a Fall 004

  • Architecture Description LanguageThanks to Ed Colbert, USC

  • Problems Developing Embedded Real-Time SystemsReliability, safety, & performance are vital concernsWrong or late answer can be deadlyHardware dependent integration and migration Few means of assessing impact of decisions Upgrades throughout an extended deployment

    CS 564a Fall 004

  • Problems Developing Embedded Real-Time Systems (cont.)Current development processManual, paper intensive, error prone, resistant to changeDisjoint modelsModels not kept upRequirements AnalysisDesignImplementationIntegration

    CS 564a Fall 004Ed Colbert - updated

  • Problems Developing Embedded Real-Time Systems (cont.)A welldesigned architecture is essential, but architectural descriptions are Informal documentsUsually centered on box-and-line diagrams, with explanatory proseVisual conventions are idiosyncratic & project-specific

    CS 564a Fall 004

  • What is an Architecture Description Language?Describe high-level designsTreats systems as collections of connected modulesModule layout defines structureConnectors define communication Iinterfaces are modulesDoes NOT describe algorithms, data structures or control flows

    CS 564a Fall 004

  • Avionics ADLSpecification ofReal-timeEmbeddedFault-tolerantSecurely partitionedDynamically configurableSoftware task and communication architecturesBound to distributed multiple processor hardware architectures

    CS 564a Fall 004

  • Model-Based AADL ProcessArchitecture-based RequirementsAnalysisArchitecture-based Design and ImplementationArchitecture-based System IntegrationRapid Integration Predictable System UpgradeabilityExplicit ArchitectureEngineering Model

    CS 564a Fall 004

  • Model-Based AADL EngineeringReal-Time Architecture ModelSoftwareHardwareSystem Build Executive Generation Module IntegrationNmakeDomainSpecificHardwareMemoryConfigurationBusDesignProcessorArchitectureDomain Specific LanguagesHand Coded ComponentsHand Coded ComponentsAnalyses Schedulability Reliability Fault Tolerance

    CS 564a Fall 004

  • An Engineering ParadigmFormal specification of architecture & propertiesEarly detection: repeated system analysesError elimination: automatic generation & integrationRapid evolution: refinement of models & componentsManaged change impact: Separation of concerns

    CS 564a Fall 004

  • Generated Partitioned Architecture Strong Partitioning Timing Protection OS Call Restrictions Memory ProtectionPortability Application Components Tailored MetaH Executive MetaH Kernel

    Operating EnvironmentSoftware ComponentSoftware ComponentSoftware ComponentEmbedded Hardware TargetSoftwareComponentMetaH Executive

    MetaH KernelFault Recovery, Execution Control, Mode Control, Timing Control, Data Synchronization, Interprocess Communication

    CS 564a