1.1. Introduction
1.5.6. Component-based Software development
Components in focus
• The main notion of component-based systems is the component.
• Most important properties of the component:
• Well-defined user interface provides services). The interface is given by abstraction, and they can be combined without modification.
C. Szyperski: The component is a reusable element of the composition, which has a well-defined interface, and it has environmental dependecies, those can be used independently from each other by a third party too.
J. Hopkins: A software component has a well-defined public interface, and this component is a physical package of an executable software.
1.5.9. Composition
Purpose of composition
• The component is the reusable unit of composition.
• Components should be functional in different environments.
• Recursive composition is permitted.
1.5.10. Composition - UML diagram
1.5.11. Interface
Interface
• Provided interface
• Collection of services and behaviours provided to the clients by the component.
• Entry point of execution of the component.
• Required interface
• Collection of services and behaviours required by the component from the environment.
• Without a correct environment and support, it is not guaranteed that the component is able to provide the functionality described in its interface to the clients.
1.5.12. Client-Server connection
Client-Server connection
• At the viewpoint of the provided interface, the component acts like a server.
• At the viewpoint of the required interface, the component acts like a client.
• The collaboration between the provided and required interfaces is guaranteed with contracts.
1.5.13. UML representation of the required and provided interfaces of the component
2. 2 UML, IDL
2.1. 2.1 UML
Short overview
• Unified Modeling Language: a set of graphic notation techniques to create visual models of object-oriented systems,
• In 1990s at Rational Software: Grady Booch, Ivar Jacobson and James Rumbaugh,
• In 1997 it was adopted by the Object Management Group (OMG),
• In 2000, UML was accepted by ISO.
2.2. 2.2 Modeling in UML
Modeling in UML
• UML is graphical modeling language, where
• the specification can be defined at abstract level,
• methods and tools exist to implement the specified system,
• it is a solution to create the documentation.
• UML2 is an extension of UML with 13 basic diagram types, organized into two large groups.
• Structural modeling diagrams
• Behavioral diagrams
2.3. 2.3 Structural diagrams
2.3.1. Structural diagrams
Structural modeling diagrams
• The static architecture of a model can be defined with structural diagrams.
• Basic elements of a model are
• classes, objects, interfaces and component.
• The structural models define the relations and dependencies among the elements of the model.
• Six different diagrams can be used to create the structural diagram
• Package diagram
• Class diagram
• Object diagram
• Composite diagram
• Component diagram
• Deployment diagram
2.3.2. 2.3.1 Package diagram 2.3.3. Package diagram
Package diagram
• It describes how to organize packages and its elements. The namespace is same for elements in the same package.
• Connectors can be defined among the packages
• Package merge is an implicit generalization between two package. Element definitions of the source package can be extended with the element definitions of the target package.
• Package import means that elements of the target package use the unqualified version of the source package names.
• Nesting connectors signs that the source package is contained in the target package.
2.3.4. 2.3.2 Class diagram 2.3.5. Class diagram
Class diagram
• The static structure of the system can be defined with class diagrams.
• It describes the relations among the classes and interfaces.
• A relation type can be one the next types
• generalization
• aggregation
• association
• inheritance
• composition
• Class diagram describes the structure of the solution in the problem space. It can be viewed as a simple connected graph, where the nodes are classes and the edges are relations.
• http://uml.org/#UML2.0
2.3.6. Class diagram
2.3.7. 2.3.3 Object diagram 2.3.8. Object diagram
Object diagram
• A special case of the class diagram.
• Object diagram focuses on the connections among class instances at a given time slice.
• The following example shows the difference between the class and object diagrams.
• A class consists of name, attributes, methods.
• Only the name is given for an object, and the class, the object instantiated from.
2.3.9. 2.3.4 Composite structural diagram 2.3.10. Composite structural diagram
Composite structural diagram
• The composite diagram defines the inner structure of the class, and those points, where they connect to the system.
• Figure shows a general schema to define a class.
2.3.11. Composite structural diagram
Part
• A part is an element of a class, which represents one or more instances, whiches are owned by the instance of the given class.
• An example can be seen on right.
2.3.12. Composite structural diagram
Port
• A port is an element with a given type. It represents a part of a class instance, which can be viewed from outside.
• A port can specify all the services, whiches are provided and required by the class.
2.3.13. Composite structural diagram
Interface
• Similar to the class, but
• All interfaces are public and abstract and they do not have default implementations.
• An attribute of an interface is a constant.
• If a class inherits only from one super-class, then it can implement multiple interfaces.
• The interface can be represented as on the upper figure, while the representation of the provided and required interfaces can be seen on the lower figure.
2.3.14. Composite structural diagram
Delegate
• Delegate is a connector, which defines the inner function of the outer ports and interfaces of the component.
2.3.15. Composite structural diagram
Collaboration
• A collaboration defines a set of cooperation roles. They are used to illustrate a specific functionality.
• A collaboration often realizes a pattern.
• It shows only those roles and attributes, whiches are required to provide the required functionality.
• It is represented by an ellipse.
2.3.16. Composite structural diagram
Role binding
• A connector, which connects a collaboration and a class or a part of a class. The given role is realized by the class.
2.3.17. Composite structural diagram
Representation
• Representation is a special connector, which makes connection between a collaboration and a class, where collaboration is used inside the class.
2.3.18. Composite structural diagram
Occurence
• A connector, which makes connection between a collaboration and a class, where collabaration represents the class.
2.3.19. 2.3.5 Component diagram 2.3.20. Component diagram
Component diagram
• A component diagram represents a part of the software and the system is built from these components.
• The component diagram has a higher abstraction level than the class diagram. A component is realized often by more than one class at runtime.
• A component diagram may represent many components and their relations.
2.3.21. Component diagram
Short explanation of the previous figure
• Product and Customer components provide the interfaces for the Order component.
• Between the Account and Order component, a dependency relation can be seen.
• The dependency relation projects the Account details of the Customer to required interface of the Order, identified by Payment.
Assembly connector on the previous figure
2.3.22. Component diagram
Component with ports
• A component specification can be extended by ports, and then the provided and required services can be also specified.
• The ports OrderEntry, Tracking on the figure represent the provided interface, while payment gives the required interface to OrderProcess component, which has a port OnlineService.
2.3.23. 2.3.6 Deployment diagram 2.3.24. Deployment diagram
Deployment diagram
• It is modeling the architecture of a system at runtime.
• The diagram shows the configuration of hardware elements (nodes) and it also shows the projection of software elements onto the hardware.
• A node represents a hardware or software element as a 3D box. The figure above represents a node and a node instance.
• Stereotypes can be: <server>, <storage>, <cdrom>, <computer>, <pc>, <unix server>, <pc server>, <pc client>, etc.
2.3.25. 2.3.7 Artifact, Installation association 2.3.26. Artifact, Installation association
Artifact
• A product is a result of a software development process, which contains
• models (use-case models, design models, etc.),
• test results, prototypes and user guides, source files, executables, etc.
Installation association
• Associations represent the communication paths among the nodes in the case of deployment diagrams.
2.4. 2.4 Behavioral diagrams
2.4.1. Behavioral diagram
Behavioral diagram
• Use case diagram
• Activity diagram
• State machine diagram
• Communication diagram
• Sequence diagram
• The use case model contains the requirements at the highest abstraction level to the system.
• The elements of the model
• actors, whose are able to generalize other actors,
• use cases, describing the behaviors of the system at the highest level,
• use case definition
• It shows the sequence of activities of a process from the beginning to the end.
• Diagram can show different decision paths or parallel execution at the same diagram.
• This diagram is often used to model business processes, while the state machine diagrams are able to model a behaviour of only one object.
• Elements of the activity diagram
• activity, actions, action constraints,
• initial node, final node, decision and merge nodes, fork and join nodes
• control flow, objects and object flows,
• expansion region, interruptible activity region,
• exception handlers,
• partition.
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 can be either in the same or in different network nodes.