Software Engineering Y2 2 (Software Architecture Styles (Decisions…
Software Engineering Y2 2
Software Architecture Styles
Abstraction of the system. Shows the components and connectors/relationships between them.
Performance - Minimise comms. Large not fine grain components
Security - Layered architecture. Critical assess in inner layers.
Safety - Localise safety-critical in small num of sub-systems
Availability - Include redundant components for fault tolerance
Maintainability - Fine grain replaceable components
Most systems don't follow a single architectural style. Mix of many
Repo/Blackboard Style - Subsystems must exchange data. Either shared data or each has their own databases. Used when subsystems have large amounts of data to share. Ads: Efficient, doesnt need to worry about how much data. Dis: Must agree on repo data model, difficult and expensive, difficult to distribute.
Client Server Model - Distributed System model. Shows components. Stand alone servers (eg printer server, mail server etc). Ads: good with networking, easy to add new server. Dis: No shared model, hard to see which server does what
Layered/Abstract Machine Model - Set of layers which provide services. Incremental development. Bottom layer is OS stuff, top layer is UI. Ads: Evolvability, changes dont affect much. Dis: Not universally applicable, Performance.
Pipe and Filter - Components are filters, connectors are pipes. Pipelines - Linear set of filters. Bounded pipes - limited data. Typed pipes - strongly typed. Ads: concurrency. Dis: Batch organisation.
Publish Subscribe - Subs register for messages/content. Pubs broadcast messages.
Event Based Style - Components emit and receive messages over busses. Components com with buses not other components directly.
Architecture Evaluation Using ATAM
Evaluation by designer - Testing done in the generate-and-test phase approach
Evaluation by peers - Peer review can be carried out at any point of the design process.
Analysis by outsiders - Once prototyped and designed
Reviewer determines attribute scenarios
Architect gives the portion to be evaluated
Each scenario is is walked through and explains
Potential problems are given
Stakeholders give the quality attribute goals for the system
Evaluate the software architecture in use. Evaluator doesn't need to be familiar with system. System doesn't need to have been started.
Can discover risks, non-risks, sensitive points and trade-offs.
Usually best to use ATAM before any code is written, after architecture is specified
Evaluation team presents overview
Customer describes the context and high level functionality
Architect presents architecture of the system
Identify architectural approaches and goals
Generate Quality Attribute Utility Tree - Basically has different nodes which get broken down. Eg. Performance -> Latency -> <200MB
Example scenarios - Outline a specific scenario of the system
Analysis - Evaluation team tries to identify risks of the current architecture
Stakeholders generate scenarios
Service-oriented architectures - Distributes systems where components are services, which could be across multiple machines and providers.
Services - Components that are loosely coupled. Eg weather service - gives information on current weather conditions
Services can be offered by any service provider, both internal and external to the company
Companies can pay for these specific services, and rely on them rather than collect their own data completely themselves. Paid for only when required.
Software as a Service (SaaS) - Software developers can rent out servers to develop, test and run their applications on. Hardware is managed and owned by the provider.
Service Oriented Architecture (SOA) - Structuring a system as stateless services. Typically used briefly, then returns a result.
Multi-tenancy - Where different clients use the same system, and it must appear as if they were the only user. This is done through efficient usage of the resources.
Scalability - Manage connections so a single server won't be overused. Don't lock out records in databases