1.1. Introduction
2.4.6. Activity diagram - example
2.4.7. 2.4.3 State-machine diagram 2.4.8. State-machine diagram
State-machine diagram
• It models a behavior of one object.
• It specifies the event sequence, which occurs when a response is generated to a query.
2.4.9. State-machine diagram
Elements of the state-machine diagram
• States,
• initial and final states,
• transitions,
• state actions,
• self-transition,
• compound states,
• entry point,
• higher entry point,
• exit point,
• choice pseudo-state,
• junction pseudo-state,
• history state,
• concurrent regions.
2.4.10. 2.4.4 Communication diagram 2.4.11. Communication diagram
Communication diagram
• Formerly called as interaction diagram.
• It gives information similar to the sequence diagram.
• It focuses on the relations, connections of the objects.
2.4.12. 2.4.5 Sequence diagram 2.4.13. Sequence diagram
Elements of the sequence diagram
• Lifelines,
• messages,
• self messages,
• lost and found messages,
• lifeline start and end,
• duration and time constraints,
• combined fragments,
• gate,
• part decomposition,
• state invariant / continuations.
2.4.14. 2.4.6 Timing diagram
2.4.15. Timing diagram
Timing diagram
• Elements of the timing diagram
• state lifeline,
• value lifeline,
• putting it all together.
• Figure above shows two examples to state lifeline at the top, and a value lifeline at the bottom, while the whole figure gives an example to a combined timing diagram.
2.4.16. 2.4.7 Interaction overview diagram 2.4.17. Interaction overview diagram
Interaction overview diagram
• Elements of the interaction diagram
• interaction occurence,
• interaction elements,
• putting it all together.
2.5. 2.5 IDL
2.5.1. Interface Definition Language
IDL - Overview
• Language independence
• Defines object (called modules in CORBA terminology) interfaces
• Hides the implementation
• An IDL compiler is needed to create stubs and skeletons to the described components. Stubs and skeletons are code chunks, providing connection between the components.
• IDL compilers available to a wide range of programming languages: C, C++, Java, Cobol, Smalltalk, Ada
• Elements of the language: tokens, comments, identifiers, keywords and literals
2.5.2. Interface Definition Language
Tokens
• Tokens can be: identifiers, keywords, literals, operators, other separators.
• A token is taken to be the longest string of characters that could possibly constitute a token.
Comments
• Follows the C, C++, etc. standard
• Comment start/end: /* and */
• Comment till the end of the line: //
• Comment start does not take effect in the line of the // characters after them.
• // characters does not take effect in a /* */ block.
readonly attribute long Attribute; // error: Attribute collides with keyword attribute
• An identifier is an arbitrarily long sequence of ASCII alphabetic, digit, and underscore _ characters. The first character must be an ASCII alphabetic character.
• Upper- and lower-case letters are treated same.
• In OMG IDL: there is only one namespace for identifiers in each scope.
• Identifier names can be escaped with _
2.5.4. Interface Definition Language
module M {
typedef Long my_num; // Error: keyword is long, not Long
typedef boolean BOOLEAN; // Error: BOOLEAN collides with the keyword boolean
};
Keywords
• Keywords are case-sensitive!
• Keywords e.g.: abstract, exception, interface, module, etc.
• Punctuation characters:
• Preprocessor tokens:
2.5.5. Interface Definition Language
Literals
• Integer literals: Decimal, if 0 or sequence of digits, begins with non zero. If starts with 0, then it is an octal integer. A sequence of digits preceded by 0x or 0X is taken to be a hexadecimal integer.
• Character literals: Character literals have type char. Non-graphic character must be represented using escape sequence, e.g.: newline n, horizontal tab t, etc.
• Floating-point literals: consist of an integer part, a decimal point, a fraction part, an e or E, and an optionally signed integer exponent. The integer and fraction parts both consist of a sequence of decimal (base ten) digits.
Either the integer part or the fraction part (but not both) may be missing; either the decimal point or the letter e (or E) and the exponent (but not both) may be missing.
2.5.6. Interface Definition Language
Literals
• String literals: a sequence of characters with the exception of the character with numeric value 0, surrounded by double quotes, e.g.: "HELLO".
• Fixed-point literals: Consists of an integer part, a decimal point, a fraction part and a d or D. The integer and fraction parts both consist of a sequence of decimal digits. Either the integer part or the fraction part (but not both) may be missing; the decimal point (but not the letter d (or D)) may be missing.
2.5.7. Interface Definition Language - Example
// Defines a container (namespace) module <identifier>
[<op_type>] <identifier>(<parameters>)[raises exception][context];
} }
IDL - CORBA Details of IDL will be discussed later as a part of CORBA.
3. 3 Software architectures
3.1. Software architecture
Concept of software architecture
• Software architecture is a relatively young discipline. Its concept is not yet complete.
• Some definitions:
• Software architecture is not else, than a high level software designing;
• It is not else, than a structure of a complete system;
• The architecture is a set of components and connectors.
3.2. Software architecture
Our software architecture definition
• A software architecture of a program or a computer system is the structure(s) of the program or computer system, which structure contains the software elements, their visible properties (from outside), and their relationships.
3.3. Software architecture - Analysis of the definition
Architecture and abstraction
• The architecture defines the software elements and their connections, omitting those information, which is irrelevant to the interactions between the elements.
• The architecture is a kind of abstraction of a system. It omits information of elements, which does not define the usage, connections and interactions of the components.
3.4. Software architecture - Analysis of the definition
Relation of the system and the structure
• A system may contain several structures, and none of them can say unquestionnable, so it is the architecture.
• The architecture is the set of the structures.
• Software systems using softwares necessary have software architecture.
• The behaviours of the system elements should be parts of the architecture.
• Definition of architecture is indifferent in the meaning of the architecture is correct for the system or not.
3.5. Software architecture
Most important components of the software architecture
• Architecture schemas
• Reference models
• Reference architecture
• Relations of components can be seen on the next figure
• Directed arrows show that a given concept contains more than one elements.
3.6. Relations of architecture schemas, reference models, reference architectures and software architectures
3.7. 3.0.1 Architecture schema 3.8. Software architecture
Architecture schema
• An architecture schema is a description of elements and relation types, which also contain the set of constraints of their usages.
• Example: the client-server architecture is a well-known schema.
3.9. 3.0.2 Reference models 3.10. Software architecture
Reference models
• A reference model is a partitioning of the functionalities, which also contains the dataflows among the elements.
• The reference model is a standard decomposition of a well-known problem into such parts, whiches are cooperating to solve the original problem.
3.11. 3.0.3 Reference architecture 3.12. Software architecture
Reference architecture
• The reference architecture is a reference model, which is projected to the software elements and their connections.
• The reference models, reference schemas and reference architectures can not be considered itself as an architecture. These important definitions only help us to define the corresponding elements of the architecture.
3.13. 3.0.4 Software architecture 3.14. Software architecture
Why is the software architecture important?
• Important from the view of the communication among the components
• The software architecture represents that common abstraction of a system, which is used by all the components and it can be a starting point to the mutual understanding, the consensus and the communication.
• Important at the early designing decisions.
• Important as a kind of abstraction of the system, because it gives help to the reusability.
3.15. 3.0.5 Common software architecture structures 3.16. Common software architecture structures
3.17. 3.0.6 Model based structure 3.18. The model based structure
Elements of the model based structure
• Decomposition
• A unit of the decomposition is the module.
• Modules can be joined by the is a submodule of relation.
• A module can be decomposed recursively, until it becomes easy to understand and implement.
• Uses
• These units can be also modules, but they can be procedures or resources described in the module interface too. The uses relation stands between the units.
3.19. The model based structure
Elements of the model based structure - cont.
• Layered
• A special case of the uses relation, in a strictly layered structure.
• The n-th layer uses only the services of the (n-1)th layer.
• Class or generalization
• In this structure, modules are called classes.
• The relation in this case can be inherits-from or an-instance-of.
3.20. 3.0.7 Component-and-connector structure 3.21. Component-and-connector structure
Elements of the structure
• Processes, or communicating processes
• Like every component-and-connector structure, this is also orthogonal to the model based structure.
• Units are processes or threads, where communication is the synchronization - including the mutual exclusion.
• The relation between units is the attachment, which shows that how the components and connectors are connecting to each other.
3.22. Component-and-connector structure
Elements of the structure - cont.
• Concurrency
• This structure gives the opportunity to the system designers to introduce the parallel execution.
• Units are components, and connectors ara logical threads.
• Shared data, or repository
• This structure contains components and connectors. These are creating, storing and retrieving data.
• It shows that, how data is created and used by runtime software elements.
3.23. Component-and-connector structure
Elements of the structure - cont.
• Client-server
• System is built from a set of cooperating clients and servers.
• Components can be clients or servers, while the connectors are communication protocols.
3.24. 3.0.8 Allocation structure 3.25. Allocation structure
Elements of the allocation structure
• Deployment
• It defines, how the software is assigned to the hardware processing and to the communication elements.
• Its elements are the software (usually a process from a component-connector structure), the hardware (processes) entities, and the communication paths.
3.26. Allocation structure
Elements of the allocation structure - cont.
• Implementation
• This structure defines, how the software elements are projected to the file structures.
• Work assignment
• This structure assigns the implementation and integration of each module to a corresponding developer team.
3.27. Software architecture
Which structure should we use?
• Some useful architecture structure are introduced in outlines, but many others exist too. It can be asked, which one should be used to concrete task? It is hard to answer, because a system may contain several structures. The advice is that the quality attributes of the system should be analysed thoroughly first, then select those structures, whiches guarantee best the required quality.
3.28. 3.1 Component models
3.28.1. Component models
Goal of component models
• Support to build software systems from different functional and logic components, those can be located in different network nodes.
• Both the software and the hardware sides of component-based software development has to be supported.
• Middleware is the most important part for basic softwares.
3.28.2. 3.1.1 Middleware
3.28.3. Component models
Middleware
• Its place is between the operating system and the application.
• It serves similar services as the operating system.
3.28.4. Component models
Middleware - services
• Framework to run component-based programs,
• Typical operating system functionalities,
• Connection between the operating system and programming language,
• Support one operating system and one programming language,
• Generate the executable code by a code generator,
• The manual component creation is less important, components can be independently developed.
3.28.5. Component models
Middleware
• Components can be either in the same or in different network nodes.
• Components located far away from each other can collaborate via Remote Procedure Call (RPC).
• A kind of RPC service can be found todays in any component platform.
• The object models are built upon the middleware.
3.28.6. Component models
Middleware systems
• Object Management Group (OMG)
• CORBA
• Microsoft
• COM/DCOM
• CORBA - Common Object Request Broker Architecture
• The first experiment to define an object model
• OMG 1991
• Main parts:
• Object Request Broker (ORB)
• The heart of CORBA, responsible for the communication among components, and for the creation and persistency of them.
• Interface description in Interface Definition Language (IDL)
• Portable, independent from the programming languages and operating systems.
• IDL - compilers to programming languages
3.29.2. 3.2.1 Object Request Broker 3.29.3. CORBA
Object Request Broker (ORB)
• Hide the communication among different address ranges (e.g. memory mapping)
• Components under the ORB supervision can create connections to each other, as if they are in the same memory space.
• ORB consists of several components on the client and server side.
3.29.4. CORBA - ORB
ORB - Client side
• Client IDL Stubs provide the static interfaces on the client side for CORBA component connections
• A proxy for remote procedure call, which transmit the calls to the remote server.
• Forward parameters to the server by the marshalling technique.
• ORB interface provides some useful local services to CORBA users:
• E.g. Convert component-references to character sequences (sequencialization) etc.
3.29.5. CORBA - ORB
ORB - Client side
• Dynamic Invocation Interface - DII helps to create dynamic components, whiches are able to explore and call methods of the server-side components in runtime.
• DII provides better flexibility at runtime, but static stubs support type checking at compilation.
• Interface Repository API provides the runtime access to the interface-repository, which contains the preprocessed IDL definitions.
• In CORBA 2.0, it also contains ORB global identifiers (Repository ID). Repository IDs are uniq identifiers of components and their interfaces.
3.29.6. CORBA - ORB
ORB - Server side
• Server IDL Stub defines static services of the server side components. Its skeleton also generated by the IDL compiler.
• Dynamic Skeleton Interface (DSI) is the pair of the Dynamic Invocation Interface (DII). It provides information in runtime about those server side components, those do not have IDL defined static stubs. DSI determines the corresponding component and its service (method), by the parameteres of the incoming message.
3.29.7. 3.2.2 Object Adapter 3.29.8. CORBA
Object Adapter
• Required to the implementation of DSI, DII, but can be used independently also.
• Runtime environment manages the
• Object references,
• Implementation Repository
• All ORB support at least one adapter
• Basic Object Adapter (BOA)
3.29.9. 3.2.3 Implementation Repository, ORB interface 3.29.10. CORBA
Implementation Repository, ORB interface
• Implementation Repository
• Container of descriptions of the implemented server side classes.
• Keeps track the instantiated objects and how to identify them.
• ORB interface is the pair of the server side IR on the client side.
3.29.11. 3.2.4 IDL 3.29.12. CORBA - IDL
Interface Definition Language (IDL)
• CORBA is strictly an object based system
• Server components can be defined as classes. Their properties are
• Inheritance,
• Exception handling,
• Encapsulation.
• IDL is used to define the classes
• Portable
• Programming language and operating system independent declarative language. It does not contain procedural elements, but supports
• Interfaces given in IDL language are compiled by the IDL compiler to a concrete language (e.g. Java). Their methods should be implementated in the same programming language.
• The structure of IDL can be found in the Java 2 Útikalauz programozóknak book (editor: Nyékiné Gaizler Judit, ELTE TTK Hallgatói Alapítvány, Budapest, 1999.)
3.29.14. CORBA - IDL
IDL compilers
• IDL - Java compiler
• Input: Interface description in IDL langauge
• Output: Java program code
• Usage of the compiler described in the book (section 22.3.)
• A simple, but useful example can be found about the usage of CORBA in the section 22.4 of the book.
• In the example, a group of objects are created on several servers.
• In the example above, the client and the server are using the CORBA Naming Service to localize each others.
3.29.15. Generated code execution within the CORBA infrastructure
3.30. 3.3 COM/DCOM
3.30.1. COM/DOM
COM/DCOM
• Component Object Model - COM
• The first component model of Microsoft (1993)
• COM+
• An expansion of COM: transactions, asynchronous messaging, with the tools of clustering.
• Distributed COM - DCOM
• An extension to COM to handle distributes systems
• A DCOM component is able to communicate with a DCOM server - by client proxies and server stubs.
• The services of CORBA and DCOM are getting closer, but not their tools!
4. 4 JavaBeans
4.1. 4.1 Introduction
4.1.1. Introduction
Sun Microsystems's Java 2 Enterprise Edition (J2EE)
• Describes how to design and develop Java programs, and how the objects communicate.
• Describes several business services: naming, transactions, lifecycle handling.
• Elements created in the standardized way are platform independent.
• The J2EE architecture was developed at the late '90s.
Enterprise JavaBeans (EJB) It defines the server side components.
4.2. 4.2 JavaBeans
4.2.1. JavaBeans
JavaBeans
• The simplest component model of Java.
• At the first sight, JavaBean is a reusable software component, which can be visually manipulated in the developer environment.
• In the JavaBeans component model
• a component may have several independent implementation.
• More instances can be created from a given component, customizing to the applications.
• Components can elements of containers.
• A component can be a container and also able to contain other components.
• Connections and communications among components are done by event handlers and method calls.
4.2.2. JavaBeans
JavaBeans
• The JavaBeans component model supports the hierarchic software development, where complex components can be created by containers from simpler components.
• Services of visual developer tools can be used.
• Development of beans is simplified by the Sun's BeanBox development environment.
• The JavaBeans model supports the customization of the beans by property lists. These lists can be displayed for easier manipulations.
4.2.3. 4.2.1 Enterprise Java Bean 4.2.4. JavaBeans - EJB
EJB - Enterprise Java Bean
• Server side distributed component model
• Types based on functionalities:
• Session Bean
• Enterprise Bean
• MessageDriven Bean
• An application server is requiered to run the components (an EJB container is required).
• Contracts between the EJB and the container
• set of interfaces,
• deployment descriptors.
4.2.5. 4.2.2 J2EE overview 4.2.6. Java2EE
Java2EE
• An architecture for a component-based, multi-layered enterprise application development.
• J2EE architecture:
4.2.7. Quality requirements of web-application
Quality requirements of web-application
• Scalability - System should be functional without human interaction, if load increases. The number of servers may change.
• Availability - System should be reachable 24 hours a day, and it should provide a short download time.
• Security - Provide possibility to register new accounts, and do right management (each person can get only that data for right is granted).
• Usability - Different users should be able to get different contents in different formats at the same time.
• Performance - Short response time is required.
4.2.8.
Additional requirements to J2EE
• Portability - Should be implemented easily on several platforms
• Ability to build - Developers can manage generally used services, like transactions, name services and security services
• Balanced specifications - Detailed specifications for manufacturers, developers and integrators, and sufficiently general specification for business and optimailty properties.
• Implementation, transparency - clear implementation; clients should not depend on details of implementations
• Cooperation - Components of different manufacturers should be able to communicate. Bridges should exist to different technologies (e.g. CORBA, .Net)
• Developmnet - Opportunity for developers to adopt different technologies.
• Expansibility - Possibility to integrate important and new technologies.
4.2.9. 4.2.3 J2EE - EJB overview 4.2.10. J2EE - EJB
Goals of EJB
• Support component-based software development by the reusability of the Java components.
• A tool is needed with server side applications can be developed as easy as e.g. GUI applications in Visual Basic.
• The standard framework has to be easy to use.
4.2.11. J2EE - Tasks of EJB
Tasks of EJB
• Support the lifecycle of a business application, including its deployment, and its runtime supervision.
• Define contracts, which provide the communcication ability to the components of different manufacturers.
• Cooperate with other Java APIs.
• Offer a cooperation between the Enterprise Beans and non Java application.
• Cooperate with CORBA.
4.2.12. Properties of J2EE
Main properties of J2EE
• Multilayered distributed application model
• Client layer
• Web layer
• Business component layer
• Enterprise information system tier
• Server side component model
• Built in transaction handling
4.2.13. 4.2.4 J2EE - architecture 4.2.14. Architecture of J2EE
4.2.14.1. 4.2.4.1 Client layer
4.2.15. J2EE - Client layer
Client Layer
• For a web application, it contains only a web browser. It sends HTTP requests to the Web server and download HTML pages from there.
• In applications, those are not using browser, Java clients ot applets can be used. These have direct connections to the Business component layer.
4.2.15.1. 4.2.4.2 Web layer
4.2.16. J2EE - Web layer
Web layer
• A Web server is running in the Web layer, which answers to the requests coming from the client layer, using servlets or JPS (Java Server Pages). Servlets are called by the server depending on the type of user requests.
• Servlets are gathering the required information from the business component layer. JPSs are HTML pages,
• Servlets are gathering the required information from the business component layer. JPSs are HTML pages,