5.26. KobrA - Vending machine UML diagram
5.28.29. KobrA - Component meta-model diagram
5.28.30. KobrA - Environmental map
KobrA method
• KobrA method consists of two important parts:
• the component specification and
• the component implementation.
• Next time, these topics will be discussed.
6. 6 KobrA - Component specification and implementation
6.1. 6.1 Component specification
6.1.1. 6.1.1 Component specification 6.1.2. Component specification
Component specification
• The component specification is a collection of such descriptive documents, those define the functionality of the component.
• Each document analyze an aspect of the component functionality and concentrate only on what the component does.
6.1.3. Component specification
Component specification tools
• Tools of component specification
• Description in a natural language
• Graphical tool (UML)
• Formal tools
• like Object Constraint Language (OCL), which is defined in the UML, or
• QoS Modeling Language to specify the Quality of Service criterias.
• It does not matter, how it happens, the essence is to give a specification, which is complete as it can be, to be able to understand the behavior of the component in order to use that.
• Goal: describe the required and provided interfaces.
6.1.4. Component specification
Component specification tools
• The component specification contains all the information can be known about the component.
• The structural model gives an overview of the component structure and about the related components.
• The functional model describes the component functionality. Here should be defined the required and provided interfaces.
• The behavioral model defines the behaviour of the component. Here should be the pre- and postconditions given.
• The next figure shows a framework of a component specification. The framework contains further elements.
• Quality assurance plan
• A complete documentation of the component
• Decision model, which describes the built in variants of the component. These kind of variants are supported by the configuration interface (this will not discussed in details).
6.1.5. 6.1.2 Structural specification
6.1.6. Component specification
Structural specification of the component
• Defines the methods and attributes of the component, the relations to the other components (clients and servers), and finally, the constraints of the component connections.
• Formerly, software projects did not use usually the structural specification. It became useful, when the model controlled development is introduced.
• A useful tool to show the interactions of the component with its environment.
• It has great difference compared to the structural model, which was introduced at the topic of the environmental map. It focuses on the system, instead of the environment.
• The next figure shows the structural model of the vending machine component.
• A good structural specification gives tips about the decomposition possibilities.
6.1.7. Component specification
Example: Structural specification of the vending machine component
• Remember the structural model of the environmental map of the vending machine.
• Compare the two structural models.
• The abort method in the environmental structural model was defined alone. In the structural model of the component, abort is defined as a part of the SelectItem method.
6.1.8. Component specification
Comparing the structural models through examples
• The main difference is how the methods of the vending machine are defined. In the structural model of the component, the realization of the methods are explained more detailed.
• The abort method in the structural model of the environmental map is realized as an input parameter of the SelectItem method specified in the structural model of the component.
• To keep consistent the two structural models, we can go back to the structural model of the environmental map, and register the changes, or a comment can be left at the corresponding place.
• We can go back to an earlier model at any time to register the newer designing decisions.
6.1.9. 6.1.3 Operation specification 6.1.10. Component specification
Operation specification of the component
• The role of the operation specification is to define the effects of provided methods of the component, those can be seen from outside.
• The next table shows that template, which is offered by the KobrA method to this procedure (KobrA took this procedure from the Fusion procedure).
• The most important elements of the table are the Assumes and Result clauses, those are representing the pre- and postconditions of the methods. These are basically important at the validation of the methods.
• The pre- and postconditions are described in a declarative way, which means that it defines what the method does, while the question: how the method does that? is not answered here.
6.1.11. Operation specification template according to the KobrA method and
Fusion
6.1.12. Operation specification of the Vending machine
6.1.13. 6.1.4 Behavioral specification
6.1.14. Component specification
Behavioral specification of the component
• Object-oriented (OO) paradigm: as a first approach, data and functionality encapsulation.
• The object has states and state-transitions, those can be reached during the object life-cycle.
• The component paradigm encloses the principles of the object oriented technology, so it is based on these principles.
• Components may have states, or if it does not have any, then we can speak about a functional component, that does not have externally visible states and state-transitions.
6.1.15. Component specification
Behavioral specification of the component
• The behavioral specification shows, how the component reacts to the external influences.
• It is made as UML state diagrams.
• It concentrates on the Assumes and Result clauses, those are given in the operation specification.
• If a component does not have any states (a functional component), then the behavioral model is not needed.
• The behavioral specification describes the behaviors of the component by its externally visible states and an external event caused state-transitions.
• A component may react to an external event in several ways based on its state.
• A transition or a state-transition is caused by an event, which is mostly a message arrived to the component. A transition may have a guard, which should be true, if a transition is executable.
6.1.16. Component specification
Behavioral specification of the Vending machine
• The next figure shows the specification of the vending machine on an UML state-diagram.
• The table following the figure lists the corresponding states.
• The diagram and the table has more or less the same information. The diagram can be understood more easily, while the table can be easier processed automacally.
6.1.17. Behavioral specification of the Vending machine in the form of a state transition table
6.2. 6.2 Component realization
Component realization
6.2.1. 6.2.1 Component realization 6.2.2. Component realization
Component realization
• The component realization is a set of documents, those describe how to realize the component.
• It contains everything that is needed to do the specification based implementation.
• The higher level components can be realized using lower level components. These lower level components act like servers to the higher level components.
• The realization contains
• the subcomponent specifications, the required interfaces and
• its realization, which is the externally non-visible (private) part of the implementation.
6.2.3. Component realization
Contents of documents of Component realization
• UML class and object diagrams, describing the structural model of the internal structure of the component.
• Specification of the algorithms of the component, as UML activity diagrams.
• UML sequence diagrams, describing the interactions of the component with the other components.
• The next figure shows an UML description of a component realization.
6.2.4. 6.2.2 Structural specification 6.2.5. Component realization
Structural specification of realization
• The structural specification of realization describes
• that kind of class types and their relations (UML diagrams), from the component is built, and
• the internal architecture of the component.
• The component we focus on in the class diagram, is labeled with "subject".
• The next figures show the realization of the VendingMachince component as an UML class diagram.
• The UML diagram represents the internal structure of the component.
• The structural model of realization is tipically a refinement of the structural model of the specification.
6.2.6. Component realization
Structural specification of realization
• At the level of realization some new elements are shown, those could not be seen at the level of specification, because they did not have meaning there.
• On the previous figure, some classes can be seen, those are
• not components, but classes representing the objects of the real world (e.g.: Timer) and
• subordinated objects, labeled as "Component".
• We may need the list of the sold items, and the list of the items can be sold. Because we want to represent the reality, it is an important part of the embedded system. The length of the list depends on the size of the dispenser, so a dependency relation is introduced on the diagram, pointing to the dispenser.
6.2.7. Component realization
Structural specification of realization
• We may also need a list of the possible coins, those can be accepted by the CashUnit.
• It can depend on the type of the CashUnit.
• The CashUnit comes from an external service.
• We can start to define the interface of some subcomponents, but it is a strongly iterative procedure, and it heavily depends on the third-party's component implementations.
• If we know the selected and implemented component, we can change the required interface of our component respectively.
• Some interactions among the components are discussed in details, while the others are not so specific.
6.2.8. Component realization
Structural specification of realization
• The definitions of the formerly shown figure can be refined in the following iterative way, depending on that the sight will be clearer according to the realization.
6.2.9. 6.2.3 Realization algorithms 6.2.10. Component realization
Specification of the algorithms of realization
• The methods of the component are specified in details.
• Activity diagrams are created, with algorithms can be described. With the help of these diagrams the specified methods can be implemented.
• The next two figures show the UML activity diagrams of the insertCoin and selectItem methods.
6.2.11. 6.2.4 Structural specification 6.2.12. Component realization
Structural specification of realization
• Compare the activity diagrams of the defined SelectItem and PurchaseItem methods.
• The SelectItem method introduces in a different and more detailed way, how the user select the item.
• The PurchaseItem provides more information for the user (about what happens), while the model of the SelectItem algorithm also defines the internal parts of the method, and also discusses how happens that.
6.2.13. Component realization
Structural specification of realization
• Some activities will be refined later, depending on how the collaborating components are concretized.
• E.g.: we are waiting for a sign, but the form of the sign is not defined.
• These are handled in private functions and are embedded into further models, e.g.: into the model of the structural realization and they are defined there similarly.
• How can we give a realization of the components in e.g. Java? This kind of modeling is early at this level, because later we may find some components, those are implemented in a different language. This case will limit the component reusability then.
6.2.14. 6.2.5 Specification of realization interaction 6.2.15. Component realization
Specification of realization interaction
• The models of the realization specification introduce the progress of the control, from the view of some components.
• The interaction diagrams describe, how the groups of the component instances are collaborating in order to realize a function or a part of it.
• The next two figures show the UML collaboration diagram of the VendingMachine.insertCoin and VendingMachine.selectItem activities.
• For a low-level activity, it is not necessary to create all the activity and interaction diagrams.
6.3. 6.3 Summary
6.3.1. Summary
Summary
• We created the models of the top-level.
• We have concrete ideas about some subsystem, while we have less concrete ideas about the other subsystems.
• In the next steps
• we will searching for existing components, those are fulfilling our requirements, and then
• integrate them into our system.
• It fits to the embodiment step.
7. 7 KobrA - Component embodiment, Normal Object Form
7.1. 7.1 Component embodiment
Component embodiment
7.1.1. Component embodiment
Component embodiment
• Component embodiment is the name of those activities, which lead from an abstract specification to a more concrete component, e.g. an executable or an installable component.
• At the top abstraction level, KobrA method handles the system as a single component.
• This top level component is decomposed into sublevel components, following the decomposition and concretization dimensions.
• Finally, the executable binary code is created.
• The next figure shows how this procedure works.
7.1.2. Component embodiment
7.1.3. Component embodiment
Component embodiment
• The steps of the procedure can be automatized, e.g. a source code given in a high level programming language can be transformed into a binary code automatically by the compiler.
• The activity of transformation of a model into a program source code tipically requires a human, manual activity. The reason is that there is a big gap between the semantic descriptions of the model and the program source code (notations and their semantics are changing).
• The transformation
• input: UML diagrams
• output: program lines.
• This transformation is presented on the next figure.
7.1.4. Refinement and translation (Manual Translation) in a single step
7.1.5. Component embodiment
Component embodiment
• This information gap can be bridged so that the notions of the model are transformed to the notions of the selected programming language.
• It is easier for the object oriented programming languages, because these are supporting most of the UML notions.
• This gap can be bridged more difficult using traditional procedural languages.
7.1.6. Component embodiment
Component embodiment
• Doing manual transformation, such decision should be made often, those lead to a state, where the created software differs from the model.
• This fact undermine the legitimacy of the model based approach. The reason is that the design procudere is made on the top level, which is a draft of the system and the implementation decisions are made based on this draft.
• This situation is getting worse by the decisions, those are usually not documented in the higher level models.
• In the following a solution is shown, which fill this gap.
7.1.7. Component embodiment - SORT technique
SORT technique
• Users of the KobrA method mainly use the Systematic Object-Oriented Refinement and Translation (SORT) technique at this phase of the embodiment.
• SORT technique is based on two basic principles:
• the refinement and compilation should be strictly separated and distinguished.
• use the Normal Object Form (NOF) implementation profile to minimize the information gap between the object-oriented models and the given object-oriented being created program.
7.1.8. Component embodiment - SORT technique
Refinement and compilation
• The refinement is a relation between two different description of the same thing. More exactly, the refinement is a more detailed description of the same thing on a different level.
• The compilation is a relation between two different description at the same level.
• Mixing these two approaches in the software development project lead to an over-complicated representation of the system. In worst case, the final system does not fit to the model.
• The refinement and the compilation should be handled separately, like unique activities, as shown on the next figure.
7.1.9. Refinement and translation in two separated steps
7.1.10. Component embodiment
Component embodiment
• Phylosophy: in the first step, refine the models into models in a previously defined level, and in the second step transform these models into source codes.
• A potential problem may occur. How to define that level of detail, which is fine enough to start the transformation and get the source code?
• This problem can be solved using implementation patterns.
• Such implementation pattern is the Normal Object Form (NOF).
7.2. 7.2 Normal Object Form
Normal Object Form
7.2.1. Normal Object Form
Normal Object Form
• UML profiles can be defined upon several motivations.
• Testing profiles
• Implementation profiles
• E.g. the Java implementation profile describes the standard language elements of Java in UML.
•
• NOF is an implementation profile, which projects the UML to the basic (core) notions of the Object Oriented languages. Later, this core-description can be refined to each programming language, like Eiffel.
7.2.2. Normal Object Form
Elements of NOF
• A subset of UML, which can model the elements of the implementation level.
• Such new modeling elements, those are based on UML stereotypes.
• Constraints on the existing and new modeling elements.
• NOF models are valid UML models. The difference is that UML models are only close to the Object Oriented concepts, while NOF also supports the model based designing of the written Object Oriented programs.
7.2.3. Normal Object Formt
Usage of NOF
• NOF models give a graphic representation of the OO programs. These representations are close to the form of the source codes, so they can be automatically transformed to the given programming language.
• NOF supports well the model controlled, architecture based software development concept of the Object Management Group.
• Literature
• C. Bunse and C. Atkinson. The normal object form: Bridging the gap from models to code. In 2nd International Conference on the UML, Fort Collins, USA, 1999.
7.2.4. SORT
The advantages of SORT
• The Systematic Object-Oriented Refinement and Translation (SORT) technique greatly improve the process of embodiment, when followings are satisfied:
• Do only small steps
• A sequence of smaller steps can be understood more, than a big, complex step.
• The SORT technique makes possible to split the implementation of the graphic model into a sequence of refinement and traslation steps.
7.2.5. SORT
The advantages of SORT - cont.
• Separate the problems
• developers should concentrate on only one task
• doing so, the refinement steps preceding the translation, can be found easier.
• Identify and use the similarities
•
• SORT supports the creation of different implementations.
• Creating a new implementation is usually a difficult task. SORT reduces greatly this difficulty, because developers only need to retranslate the previously created model (in NOF form) of the component.
7.2.6. Component embodiment
Component reusage
• Component reusage represents activities close to the composition/decomposition and abstraction/concretization dimensions.
• A reused component usually not exactly fit to the specification.
7.2.7. Component embodiment - Component reusage
Possible solutions to component reusage
• Change the model to eliminate the differences
• It is not intended, while its concept is the opposite of the component based software development concept.
• Rewrite/modify the reused component
• Not a good idea, because it is too complex and sometimes impossible.
• Introduce an adapter component, which projects the interfaces onto each other
• Usage of wrappers
• Several component techniques have services, called syntactic projections.
7.2.8. Component embodiment
Semantic projections
• The real solution is the semantic projection between the entities, those are in relationships.
• Semantic projections translate the thinks of a component to a form, that can be understood by the other component.
• The name of this kind of wrapper component is glue code, which usually encloses a server component into a unit.
7.2.9. Component embodiment
Creation of a new component
• If the corresponding component could not found, then it should be made by us.
• In this case, further decomposition steps are needed to find the fitting implementations.
• After this, we can step back again to the integration step to integrate the newly implemented components.
7.2.10. Component embodiment
Example - CashUnit
• Assume, that we did not find a corresponding component on the market for our vending machine, which can fulfill the requirements and play the role of a properly working CashUnit.
• In this case examine, whether we can find such components on the market from we can build our CashUnit component.
• Assume, that we found four components on the market, from those the CashUnit can be built (see next figure).
• The next figure shows only those parts of the vending machine, those are involved at this design refinement step.
• To develop the CashUnit component, the same development steps should be made, those are also performed to the VendingMachine component.