Though we can use UML notations for describing models, there is a need for a formal approach to specify architectured design.
Architectural description languages allow a formal approach by providing semantics and syntax for describing software architecture.
Goals of an ADL:
1. Allow the designer to compose the components of an architecture.
2. Allow integration of smaller components to obtain a large architecture.
3. Represent interfaces between blocks.
Using ADL allows effective assessment methods for architectures.
Transform flow:
1. As the name itself suggest, the data transformation takes place in the part of the analysis model approach.
2. It is just concerned to develop a model representing the flow of data from the external world to the internal world and then again shown in fig.
3. The figure clearly depicts that the data enters from an external world through keyboard etc and moves the data via pah called incoming flow.
4. In this path, the data is converted into an internal form.
5. The transforming center is the part of the kernel of the software where this data is processed.
6. The output produced is moved through an outgoing flow path to the external world again.
7. This is called transformation flow itis a small segment in data flow diagrams.
8. Transaction flow has its roots from transforms flow.
9. It can be said that transaction flow occurs at the incoming low path to the outgoing flow path in the transform flow.
10. Mapping as said before is a process of translating an analysis model especially DFDs into an architectural type.
11. Transform flow shown in the section is the DFD segment which can be converted into a specific architectural style through transform mapping.
12. It is a step-by-step design procedure for conversion.
13. Information flow is often characterized by a single data item called transaction that triggers other dataflows along one of many paths.
14. Transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction.
15. Within a DFD for large systems, both transform and transaction flow may be present.
16. Transaction mapping is illustrated using the user interaction subsystem of the safe home software.
17. User interaction subsystem is selected particularly for transaction mapping because, if we observe level 2 DFD, the data object user commands flow into the system and has three action paths.
18. Based on the command type an action path is selected.
19. Here invoke-command processing act as a transaction hub hence, it is a transaction flow process.
20. The design steps of transform and transaction mapping are similar but transaction mapping differs in the mapping of DFD to software structure.