Modelling your application architecture
During the process of architecting your application, you will create models to visually describe your overall structure and behavior of your application. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. A model is an abstract representation or simulation of a "system" that provides a complete description of the system from a particular perspective.
The purpose of a model is to reduce the ambiguities that occur in natural-language descriptions, and to help you to visualize the design and to discuss alternative designs. A model should be used together with other documents or discussions. By itself, a model does not represent a complete specification of the architecture.
The application architecture will be revealed and discussed using various views, each of which models the system with different perspectives and emphases:
The central views of an architecture model are the component diagrams that show the major components of the system and how they interact with one another to fulfill requirements. If the system is large, each component might have its own high-level design that shows how it is composed of smaller components.
A typical component diagram for a large system might include components like these:
Within each component, you can show its sub-components as Parts. A Part is effectively an attribute of its parent component, which is much like an attribute belongs to an ordinary class. Each part has its own type, which is usually also a component. You can place this component on a diagram and show its parts. It is useful to apply this technique to the whole system. Draw it as a single component, and show its major components as parts. This helps you identify clearly the interfaces of your system with the external world.
When your design for a component uses another component, you frequently have a choice about whether to represent it as a part or as a separate component that you access through a required interface. The major recommendations are as follows:
Use parts in the following situations:
Use separate components accessed through required interfaces in these situations:
The use of required interfaces is usually preferable to the use of parts. Although the design can take longer, the resulting system is more flexible. It is also easier to test the components separately. This allows less coupling in their development plans.
By placing interfaces on your components, you can separate and name the major groups of operations that are provided by each component. For example, components in a web-based sales system might have an interface through which customers buy goods, an interface through which suppliers update their catalogs, and a third interface through which the system is managed.
A component can have any number of provided and required interfaces. Provided interfaces show services that the component provides for other components to use. Required interfaces show services that the component uses in other components. Examples include a user interface, a Web service, a .NET interface, or a collection of functions in any programming language.
If you define both provided and required interfaces, this helps you separate the component cleanly from the rest of the design, so that you can use these techniques:
An operation in an interface can represent any way in which a behavior of a component can be invoked. It might represent a Web service request, a signal or interaction of some other kind, or an ordinary program function call. To determine what operations to add, create sequence diagrams to show how the components interact with one another. Each of these sequence diagrams shows the interactions that occur in a different use case. In this manner, you can gradually add to the list of operations in each component's interface, as you explore the use cases.
In addition to the components themselves, you can show the dependencies between them in the component diagram. A dependency arrow between two components shows that changes in the design of one could affect the design of the other. This usually happens because one component uses the services or functions that are provided by the other component, either directly or indirectly.
A well-structured architecture has a clear arrangement of dependencies, in which these conditions are true:
You can show dependencies directly between components, or you can show dependencies between required and provided interfaces that are attached to the components. By using interfaces, you can define what operations are used in each dependency.
Typically, dependencies are shown between components when the diagrams are first drawn, and then replaced by dependencies between interfaces as more information is added. Both versions are correct descriptions of the software, but the version with interfaces provides more detail than the earlier version.
Managing dependencies is most important for the production of maintainable software. The component diagrams should reflect all the dependencies in your code. If the code already exists, make sure that all the dependencies are shown in the diagrams. If the code is being developed, make sure that it does not include dependencies that are not planned in the component diagram. To help you discover dependencies in the code, you can generate layer diagrams. To help you ensure that your planned dependency constraints are met, you can validate the code against layer diagrams.
© 2020 Digcode.com. All rights reserved.