Components and functions of UML

[NatureAddicted]

I have found some information related to the UML over here, while searching on Google, so thought to post here my query. Please provide some detailed information about the components and functions of UML. It would be better if you explain me about identifying components. I hope that you will help me too.

[Benito]

To identify components of the system is gradually broken down completely and produces a hierarchical tree of components. Thus, the considered system may be composed of subsystems, which in turn consist of individual segments. Up to what level you should drive the decomposition is, in principle, easy answer: It is important to find components, not their implementation, the realization of other components affected. An exception is, of course, the interfaces of the components. As a boundary condition applies here, of course, that you find for the components of the lowest level, a department or external suppliers who can develop this component for you. A criterion for the structuring of the system at higher levels may be the spatial arrangement of the system components. If the system as of several separate components, so they form the first hierarchical level in the analysis of the components. Also known from the software architecture principles are used for cutting components to bear. These are, for example, high cohesion, low coupling, or a small number of components.

[Quattro]

To represent the system components are used as the notation means the UML components. These can be classified further by the so-called stereotypes that information is provided in brackets. Thus, for example, the distinction between logical, that is, grouping components or hardware and software components of the stereotypes <<logical>>, map <<HW>> and <<SW>>, or as a further possible distinction <<HW electronics >> and <<HW-Mechanic>>. The choice of stereotypes tends often to the specifications of your project. Thus, in V-model-based projects of the stereotype <<logical>> often differentiated by the terms subsystem and Subsegement segement.

[afidelino]

In compiling the component hierarchy, top-down, bottom-up approach or middle-out. The latter means that we identify components on the middle levels of the hierarchy and then both downward and upward refinement concludes. In practice it is rarely followed strictly a method, but changes between all three methods. It is, however, especially at the beginning of new developments usually the top-down approach in the foreground. A point is reached where a further breakdown of a hard component, one should first define its tasks. This additional knowledge of the component is a good basis for further action with respect to their decomposition. Precisely in the context of new developments this iterative approach is useful.

[Arumugan]

After the components were identified, one has to think about what roles they will play in the future system. Therefore, the second job working within the system architecture in order to define the functions of components. Already in the system analysis, possibly in the form of system use cases and their refinements, the requirements and desired functionality of the system were developed. The challenge now is to distribute these requirements to the individual components, and thus express the components of role sharing. This approach also results in a criterion of how far you should drive the refinement in the systems analysis: A request should be further refined until the resulting requirements, clearly a component of the system are assigned. will be realized when deciding which task in which component to play the non-functional requirements such as reliability, time response, fault tolerance, etc. play an important role.

[Galbraith]

For these tasks now the formal requirements are determined on the components. This activity is equivalent to a conventional analysis of the individual components, similar to the system analysis requirements were elaborated on the overall system. For this reason can also use the known methods such as use case and their detailing. Just with the difference that now the whole system, but a component in the center of the analysis is. Therefore will appear in the use case diagram of a component as the system limit the considered component and the use cases of the component. The actors are formed by the neighboring components, which are involved in the processing of the components of use cases. As a starting point for the use-case analysis of a component, all previously assigned tasks are considered, this may be too new use cases and summarizes the use cases in detail further. There are of course in addition to the use-case analysis, the possibility of the (desired) behavior of a component by a state machine, or simply be described by natural language requirements.

[Jagruti23]

The UML offers different display options for interfaces. One is the interface classes. Here I create a class with the stereotype <<interface>>. The component that provides this interface is available, then connected via a <<realize>> relationship, which use components with a <<use>> relationship of this class. A shorthand notation is the notation "Ball & Socket". Here is the interface offered are represented by a ball (called the Lollipop) and the required interface of a semi-circle. In principle, should have every component in the component hierarchy interfaces to the abstract view to support the complete separation. If a component provides an interface, this does not necessarily mean that this interface directly implemented, are thus implemented as a piece of code needs. Take for example the interface of a component at the lowest level. Just this interface we want to make visible in the overlying component. In this case, interfaces are delegated to the top. This means that a component provides the interface of its sub-component is available, but not with spending for this interface. Thus in the example, the local control interface fully realized by the component buttons. The situation is different when a component grouping together interfaces of their subcomponents, a kind of facade forms. This also needs the overlying component part of the realization over it.