1. Code Architecture View
ZHAO Jianhua
Dept. of Computer Sci&Tech
Nanjing University

2. Introduction
The code architecture view describes how the software implementing the system is organized.
Source components implement individual elements in module view
Deployment components (executible, libraries, …) instantiate runtime entities in the execution view.
Describe how these components are related to each other through intermediate components.

3. Introduction(2)
How all of them are organized according to an organization’s particular development environment.

4. Introduction(2)
Describes the design decisions related to configuration management, multiple release, and testing.
affect the effectiveness of the development team because of their impact on: turnaround time for the edit-compile-test cycle.
The primary goal of the code view is to facilitate the construction, integration, installation, and testing of the system.

5. Introduction(3)
By having a separate code view, you can make the module and execution views independent of the programming language.
describe how a module, its interfaces, and its dependencies are mapped to language-specific components and depencencies.
Describe how source components and intermediate libraries are released to other teams for integration and testing.

6. Introduction(4)
Describe how much of a module’s functionality is implemented in each release.
the code architecture view is straightforward for simple examples.
the code view is complex and diverges from the module and execution views when
there are multiple executables, shared components, a large team, or concurrent development,

7. Introduction(5) The code view organizes code components to support
Daily concurrent development tasks of developers
Constructing or building parts of the system and releasing them to different teams
Ease of maintenance or change.
Enforcement of architectural design decisions
Configuration management of different versions of the system.

8. Introduction(6) A good design of the code architecture view
preserves architecture design decisions.
streamlines development activities,
integrates smoothly with the development evironment.

9. Introduction(7) Input: Should also consider:
module view, execution views
Should also consider:
implementation language,
development tools,
development environment
development process

10. Design Activities for the Code Architecture View
Global Analysis
Central design tasks
source components
deployment components
intermediatae components
global evaluation
Final design task
make detailed decisions related to the build procedures and configuration management.

11. Code Architecture View Design tasks
Execution view
Conceptual View
Module View
Central
Design
Tasks
Central Design Tasks
Code View
Central Design Tasks
Final Deisgn Tasks
source comp.
deployment component
Global Analysis
build proc.
Intermediate component
global evaluation
conf. manag.
Figure 7.1, PAGE 161

12. Global Analysis(1)
Start by reviewing the global analyses performed for the module and execution views.
To see whether they put additional requirements or constraints on the design of this view.
Develop strategies to address these requirements or constraints.
Consider factors related to the development platform, environment, process, and schedule.

13. Global Analysis(2) For development environment,
list the capabilities of tools.
Configuration management,
whether necessary and/or feasible for cross-platform development.
For development process,
identify the process
and the testing requirements.

14. Global Analysis(3) With the development schedule
Whether the procuct will be released in stages.
Whether there are internal release
Whether developers and testers will be working on multiple release concurrently.
Whether multiply versions will be developed.

15. Global Analysis(4)
Consider the target platform and the target environment.
Analyze the support for installing the system on the target platform
Analyze whether there are limitations on the availability of the target platform or hardware.
Develop new strategies to take the advantage of the development environment while overcoming the limitations.

16. Central Design Tasks Source Components Intermediate Components
Deployment Components
Global Evaluation

17. Meta-Model Figure 7.2, Page 162 Conf. Description Source Component
Binary Component
Library
Executable
use at run-time
import
generate
link >
compile >
compile >
link >
Figure 7.2, Page 162

18. Source Component To design source components
Identify source components and map elements and dependencies from the module view to the source components and dependencies.
Organize the source components using storage structures such as directories or files.

19. Source Components Source components are language-dependent
C or C++: .h for interfaces, and .c or .cpp
Ada: package specification and implementation.
Other languages (IDL, …)
Two language-specific dependencies:
import: include relation in C or C++
generate: when a source component is generated from another one.
implement ?

20. Identify the source component
Elements from the module view are mapped to the source components.
The module and the interface: in C++, .h for interface and .cpp for module.
Different language has different map rules.
For larger, complex modules, the code may be distributed in several files.
For easier editing and rebuilding.
For reuse.

21. Organize the components
Development tools can help organizing the components.
For small systems, the organization can be very easy.
organize the components based on some criteria such as similarity of functionality, or developer responsibility.

22. Organize the components
For large system with concurrent development, we should consider
Ease of accessing interface components
Organizing related source components.
support the release process for the system
Should consider time for the edit-compile-link cycle if the time is hours or days.

23. Intermediate Components(1)
Including binary files, static library, and others generated by tools.
Identify intermediate components, and their dependencies on source components and each other.

24. Intermediate Components(2)
Organize them using storage structures, such as directories or files.
Intermediate components are specific to implementation language and environment.
Organize the intermediate components to facilitate sharing: for example, static libraries.

25. Deployment Components(1)
You should:
Identify and map runtime entities and dependencies in the execution architecture view to deployment components and their dependencies.
Organize the deployment components.

