Structure describes a software system in different contexts. There are three structures: Module structure, Component-and-connector structure (CNC from here on), Allocation structure. Module structure describes static structure of the software system, while CNC structure describes runtime structure. Allocation structure is an add-on to either Module structure or CNC structure.
Structure itself is a concept and we don't really have a specific diagram for it. View is a diagram of a structure. When we describe a view (diagram), we are generally drawing a kind of a 'graph', each node being an element, and each connection being a relation.
1 Module structure views
Describes static structure of the software system.
Static structure is concerned with code and implementation (that is, prior to runtime) as an element, and naturally, it's helpful in understanding and reasoning about modifiability of the software system, since modifiability is evaluated in terms of code.
1.1 Examples of views
- Decomposition view: Modules are decomposed into smaller modules recursively until each module is small enough to be understood
- Uses view (no diagram supplied here): A uses B kind of diagram
- Class view: shows inherits from, is instance of kind of relationship between classes
- Data model view: ER diagram (database)
1.2 Why useful?
What we can understand is what code contains, where functionalities/interfaces are located at, and how they depend on each other.
We can understand:
- Module's public interface (functional responsibility)
- elements the module uses or can use
- generalization/inheritance (how modules are related)
1.3 Diagrams
Press the button to see diagrams
2 CNC structure views
Describes data flow at runtime, and it's useful in considering security, as it looks at the locations of data transmission and which entity data is going to/coming from.
2.1 Examples of views
Service view: how components interoperate with each other with public interfaces (services); what components there are at runtime (there can be multiple instances of server and client).
Concurrency view (no diagram): shows resource and processes that acccess the resource, so we can see possiblities of resource contention and opportunities for parallelism.
2.2 Why useful?
We can understand system at runtime. For example, we can identify resources that are accessed at runtime, how system is replicated (multiple instances of server class, for example). How data flows, what parts can run in parallel, how structure can change at runtime and how. What are executing components (proceeses) and how they interact at runtime.
2.3 Diagrams
Press the button to see diagrams
3 Allocation structure views
Describes software system that interacts with external entities (or which external entities each element in software system is abstractly contained in). This is more of an add-on to existing Module or CNC structure views. External entities include server where a subsystem is contained in, file system that something is contained in, CPU allocation et cetera.
Naturally, it helps us reason about security (from knowing which entities software entities interact with), performance (CPU / memory allocation, how many processes are in the server), availability (from knowing
3.1 Examples of views
Deployment view: shows where each component in software system is allocated. Helps reason about performance, security, availability. We can check bottleneck to improve performance (see two diagrams).
Implementation view: how software elements are mapped to the file structures/processor in the system's development, integration, configuration, control environments. (not really sure what this means - where's the file structure?)
Work assignment view: assigns responsibility for implementing and integrating the modlules to the teams who carry it out.
3.2 Why useful?
- What processor ('file structure') does each software element execute on?
- In what directory or files is each element stored during development, testing and system building?
- what is each development team in charge of?
3.3 Diagrams
4 Questions
Here, we consider how we can generate views to evaluate a design. We outline thought processes that go into this too.
4.1 Modifiability before runtime (uses view)
Q: In order to determine whether or not an architecture meets modifiability scenarios relating to change of functionality, what kinds of software elements should be considered?
A: This is about code, before runtime. => use modular structure (section 1). Uses view can be quite useful, as it helps us look at dependencies and do impact analysis (what 'impact' change in code brings). This change can be refactoring method, or change in interface. We may identify other places to change.
4.2 Modifiability at runtime (services view, concurrency view)
Q: In order to determine whether or not an architecture meets modifiability scenarios relating to change run-time performance behavior, what kinds of software elements should be considered?
A: This about performance, so we consider resource contention between processes and deadlock possibility. => this is about concurrency (process) view (CNC structure view). There can be other answers here too. (services view)
4.3 Determine what things to run on the same machine (deployment view)
Q: In order to determine which things to run on the same machine, what kinds of relationships should be considered?
A: Allocation view (deployment view) - hardware, processors, and what physical unit to allocate components on.
4.4 Security goal (deployment view, CNC structure views, decomposition view, assignment view)
Q: In order to determine whether or not an architecture meets its security goals, what kinds of relationships should be considered?
A: For security, possible views to consider:
- Deployment view: shows outside connection to other units, helps us to identify vulnerable links
- CNC structure views (in general): show dataflow, helps us to see important information flows (no encryption -> security risk)
- decomposition view: where security concerns are located (which module is in charge of security) - we can then ask if that's enough
- assignment view: who are responsible for developing sensitive components, whether that development team has expertise in security
'2021 > October 2021' 카테고리의 다른 글
| CSS man you are pretty cool (0) | 2021.10.22 |
|---|---|
| Link layer packet (frame) transfer (0) | 2021.10.12 |
| Link layer Error Detection Code (EDC) (0) | 2021.10.10 |
| Hierarchical routing (iBGP, eBGP, OSPF, RIP) (0) | 2021.10.09 |
| Client and server architecture (0) | 2021.10.09 |
