Software architecture
- Introduction
Definition: the fundamental organization of system
Input: Software requirements specification (SRS)
Output: Software design description (SDD)
Architecture Styles
Definition: Abstracts the common properties of a family of similar design, also known as "architecture pattern"
Key components:
Elements: perform functions required by system
Connectors: enable communication among elements
Constraints: define how elements can be integrated
Attributes: advantages & disadvantages of structure
Quality attributes
Sample quality attributes:
Reliability: Continue to keep operating over time not causing exception
Portability: Run on numerous platforms
Usability: How the user use system effectively and the ease of learn
Security: resist or block malicious or unauthorized attempts that affect the system
Testability: How well to perform tests
Maintainability: Easy to maintain and support changes cost-effectively
Availability: Raito of available system time to total working time
Flexibility: Ability of a system to adapt to future changes
Interoperability: Communicate or exchange data with other systems
Scalability: Handle demand for stress caused by increased usage without decreasing perfomance
Performance: response to actions within a period of time
Quality attributes trade-off
- Models for Software architecture
UML diagram
View models
Purpose: Visually representing a system along with its elements to better understand, alter, maintain or document about system
2 major categories
Structural (Static): Show the hierarchy or structure of components or module of the system and show how they interact
Behavioral (Dynamic): show the dynamic behavior of the objects in system
Show a set of classes, interfaces and their relationship
Show set of objects and relationships which is the static instances
Show internal structure of a classifier and interaction with environment
Show a set of components and relationship that illustrates the static implementation view of system
Represented by a tabbed folder such as namespace in .NET and packages in Java
Describe the physical configuration of system
An overview of use cases, actors and their communication with system
Representations of workflows of stepwise activities and actions
Event-oriented diagram used for behavior of a part of a designed system through finite state transitions
Time-oriented interaction diagram used for showing the chronological sequence of messages between objects
Describes the control flow of the interaction
Message-oriented diagram summarizes how objects in the system receive and send messages. Equivalent to sequence diagram
Is new in UML 2.0 combining the state diagram and time sequences to show the dynamic view of state change caused by external event over time
A model is a simplified description of a system from a particular perspective or viewpoint
logical view: objects and their interactions
Support by Interaction diagram, Sequence diagram, Communication diagram, State machine diagram & Activity diagram
process view: system activities, their concurrency and synchronization
Support by Activity diagram
physical view: mapping of software into hardware, server and network
Support by Deployment diagram
development view: software static structure within given development environment
Support by Component diagram
scenario view: real world scenario
- Object oriented paradigm (method)
OO principles
Encapsulation: Only exposes the selected information
Inheritance: Entities can inherit attributes from other entities
Polymorphism: Entities can have more than one form
Abstraction: Hides complex details to reduce complexity
Static polymorphism: implement multiple method with the same name but different params which called method overloading
Dynamic polymorphism: A subclass can override a method which called method overriding
Relationship among classes
Composition: class 2 lives and dies with class 1 and class 2 cannot stand by itself
Aggregation: class 2 is a part of class 1 but both have a separate life time
- Taxonomy of Architectural styles
Data flow architecture
Data centered architecture: A data store will reside at the center of this architecture and is accessed frequently by the other components that update, add, delete or modify the data present within the store
Hierarchical architecture
Implicit Asynchronous communication architecture
Batch Sequential architecture
Pipe and filter architecture
Process control architecture
Applicable domain:
Control flow: The flow of logic determined by the current data status
Suit for large complex information system
Benefits:
Limitations:
Control flow is implicit
Easy to backup & restore
Scalability and reusability of agents (components): easy to add new components
Control flow is explicit
Reduce overhead of transient data between components
Mostly for embedded systems
Data store reliability and availability is very important
High dependency between data store and its agents (components)
Overhead cost of moving data on network on distributed system
Limits
Applicable domain
Data are batched
Each sub-system reads related input files and writes output files
Control flow: Clients control the logic flow
Benefits
Each sub-system can be a stand-alone program working on input data and producing
output data
Simple divisions on sub-systems
Data store is passive
Clients are active
Implementation requires external control
Does no provide interactive interface
Concurrency is not supported and hence throughput remains low
High latency
Applicable domain
Data store is active
Clients are passive
Suitable for solving open-ended and complex problems (AI)
Exhaustive searching is impossible and impractical
Applicable Design Domain
Benefits:
Scalability: easy to add new knowledge source
Whenever the system can be broken into a series of
processing steps over data streams
Whenever the data format on the data streams is
simple and stable
and easy to be adapted if it is necessary.
Concurrency: all knowledge sources can work in parallel
Reusability of knowledge source
Benefits
Concurrency
Reusability
Modifiability
support experimentation for hypotheses
Limitations:
Simplicity
Flexibility
Tight dependency between the blackboard and knowledge source
Limits
Not suitable for dynamic interactions
Difficult to make a decision
Low Common Denominator
Difficult to configure a P&F system dynamically
Synchronization of multiple agents is an issues
Debugging and testing is a challenge
Main subroutine architecture
Buffered
Non buffered
Master-slave architecture
2 partitions:
Event sources
Event listeners
Layered architecture
Virtual machine architecture
Applicable domain
Interactive GUI component communication
Integrated Development Environment (IDE) tools
Applications that require loose coupling between
components
Implementation of state machine
When event handlings in the application are not
predictable.
Benefits
Framework availability
Reusability component
System maintenance and evolution
Independency and flexible connectivity
Possibility of parallel execution of event handlings
Limits
Difficult to test and debug the system
The event trigger cannot determine
Tight coupling between event sources and their listeners
Reliability and overhead of indirect invocations may be an issue
3 partitions:
Message producers
Message consumers
Message service providers
click to edit