26. Deployment Components(2)
Including executables, dynamic libraries, configuration descriptions.
A configuration description describes processes and/or resources: data storage, shared memory.
executables and dynamic libraries are related to binary components by a link dependency.
Executables are also related to the dynamic libraries by a link dependency.

27. Deployment Components(3)
For large, complex system, the organization can be very complex
You may need to establish a separate file system for storage of data and for shared memory areas.
You may want to separately organize each executable and associated components such as required resources and test data.

28. Global Evaluation Criteria:
preserving the integrity of the architectural decisions.
streamlining the development activities
integrating smoothly with the development environment and external components.
consistency, simplicity, uniformity of your design decisions.

29. Final Design Tasks
Build procedure: the procedure for building and installing the intermediate and deployment components:
the components and dependencies identified during central design tasks.
The release process identified during global analysis.
and the design decisions related to configuration management.

30. Final Design Tasks
Configuration Management: determine design decisions related to management of versions and releases of components
design how the versions and releases of components and the system are managed.
reduce the complexities of managing multiple versions of source code and intermediate releases of parts of the system.

31. Design of Code View: IS2000 Global Analysis(1)
Review the global analysis
Analyze those factors relevant to the code architecture view.
Analyze those factors using the steps described in Chapter 3. Develop new strategies for code view.

32. Review Global Analysis
Relevant strategies
Issue: Easy Addition and Removal of Features
Separate components and modules along dimensions of concern.
Encapsulate features into separate components
Issue: Real-Time Acquisition Performance
Use flexible allocation of modules to processes
Issue: Aggressive Schedule
Make it easy to add or remove features.

33. Review Global Analysis(2)
For the first two strategies, we should design the components so that they can be linked to different executables without modification.

34. Review Global Analysis(2)
The third strategy means the modules assigned to processes or other runtime entities may change.
The forth strategy requires greater flexibility in the code architecture view.
A new strategy to support the third and the forth is separately organize the deployment components and the source components that are linked to them.

35. Analyze Factors The new factors are about development platform,
development environment,
configuration management tool,
release process,
testing process,
release schedule,
Implementation language.
code conventions.

36. New organization factors
Table 7.1, page 167.

37. New technological factors
Table 7.2, PAGE 169.
T3.5: Implementation language
C and C++ will be the implementation language.
T5.6: Coding conventions
Standard coding and naming conventions are required. Not defined yet.

38. New Issues and Strategies
Issue: Architectural Integrity
Architectural decisions and principles must be preserved and enfored in the code architecture. Their violation needs to be detectable.
Issue: Concurrent Development Tasks
Developers may be working concurrently on different component versions for multiple internal releases.

39. New Issues and Strategies
Issue: Limited Availability of Probe Prototypes.
The limited availability of probe prototypes will adversely affect the developers’ ability to test many components.
Issue: Multiple Development and Target Platforms.
The use of multiple development and target platforms must be considered and facilitated.

40. Issue card for Architectural Integrity
Influencing Factors: O3.2, T3.5, T5.6
Solution:
Making architectural decisions explicit in the code can go a long way toward detecting violations. There is tension between the goal to make editing more convenient by reducing the number of header files and between reducing compile-time dependencies by separating header files into public and private ones.

41. Issue card for Architectural Integrity(2)
Strategy 1:Preserve module view hierarchies
Reflect module and layer hierarchies explicitly in the code view by hierarchically mapping each layer and module into separate package.
Strategy 2: Separate organization of public interface components.
Organize public interface components in separate directories. Create a public interface package for each layer and subsystem.

42. Issue card for Concurrent Development Tasks
Page
Influencing Factors: O4.2, O3.4
Solution:
Make the different release of source components transparent to developers, and organize the released deployment components to reflect the execution view.

43. Issue card for Concurrent Development Tasks(2)
Strategies:
Separate organization of deployment components from source component.
Preserve execution view
Use phased development
Release layers through static libraries.
Related Strategies:
Use a flexible build procedure
Make it easy to add or remove features.

44. Issue card for Limited Avaliability of Probe Prototypes
PAGE 173
Influencing factors: O3.2, O3.3, O3.4, O4.3
Solution
Use a probe simulator while the probe hardware is not available and create flexible build scripts to use the simulator transparently.

45. Issue card for Limited Avaliability of Probe Prototypes
Strategies:
Develop and off-line probe simulator with an appropriate abstraction.
Use a flexible build procedure.
Related Strategies:
Separate and encapsulate code dependent on the target platform.

46. Issue card for Multiple Development and Target Platforms
PAGE 174.
Influencing Factors: T1.1, T1.2, O3.1, O3.2
Solution:
Create the source components to separate code dependent on the target hardware
Strategy:
Separate and encapsulate code dependent on the target platform.
Related strategy:
Use a flexible build procedure.

47. Central Design Tasks:IS2000
Source Components
Intermediate Components
Deployment components

48. Source Components(1) Start with the layers defined in the module view.
Apply the strategy Preserve module view hierarchies, each code group contains the set of related source components.
Apply the strategy Separate organization of public interface components, create a code group named ‘include’

