WHY SA
Managing complexing Share stockholders communication Constrain early stage design reuse knowledge reduce risks
What SA
The highest-level structure of a software system, defining its components, relationships, constraints, and the principles guiding design and evolution.
Style
Data Flow
Batch: adv: clear modular seperation, easy to debug. disadv: high latency between steps, Pipe-and-filter : adv: Reusable filter, low coupling, concurrent execution disadv: Poor for interactive app, Format conversion overhead, hard to share state
diff: ![[Batch_VS_PaF.png]]
Event system
no dispatcher: observer dispatcher: P2P, Publish-Subscribe
adv: decoupling handler easy to add listeners fault isolation high reuse disadv: dispatcher bottleneck less control event storms harder correctness
Call-Return
Main subroutine Object oriented Layered MVC Client-Server: 2-Tier: Client(UI + logic) -> Database server 3-Tier: Client(UI) -> App Server (logic)-> Database Browser: Browser ->(Http) Web Server -> Database
Data-Centered
Repository Blackboard
Virtual machine
speed ↓ portability ↑ Interpreter(JVM) Rule-Base System
Modern
Microservices: one service one job, good fault tolerant, for large proejct. complex
Serverless: only when event come call up the function, no server remain.
Monolith: one deploy, one project, fast, for new project and small team. hard to scale
UML
Use case: ![[SA_UseCase.png]] Class: ![[SA_Class.png]] Sequence & Communication: ![[SA_Seq_Com.png]] State: ![[SA_State.png]] Activity: ![[SA_Activity.png]]
4+1 view and UML:
logical: what are the parts : object, class, state, seq process: what's concurrent : activity deployment: How organized : package, component physical: where deployed :Deployment scenario(use case)(+1) : what it do : use case
QA
Performance
Res Demand: Algorithms, reduce data, limit execution time Res management : concurrency, Maintain multiple copys, increase resource Res Scheduling: FIFO, Fixed priority, dynamic priority, Earliest deadline first
| Part | Answer |
|---|---|
| Source of Stimulus | End user |
| Stimulus | Searches for a product |
| Artifact | Search service |
| Environment | Peak load with 10,000 concurrent users |
| Response | Returns relevant search results |
| Response Measure | 95% of requests complete within 2 seconds |
Availability
fault detect: heartbeat: sent signal every minute fault recovery: add checkpoint to rollback, redundancy fault avoid: monitor, service removal,
| Part | Answer |
|---|---|
| Source of Stimulus | External payment service |
| Stimulus | Becomes unavailable |
| Artifact | Order processing system |
| Environment | Normal operation |
| Response | Switches to backup payment provider and continues accepting orders |
| Response Measure | Service recovers within 30 seconds, and no more than 1% of orders fail |
Modifiability
limit scope of modification: reduce coupling, encapsulate, increase cohesion, Delay binding time: runtime configuration, on-demand loading
| Part | Answer |
|---|---|
| Source of Stimulus | Developer |
| Stimulus | Changes the payment provider |
| Artifact | Payment module |
| Environment | Maintenance phase |
| Response | Replaces the provider without modifying order processing logic |
| Response Measure | Completed within 1 working day with no changes to OrderService |
Security
Resist atk: Authentication authorization, Data confidentiality(encrypt, HTTPS, SHA) Detect atk: Software monitoring, security experts Recover from atk: Restore, atk identification
| Part | Answer |
|---|---|
| Source of Stimulus | Unauthorized user |
| Stimulus | Attempts to access another user’s account |
| Artifact | Authentication and authorization service |
| Environment | Normal operation |
| Response | Denies access and logs the attempt |
| Response Measure | 100% of unauthorized access attempts are denied and logged |
Usability
Runtime: Anticipate user tasks, user feedback, maintain consistency use experience Design-Time: Support undo, MVC separate, UI change don't affect logic
| Part | Answer |
|---|---|
| Source of Stimulus | New user |
| Stimulus | Uses the application for the first time |
| Artifact | User interface |
| Environment | Normal operation |
| Response | Guides the user to complete account registration without external help |
| Response Measure | 90% of new users complete registration within 5 minutes with no more than one input error |
Testability
Black-box: Replay, separate interface implement, controlable input, observable output. White-box: create monitor, log, breakpoint, debugging tools
| Part | Answer |
|---|---|
| Source of Stimulus | Tester |
| Stimulus | Runs automated regression tests |
| Artifact | Order processing module |
| Environment | Before release |
| Response | Executes tests with controlled inputs and observable outputs |
| Response Measure | 90% branch coverage achieved and all critical tests completed within 10 minutes |
Design Small
Rigidity: change affect manage modules -> extract behind abstraction // predictable Fragility: Breaks in unrelated places -> isolate module scopes // unpredictable immobility: can't use for reuse -> separate abstraction interface and logic functions. Viscosity: Right way hard -> make right way easy Opacity: code hard to read/understand -> code review and reminder Needless complexity: overcomplicated -> wait for real need // waste Needless repetition: CP -> abstraction // hard to maintenance
Principle of Design
Separation of Concerns: one service one concern -> modules
Information Hiding: hiding likely changes things(inner details) -> encapsulation
SOLID Single responsibility: only one reason to change -> Rigidity, Fragility Open-close: Open for extension close for modification-> Rigidity, Fragility, Immobility Liskov Substitution: subtype can change the base type -> Fragility Interface segregation: Clients should not depend on methods they do not use -> Rigidity, Viscosity Dependency inversion: Least known -> Rigidity, immobility
DRY: don't repeat yourself KISS: Keep It Simple, Stupid YAGNI: You Ain't Gonna Need It
Coupling
Content: A modify B Common: Share Global data Control: A use some signal control B Stamp: Share whole data structure use only a part Data: only share data
Cohesion
Coincidental: Cohesion by accident Logical: categorically similar functionality diff Temporal: Run at a same time Procedural: group by sequence but no data sharing Communicational: operate same data in a sequence Sequential: output of A is input of B Functional: All elements contribute to a single well-defined work