5.26. KobrA - Vending machine UML diagram
6.1.17. Behavioral specification of the Vending machine in the form of a state transition
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.
7.2.11. Containment hierarchy for the CashUnit
7.2.12. Component Of The Shelf
COTS component integration
• An existing component can be reused easiest, when the specifications are equivalent, so the specifications of the required component and selected components for usage are equivalent.
• The left side of the next figure shows that general case, when user does the development using these considerations.
• Opposite to the left side of the figure, the right side shows that case, when there is a syntactic and semantic difference between the required and provided interfaces.
7.2.13. Custom-designed vs. third-party component integration
7.2.14. Component Of The Shelf
Conformance map
• The conformance map helps the integration of the components, which
• describes the visible properties of a COTS component by a projection, which defines the relation between the notations used at the COTS component development and the notations used by us.
• This projection can only be applied, if the information is correct and total in about the structure, behavioral and functionality in the documentation of the component, that is being reused.
• These information usually exist for a component, but the information can be split in a distributed system, so it is often hard to collect it and define the projection.
• It can be deciced, whether a component fits to our needs only, when the conformance map can be assembled and the interfaces are comparable.
7.2.15. Component Of The Shelf
Semantic map
• If we decide to reuse a component after the conformance map is assembled, then the next step is to create the semantic map.
• The semantic map concentrate on the similarities and differences of the two components (the designed one and the reusable one) and try to model the projection between the two different interfaces.
• In practice, it is a specification of a wrapper component, which encapsulates the COTS component.
• In general case, this component is called adapter and it can be defined using the development principles of KobrA.
8. 8 System development from "Off the shelf"
components
evelopment
8.1. 8.1 Components of the Shelf
8.1.1. Components of the Shelf
Motto "The food is organized so great that somebody must have touched all of it".
(Julia Child, The modern kitchen art)
8.1.2. Components of the Shelf
Components of the Shelf
• Nowdays, the "of the shelf components" are getting into foreground when complex systems are being developed.
• Main reasons:
• Economy The final product costs less time and manpower, so less money.
• Lack of expertise The specialization is so high at each scientific scope that it is difficult and expensive to employ the corresponding experts.
8.1.3. Components of the Shelf
Concept
• COTS means a software bundle, which has large functionalities and it is easily accessable.
• The interior parts remain invisible, only its functions and its interfaces are public.
• We have to keep in mind that the components are probably created not to our problem.
8.1.4. Components of the Shelf
Consequences
• COTS components are changing not only the process of software development, but also embodies architectural (and quality) constraints.
• The "architect" should be sure that the constraints are acceptable and they not lead to incompatibilities.
• In this lecture we will inspect how the ready to use components are affecting the architecture of the designed system.
8.1.5. 8.1.1 Example
8.1.6. Components of the Shelf
Example
• Quack.com is a company, that is specialized to provide content and business services through telephones.
• The example illustrates the usabilities and limits of the "of the shelf" components.
• There were already other companies developing the same services (with better financial background), so Quack.com had the only chance that they release their product first.
8.1.7. Components of the Shelf
Example - cont.
• They browsed among the existing (relevant) "off the shelf" components and they saved a lot of time. In some cases, more than one company offered components to a given function.
• The strategy worked, they released the product first and the AOL bought it. To deal with the increasing load (influenced by the increasing amount of customers), they have rewritten some components on the fly, where it was necessary.
• The flexibility of the architecture made it possible to replace components easily, but it was questionable how components are reacting.
8.1.8. Components of the Shelf
Example - cont.
• One of the developers said:
• When a function was not significant, we used COTS.
• When we found that our system should follow a standard, then we also used COTS there (because the solution on the market should exist).
• When we were uncertain about the reliability or the quality of a component, then we created it.
8.1.9. Components of the Shelf
Disadvantages
• COTS does not allow for developers to fully control the whole system.
• The "contract" concept of Bertrand Meyer eliminate this disadvantage.
8.1.10. 8.1.2 Effects of the components 8.1.11. Components of the Shelf
Effects of the components on the architecture Assume that we have to create a software which checks the processes of a chemical firm. The states of the chemical processes are interpreted by sensors and the information are transmitted to a special display of the operator. One of the software functionality is to draw the models of the methods onto the display. A software company offers a component, which implements this drawing functionality. We buy this product, but later becomes clear that the modul exists only in VisualBasic language.
8.1.12. Components of the Shelf
Effects of the decisions on the architecture
• We may need to reimplement the complete system in VisualBasic, because the component uses VisualBasic specific functions to control the drawing. An other possibility to detach the complete operator part from the other parts of the system.
• It is a basic structural decision, which is caused by a small selected component.
8.1.13. Components of the Shelf
Disregardness
• Even a simplest component has a kind of architecture inside, and it can be disregarded really difficult.
• E.g. an HTTP server assumes a client-server architecture with well-defined interfaces and in the background some functions.
8.1.14. Components of the Shelf
Consequences
• The interactions of the components are really important to understand them, before the architecture becomes fixed.
8.1.15. 8.1.3 Architectural differences
8.1.16. Components of the Shelf
Architectural difference - 1.
• Not all the components can cooperate, even if they are commercial products and the manufacturer stands that
• Not all the components can cooperate, even if they are commercial products and the manufacturer stands that