49. Code groups Figure 7.3, Page 175 IS2000 IS2000 Source GUI Applications
Probe Service
Image Processing
Database Service
System Service
Include
Operating System
Error Handling
Figure 7.3, Page 175

50. Imaging subsystem use-dependencies
SImaging
MFramer
MImager
MPipeline
MPacket
MImageMgr
MAcqControl
MPacketMgr
MPaccketizer
MPipelineMgr
Figure 7.4, PAGE 176

51. Source Components(2)
Map some of the supporting modules and interfaces in the subsystem to source components.
Map the interfaces of modules of Simaging subsystem to respective language-specific components. Apply Separate organization of public interface components.

52. Source Components(2) Map the dependencies
import(include) dependency between public and private header files.
Import dependency between the modules and its interfaces.
Import dependency between the modules and the interfaces it requires.

53. Source components and dependencies for imaging subsystem
Figure 7.5, PAGE 177.

54. For modules Mframer and MImager
There are several instances of these modules.
We can map the individual instances of these modules to source components as we did earlier.

55. Organizing source components for the Simaging subsystem
Figure 7.7, PAGE 178
Applied strategy:
Preserve module view hierarchies
There are packages for Mpacket and Mpipeline. The source components common to their subcompositions are organized in these packages.

56. For ProbeService layer
Applied Strategy:
Develop an off-line probe simulator.
Mapping the interface of Mdatacollect to CDataCollect.h
Figure 7.8, Page 179.

57. Intermediate Components
Applicable strategies
Develop an off-line probe simulator
Separate and encapsulate code dependent on the target platform
Use pahsed development
Release layers through static libraries
Use the strategies to allow developers to work independently on the target and development platforms of their choice.

58. Intermediate Components(2)
Organize the .obj files into a separate subpackage for each target platform.
Allows a developer to change the target platform easily without having to recompile.
Create one static library for each of the OperatingSystem, ErrorHandling, SystemServices layers.(Release layers through static libraries)

59. Intermediate Components(2)
ProbeService offers two different library.(Develop an off-line probe simulator)
Offer five separate libraries for the ImageProcessing layer because Mpacketizer may be very large.

60. Deployment Components(1)
Executables, configurations, and resources.
For each process in the execution view, identify an executable in the code view.
The link dependencies of each of the executables to binaries and static libraries can be identified based on the modules assigned to the runtime entities.

61. Organization of executables for image processing
EPacketizer
EFramers
EImagers
EPipelineMgr
EFramer
EImager
Epacketizer.exe
Epacketizer.resources
ImageProcessing Pipeline Configuration
Figure 7.10, page 181

62. Deployment Components(2)
There is a package for each executable: executable, supporting files
Executables for different Eframer and Eimager processes are organized hierarchically.
The configurations for each of the possible pipelines are mapped to configuration files organized in the Configurations package.

63. Final Design Tasks
Build Procedure
Configuration Management

64. Build Procedure for IS2000(1)
Need to design a build procedure that builds the entire system or parts in an efficient manner.
The order in which derived objects are built or rebuilt.
How the dependencies are expressed in build scripts.
the installation procedures used to install and to organize deployment.

65. Build procedure for IS2000(2)
Use hierarchical build procedures to perform the required task.
May need a variety of build targets to rebuild a component, subsystem, or a layer for module testing, internal release, or release for a particular target platform.

66. Configuration Management
Design how versions and releases of components are managed.
Divide the intermediate components based on the source component they are derived
From source components developed by developers.
From source components developed by other team members.
Source components developed by other teams.

67. Configuration Management: IS2000
Strategy: Use phased development
Each team releases its components first internally for use by other team members.
Each release should be relatively stable to minize the effect of changes made by other developers.

68. Design Summary(1)
Identified source components corresponding to the elements of the module view.
Translated decomposition and use-dependencies among the module view elements to source components and dependencies among them.
Organized the source components into directoires.

69. Design Summary(2)
Identified all the components derived from the source components and organized them based on the release procedures and team organization.
Organized the deployment components.
Designed the build procedure and made several configuration management decisions.

70. Design Summary(3)
Table 7.3, PAGE

71. Summary of Code View Table 7.4, PAGE 185-186 Elements:
Source component
Binary component
Library
Executable
Configuration description
Code group

72. Summary of Code View Relation generate import compile link
use at runtime
trace
instantiate

73. Summary of Code View Artifact
Module view, source component correspondence.
Runtime entity, executable correspondence.
Description of components in code architecture view, their organization, and their dependencies.

74. Metal model for Code View
Subsystem
Code Group
Layer
Module
Interface
Source Component
Binary Component
Library
Executable
Configuration Description
g/i
Runtime Entity

75. Traceability
The following three items should be traceable in the code view:
Critical requirements and organizational and technological factors.
Elements in the module view
Elements in the execution view.

76. Uses for the code view
Tracebility to elements of the module and execution views.
Transparent access to all the components needed for a particular development task.
Building parts of the system
Managing versions and releases of components
Preserving architecture design decisions and detecting their violations.