Software Architecture What is a Software Architecture The description of the structure of a software system which is composed of software elements their externally visible properties and their relationships to each other ID: 1001075
Download Presentation The PPT/PDF document "CSci 3130 Software Architectures" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. CSci 3130Software Architectures
2. Software ArchitectureWhat is a Software Architecture?The description of the structure of a software system, which is composed of software elements, their externally visible properties and their relationships to each other.Software system design at the highest level.Closely related to Software Design – boundaries are very fuzzy.Iterative and incrementalThere is no one unique architecture for a given problemWhy do we need it?
3. Understanding and CommunicationSoftware systems are too complexAbstraction of detailsBreak a complex system into smaller, less complex sub-systems (Divide & Conquer)Individual sub-systems are better understood50% of your time you deal with people who probably don't understand you.
4. ReuseIdentifying the individual parts of the system facilitates encapsulationEncapsulation facilitates reuseMany small problems have been solved beforeSub-systems are designed and implemented for a specific purpose / task with generalized interfacesGeneralized interfaces allow the reuse of the same sub-system in a different complex systemSoftware Product LinesThe more reuse, the less money it costs, the safer your job
5. Construction and EvolutionIndividual sub-systems and well defined interfaces allow:Independent development of multiple sub-systems in parallel by different teamsIndependent testing of multiple sub-systems with much less test casesReplace one implementation of a sub-system with another implementationEasily estimate the impact of a changeYou won't get it right the first time → software evolves
6. AnalysisUp-front analysis prevents undesired surprises:Design decisionsPerformance requirementsReliabilityUsabilityDoes each sub-system satisfy its specific requirements? Under which conditions?Implementation restrictionsHardwareStorageInterconnectSupport
7. Software Architecture ModelsVarious formal models / frameworks exist:4+1RM-ODPSOMFIEEE 1471-2000 – ISO/IEC 42010-2007 (standards)Languages to describe the architecture:AcmeWrightUMLPick and chooseAll have in common: Views
8. Architecture Views
9. Architecture ViewsDescription of the architecture from different perspectives (viewpoints)Facilitates communication:Business OwnerClientSoftware DesignerDeveloperSystem BuilderEveryone has their own vocabulary
10. View model or ViewpointsA view is a representation of a whole system from the perspective of a related set of concernsA view model or viewpoints framework defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture.
11. Example ViewsSome examples of kinds of views (viewpoints in the 1471/42010 ontology) are:Functional/logical viewpointCode/module viewpointDevelopment/structural viewpointConcurrency/process/runtime/thread viewpointPhysical/deployment/install viewpointUser action/feedback viewpointData view/data model
12. Types of Architecture ViewsComponent & Connector ViewVery universal, easy to understand, high-levelModule ViewOften the result of the software designAllocationUsed by integrators and system engineers
13. Component & Connector ViewGraph-like diagram of the parts of a system and their relationshipsParts = ComponentsRelationships = Connectors
14. Component & Connector View
15. ComponentsUnits of computation or data storageDistinct names – Choose them wisely!Components have types, the C&C view shows specific instancesInterfaces (ports) to communicate with other componentsDescribe components independent of the system
16. Component Types
17. ConnectorsConnect components that interact with each otherDistinct names – Choose them wisely!All communication between components is done through connectors – not only remote.Mechanisms:Function callRPCBroker-basedProvided and implemented by middlewareBeware: Easily slips into the component implementation!
18. ConnectorsMiddleware connects componentsHardware (CPU instructions)OS infrastructure (pipes, shared-memory)Domain specific middleware (CORBA, HTTP, etc.)Different communication patterns and protocolsPoint-to-pointBroadcastMulticastHTTP / RESTCORBA (IIOP), SOAPAMQPUse different notation for different types of connectors
19. Connectors
20. Modular ViewOften logicalOften combined with a component/ connector viewCan be a software design view
21. Allocation ViewDescribes the allocation of functional objects to computational components within the system, permits analysis of performance and used to verify satisfaction of requirements Often used by integrators and system engineers
22. Data ViewThe data modelMay be relational, may not
23. Example: Student Survey
24. Architecture StylesDesign Patterns for Software ArchitecturesBest practices to solve common problemsArchitecture is a combination of manyModule View (Software Design):DecompositionUsesGeneralizationLayered
25. Examples of architectural styles and patternsBlackboardClient–server model (2-tier, n-tier, Peer-to-peer, cloud computing all use this model)Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)Distributed computingEvent-driven architecture (Implicit invocation)Front end and back endMonolithic applicationPeer-to-peerPipes and filtersPlug-in (computing)Representational State TransferRule evaluationSearch-oriented architectureService-oriented architecture (A pure SOA implements a service for every data access point.)Shared nothing architectureSoftware componentrySpace based architectureStructured (Module-based but usually monolithic within modules)Three-tier model (An architecture with Presentation, Business Logic and Database tiers)http://en.wikipedia.org/wiki/Software_architecture
26. Pipe & FilterProducer-consumer patternGood encapsulationAsynchronous processing at each componentPipe connector responsible for synchronizationParallel processing (Map/Reduce)Document processing, signal processing, ETL
27. Shared-dataData repository + data accessorsCommunication through data repositoryData repository responsible for data consistency and synchronizationAdd / remove components easilyPassive / active data repositoriesDatabase applications, Web applications
28. Client-ServerClient requests a responseResponse is generated by an action executed by the serverClient waits for responseServer itself might be a clientOften statelessClient initiatedLightweight clientsWWW, HTTP, REST
29. Publish-SubscribeProducers publish messages on a shared medium (e.g. message bus)Consumers subscribe to certain types of messagesBrokers may connect independent bus systemsScalable, transaction safe, easily extensibleIRC, ESB, AMQP
30. Peer-to-PeerLike client-server, but every component is both client and serverIntermediate components can act as proxies and/or cachesDistribution of loadHighly scalable for specific applicationsICP, CDNs, BitTorrent, Gnutella, etc.
31. DiscussionArchitecture Integrity: Why you should listen to the architect?Architecture Analysis: What can you learn from an architecture?Architecture Documentation: How to communicate an architecture?
32. Architecture IntegrityWhy listen to the architect?Architecture imposes constraintsConstraints allow to make assumptions in other parts of the systemIf the constraints are not respected, other parts of the system may no longer be compatibleDeviation impacts communication, evolution, reuse, analysis
33. Example: Word CountIntended Architecture:
34. Example: Word CountDeviating Implementation 1:
35. Example: Word CountDeviating Implementation 2:
36. Architecture DocumentationDiagrams are not sufficent documentationDocumentation needs to satisfy all stakeholdersPrimary goal is to communicate the architecture:Structure and formulate the documentation with that in mind
37. Architecture DocumentationSample Outline:Context (diagram)How does the system fit into its environment?Who interacts with the system?Relevant Views (C&C, module, allocation)DiagramDescribe the elements/components in the view in detailDescribe the interfaces between elements/componentsRationale for the decisions reflected in the architectureDescribe behaviour and processesCombine views if suitable (e.g. C&C + allocation)
38. Architecture DocumentationFormal languages:AcmeWrightUML (good choice for diagrams)English works tooDon't constrain yourselfUse whatever gets the point across.Don't overload itOne cloud is enough, and it does not need to be sparkly.
39. Architecture Analysis & EvaluationSignificant impact on qualitative properties:PerformanceReliabilityModifiabilityPortabilityMore important than decisions at the implementation level:A faster sorting algorithm only makes the chosen architecture faster, but not better.Evaluate an architecture w.r.t. individual properties
40. Architecture Analysis & EvaluationFormal simulation models can help:Difficult to capture all the information to have a representative model.Better choice for increasing system complexity (cost ↔ benefit)Alternative: Procedural ApproachList attributes to be evaluatedAssign an experience-based subjective assessment of the quality to each attribute (e.g. letter grades)
41. ATAM Architectural Tradeoff Analysis MethodDeveloped by the Software Engineering Institute at the Carnegie Mellon UniversityGoal: help choose a suitable architecture for a software system by discovering trade-offs and sensitivity points“Just” another semi formal inspection process...
42. ATAM Architectural Tradeoff Analysis MethodCollect ScenariosUse Cases, Error Cases, Exceptional Cases (e.g. high load)Attributes of interestCollect Requirements and ConstraintsCheck SRS for QoS requirements/expectations for each use case / attributeFind quantitative measuresDescribe architectures that are subject to analysisAnalyze attributes w.r.t. RequirementsIdentify Sensitivity and TradeoffsPoints with most significant impact when changesImpact on other componentsDeveloped by the Software Engineering Institute at the Carnegie Mellon University
43. What Viewpoints for Your Project?Functional/logical viewpoint?Code/module viewpoint?Development/structural viewpoint?Concurrency/process/runtime/thread viewpoint?Physical/deployment/install viewpoint?User action/feedback viewpoint?Data view/data model?