3.25. Allocation structure
4.2.29. J2EE - Example for J2EE/EJB-compliant implementation
4.2.30. 4.2.7 J2EE - EJB programming 4.2.31. J2EE - EJB programming
EJB programming
• EJBs have connections only through the containers. If an EJB wants to reach a JDBC connection or an other bean, then it can be done throught the container.
• Beans can interact with a container
• with Callback methods, or
• through an EJBContext interface, or
• using Java Naming and Directory Interface (JNDI).
4.2.31.1. 4.2.7.1 Server side
4.2.32. J2EE - Creating a server side bean
Creating a server side bean
• Two interfaces should be defined, when the business methods are defined:
• Home - Instanciated from EJBHome. Contains methods to handle life-cycle: constructor, destructor, finding a bean-instance.
• Remote - Contains the business methods. If a client wants to call a method of these, a reference to the bean should be retrieved first through the Home interface. Client interacts with the bean always through the interface of remote. These methods are application specific.
• A bean class has to be written. It loads only, when it is needed. Functions contained in the interfaces are implemented here.
4.2.33. J2EE - EJB program units
[fragile]J2EE Example - A simple home interface
Creating a Broker type EJB
public interface BrokerHome extends EJBHome {
Broker create() throws RemoteException, CreateException;
}
[fragile]J2EE Example - Part of the Broker remote interface
public interface Broker extends EJBObject {
// Return the newly created account number
public int newAccount(String sub_name, String sub_address,
int sub_credit) throws RemoteException, SQLException;
...
public void updateAccount(int sub_accno, int start_stock_id) throws RemoteException, SQLException;
...
public Vector getHoldingStatement(int sub_accno, int start_stock_id) throws RemoteException, SQLException;
}
Part of the Broker remote interface Interface contains methods, used by the container, when that manages the creation and the life-cycle of an EJB. Programmer can provide a bean specific behaviour to the EJB, or it can inherit a default behaviour. After that, client can use the public interface of the EJB to create, manipulate or destroy beans.
4.2.34. J2EE Example - The realizer class
Realizer class
• The realizer class, which is known as bean class, instanciated at runtime, and can be reached as a distributed object. The next figure shows a simple client code.
• An EJB client can be a standard application, servlets, applets or an other EJB. Each client uses the home interface of a server bean in order to get a reference to an instance of the server bean. Then, client connects to the server bean via the remote interface, when uses its methods.
• In this example the Broker bean is a stateless session bean, which processes the requests of the client.
4.2.34.1. 4.2.7.2 Client side
[fragile]J2EE Example - A code of a simple client
Broker broker = null;
// Find home interface
Object _h = ctx.lookup("EntityStock.BrokerHome");
BrokerHome home = (BrokerHome)javax.rmi.PortableRemoteObject.narrow(_h, BrokerHome.class);
// Use the home interface to create the Broker EJB Object broker = home.create();
// Execute requests at the broker EJB broker.updateAccount(accountNo, 200000);
broker.buyStock(accountNo, stockID, 5000);
// We are finished...
broker.remove();
4.2.34.2. 4.2.7.3 Entity and Broker bean functions
[fragile]J2EE Example - An Entity bean, and a Broker bean function
public void updateAccount(int sub_accno, int sub_credit) throws RemoteException {
try {
Account account = accountHome.findByPrimaraKey(new AccountPK(sub_accno));
account.update(sub_credit);
Entity bean of the broker example
• The updateAccount method uses an entity bean called Account, which contains all the important functions of the application.
• The code of updateAccount uses a findByPrimaryKey method, which was defined in the home interface of the Account bean.
4.2.34.3. 4.2.7.4 Account bean, Home/Remote interface
[fragile]J2EE Example - Account bean - Home/Remote interface
public interface AccountHome extends EJBHome {
public Account create(String sub_name, String sub_address,int sub_credit) throws CreateException, RemoteException;
// Finds an account by its primary Key (Account ID)
public Account findByPrimaryKey(AccountPK key) throws FinderException, RemoteException;
}
public interface Account extends EJBObject {
public void update( int amount) throws RemoteException;
public void deposit( int amount) throws RemoteException;
public int withdraw(int amount) throws RemoteException, AccountException;
// Getter/setter methods on Entity Bean fields
public int getCredit() throws RemoteException;
public String getSubName() throws RemoteException;
public void setSubName(String name) throws RemoteException;
}
[fragile]J2EE Example - Account bean - update method
public class AccountBean implements EntityBean {
// Container-managed state fields public int sub_accno;
• The greatest attraction of EJB model is that the business logic and the technical parts of programming can be separated.
• Technical details are often solved by the container. To achieve this, beans should define, what they require from the container. These requirements are described in the deployment descriptors, which are contained in an XML file.
• Requirements are defined in a declarative way.
• Advantage: several descriptors can be given for the same bean, to change its functionality.
[fragile]J2EE Example - Broker bean - Deployment descriptors
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>EntityStock.BrokerHome</ejb-name>
<home>j2ee.entitystock.BrokerHome</home>
<remote>j2ee.entitystock.Broker</remote>
<ejb-class>j2ee.entitystock.BrokerBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
4.2.37. 4.2.9 Summary 4.2.38. Summary
Summary
• The EJB component model can be used efficiently after a few practicing, to create client/server applications.
• The EJB model gives the chance to apply different architecture schemas in the same application. It is hard to decide, which schema is the best to the given application.
• The interaction between the beans and the container is very complicated, which effects the performance of the application.
• Efficient and scalable EJB applications can be written only after a lot of practice.
5. 5 KobrA program-development model
Based on the book of Hans-Gerhard Gross: Component-Based Software Testing with UML. Springer-Verlag Berlin-Heidelberg 2005.
5.1. KobrA
Introduction
• Developed by Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany.
• A synthesis of more currenty existing component-based program-development model:
• OMT
5.2. KobrA
Introduction
• Goal: combine the strongnesses of the available methods and avoid their weaknesses.
• KobrA gives help to the activities (analysis, designing, programming, verification, documentation).
• The tool of the analysis and designing is the UML
• UML is a good choice, because modeling can be done without implementation or system specific considerations.
5.3. KobrA
Introduction
• The main goal is to create the abstract form of the basic structure of the system. Because of this, several implementation technology can be used.
• Principles:
• Separate problems
• Model based development
• Use of components
• Use of object oriented technology
• The figure shows that three dimensional model, which is suggested by the creators of KobrA.
5.4. 5.0.1 Development process
5.5. KobrA
5.6. KobrA
Development process
• KobrA divides the development process into two basic dimensions.
• All activities are rated in these two dimensions and analysed from this viewpoint.
• It defines four directions for the development:
• Composition / Decomposition
• Abstraction / Concretization
5.7. KobrA
Development process
• Composition / Decomposition
• Decomposition: Apply the Divide and conquer approach. It breaks up the system into flexible, independently managable parts.
• Composition: Assemble the system from the implemented parts.
• Abstraction / Concretization
• It goes from the model (which can be understood by the users) to the program (that can be executed on the computer).
5.8. KobrA
Development process
• One more dimension...
• Generalization / Specialization
• The job in this dimension plays role, when a complete product family is developed.
• The exact function of some components defines that which product (version) is discussed.
• This dimension is not discussed here to keep our model simple.
5.9. 5.0.2 Decomposition 5.10. KobrA
Decomposition - Vending-machine example
• Structure
• Vending machine
• Coin checker
• Button panel
• Dispenser / Change dispenser
5.11. KobrA
Decomposition - Vending-machine example
• In this case, the composition/decomposition is followed downward.
• During decomposition, we try to identify units, those are already implemented and reusable (or, if there is no chance to find those kind of units, we define them so that they will be reusable after implementation).
• The following figure shows the result of decomposition of the vending-machine problem.
5.12. KobrA - Vending-machine problem decomposition
5.13. KobrA
Decomposition
• The success of decomposition depends on the understanding of the problem.
• The goal is always to get reusable components during the decomposition.
• If it falls out of our sight, then each components should be reimplemented always, which gives nothing more, than a top-down method.
5.14. 5.0.3 Embodiment 5.15. KobrA
Embodiment
• During decomposition, each subsystem is identified and specified.
• The specification and implementation are handled separately.
• The specification contains the provided services, required by the user. It is described in a very abstract level.
• At the implementation level, the concrete implementation is given to the services specified in the user interface.
• The executable solution can be reached by starting from the UML model and going through the concrete representations. This process is called embodiment.
5.16. KobrA
Embodiment
• In the case of the vending machine, the process of embodiment is not only a coding (our machine can be seen as an embedded system). Embodiment here is also the decision of which parts should be realized by hardware and which ones by software.
5.17. 5.0.4 Composition 5.18. KobrA
Composition
• Some parts are implemented...
• ...others are reused.
• Now subsystems can be integrated into a complete system.
• This is an upward movement in the composition/decomposition dimension.
5.19. 5.0.5 Validation
5.20. KobrA
Validation
• Validation compares the implemented parts with the abstract model. This movement is realized in the abstraction/concretization dimension.
• It is not always the last task:
• It is not required to completely decompose a system to implement parts.
• An implemented unit can be validated immediately.
• If a unit depends on an other unit, e.g.: on a hardware, which does not exist yet, then it should be simulated.
5.21. 5.0.6 Spiral model 5.22. KobrA
Spiral model
• All the program development steps can be put into one of the dimensions. Activities are not always in the same order as suggested by the direction defined by the dimension.
• E.g.: decomposing a system, new elements can be identified. In this situation we face with an embodiment, a decomposition, a composition and a validation step.
• At least the embodiment can be made. The steps of composition and validation can be done at abstract level, in the UML model level.
• It means that the steps above are repeated in different levels - this is the key of the spiral program development model.
5.23. 5.0.7 Waterfall model 5.24. KobrA
Waterfall model
• Activites are done in a strict order.
• Spiral model fits better to the component-based software development.
• Waterfall model are useful for the traditional program development.
• The next figure shows the UML diagram of the vending machine. Each UML package symbol defines a set of model elements.
5.25. 5.0.8 Example
5.26. KobrA - Vending machine UML diagram
5.27. KobrA
Notations
• "Component" - a KobrA component
• "Variant" - it notes the fact that the component is a part of a product family
• Each "Variant" component may have a different implementation, depending on what kind of product should be made.
5.28. 5.1 Environmental map
5.28.1.
Environmental map
5.28.2. KobrA - Environmental map
Environmental map
• The starting point of the software development is the specification of the system or application.
• The specification is inherited and decomposed from the requirements. User-level requirements collected from prospective users by use case diagrams are also decomposed later.
• Descriptor data are collected by gathering information about the environment.
• The system or application specification should reflect to the requirements of the environment.
• The collection of the environment descriptor elements is called environmental map.
• KobrA method handles the environmental map the same as the components, while it is an independent component with its own rules.
5.28.3. KobrA - Environmental map - Example
Vending machine - Environmental map A part of the environmental map of the vending machine.
"Mechatronics" stereotypia denotes that the system is a combination of electronical and mechanical parts and a software.
5.28.4. KobrA - Environmental map
Note
• The KobrA style contain relation on the previous figure is an extension of a KobrA method, which is basically developed for embedded systems.
• This method is called as Marmot.
• The exact definition of the environment is always the first step in a development project.
5.28.5. KobrA - Environmental map
Environmental map
• The definition of the environment is the first step in a development project, where the following questions should be answered:
• What kind of activities are supported by the system?
• What is the input of the system?
• Who/what will be in relation with the system?
• What kind of objects are required from the system in order to perform other activities in the environment?
• This first step is well represented by the use case diagrams.
• The environmental map can be also created by other models: model of business or enterprise processes, structural and interaction models.
• Next figure shows the elements, those are creating an environmental map.
5.28.6. KobrA - Environmental map elements
5.28.7. KobrA - Environmental map
Environmental map
• As a result of the environmental map definition, the required interfaces of the whole system can be determined.
• If an existing component is found, which has a specification that satisfies the actual context, then it can be reused (so it is not required to reimplement it).
5.28.8. 5.1.1 Usage model
5.28.9. KobrA - Environmental map
Usage model
• It specifies the high-level relation of the system and the user.
• This model is a collection of use case diagrams.
• Usage models can be used to define the system modules at a very abstract level.
• Use cases are concentrating mainly on the interactions of the system components, and on the connections between the system and its boundaries.
• Use case diagrams introduces the actors of the system and the use cases, and the existing relations among them.
• Each use case represents an abstract activity, which is performed by the user of the system.
5.28.10. KobrA - Usage model - Vending machine's use case diagram
5.28.11. KobrA - Environmental map
Usage model
• Use case diagrams contain few information itself, so they have to be completed with use case descriptors. It can be done by using use case templates.
5.28.12. KobrA - Environmental map - Use case template
5.28.13. KobrA - Vending machine - Purchase item use case
5.28.14. 5.1.2 Business and enterprise processes model 5.28.15. KobrA - Environmental map
Business and enterprise processes model
• Describe the business environment of our system.
• Sometimes it is not so important, e.g. in case of embedded systems (vending machine).
• Sometimes it is important (bank systems).
• In the case of bank systems, the enterprise model represents those notions, those are relevant to the world of banks.
• In this case, business and enterprise models are focusing on how these existing notions affect the computer system.
5.28.16. KobrA - Environmental map
An enterprise model of a bank software
• Relevant notions of a bank software
• Bank account
• Account
• Exchange rates
• Form filled by customers
•
• It should be defined for a business and enterprise model
• that how these notions affect the software system, which will be created and
• what kind of changes should take effect in the organization structure of the bank after the system is installed.
5.28.17. 5.1.3 Structural model 5.28.18. KobrA - Environmental map
Structural model
• The structural model lies inside the environmental map, which defines the structures of those entities, those are out of the system's scope, but they effect the system. It contains the system's
• inputs and
• output (which will be postprocessed somehow).
• In our example, the simplest case does not contain such outer structure, which has to be considered. (If a creditcard or hotelcard payment method exist, then these should be included in the structural model.)
5.28.19. KobrA - Structural model of a variant inside the environmental map
5.28.20. KobrA - Environmental map
Notations
• The user of the vending machine can pay in two different ways:
• together with the hotel receipt, or
• with creditcard.
• It is noticed with the following variants:
• "variant" RoomBilling association in the diagram, and
• "variant" CCBilling association in the diagram.
5.28.21. 5.1.4 Activity and interaction model 5.28.22. KobrA - Environmental map
Activity and interaction model
• The activity model inside the environmental map describes the activities of the system actors, those affect the system boundaries.
• The UML activity diagram is very similar to the traditional control flow graph, although diagrams are used on a higher abstraction level.
5.28.23. KobrA - Activity diagram - Vending machine - Purchase Item
5.28.24. KobrA - Environmental map
Explanation
• At the entry point of the diagram, we can choose from two alternatives
• select an item or
• drop coins into the machine and the select an item.
• The main path in the activity diagram is to dispense the selected item and the change.
• These two activities can run concurrently, as it can be seen on the model.
• An other possible path in the diagram is the abort.
5.28.25. 5.1.5 Summary
5.28.26. KobrA - Environmental map
Summary of the environmental map
• Usage model
• is useful to discuss with the customer, whether we understood correctly the problem,
• and to transform the models into diagrams.
• Activity model
• based diagrams are going one step closer to the technical abstraction. These small steps are important, because the development is made recursively until we reach an implementable version.
• Interaction model
• is very useful to show the user activities.
5.28.27. KobrA - Activities of a customer of the Vending machine
5.28.28. KobrA - Environmental map
Summary of the environmental map - cont.
• When the environmental map is made, then the next step is to specify the top level component.
• Component/system: it depends on the viewpoint and it is difficult to define the place where they should be split.
• Components can be defined by the tools of the meta-model (as can be seen on the next figure).
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
• Formerly, software projects did not use usually the structural specification. It became useful, when the model