|
partitioning (as seen in
Figure 11.6
), which allows the addition of more layers or tiers. The
architecture provides vertical partitioning as well. As part of vertical partitioning, each layer (or tier)
can be partitioned based on its functionality. For example, let us assume that the architecture
outlined in
Figure 11.6
has to support two distinct devices. As such, the presentation layer can be
divided vertically into two presentation subsystems, as shown in
Figure 11.7
.
In this specific case, the requirements are for an application that can be executed using a standard
PC and a mobile phone. Although all mobile devices support a browser, which can run the
application, the different characteristics sometimes require a different presentation layer. The
application, in this case, is designed to use two different presentation subsystems.
There are, of course, situations in which not only does the presentation have to be vertically split
but the additional layer as well. For example, if the application displays advertisements, then on the
PC screen, some ads can be displayed on the left and right sides. On the mobile device, due to its
limited display, the ads should be managed differently. In such a case, the business-logic layer will
have to be divided as well (
Figure 11.8
).
Of course, vertical partitioning can be extended to additional layers as well. For example, a system
that uses more than one storing mechanism, or utilizes more than one database, may require more
than one DBMS layer.
FIGURE 11.7
Vertical partitioning.
FIGURE 11.8
Two-layer vertical partitioning.
The main benefits of using tier architecture are
• Increased availability due to the modular design and the possibility of replicating servers as the
load increases, or in case of a server malfunction
• Increased scalability, since each tier can be deployed on one or more servers, and each such
server can be scaled based on the anticipated load
• Increased flexibility, which is gained by the modular design and the fact that each tier can be
managed and scaled independently, with no required changes to the other architectural
components
• Simpler maintainability, which is achieved due to the separation of the tiers and the fact that
each one can be maintained independently without interfering with other components
Compared with layered architecture, tier-based architecture provides additional benefits and,
mainly, flexibility. If the processing done in one layer is intensive and may interfere with the
processing required in other layers, then tier architecture is a much better option because of its
utilization of a different computer. Furthermore, in some cases, the different layers are executed on
the same machine, even if there is very little interaction between them. With the rapid developments
in communications technologies as well as distributed processing, tier architecture may provide a
significantly better solution.
Object-Oriented Architecture
The object-oriented paradigm was developed originally as a new programming approach in the
1960s with the introduction of Simula, a language developed by a group of Norwegian researchers to
simulate real systems. Additional developments were performed by researchers at Xerox with the
introduction of Smalltak, which was a real object–oriented programming language. Only during the
1980s, with work by Grady Booch, did it develop from mainly a programming language into an
object-oriented design method. In the 1990s, additional capabilities were introduced, such as object
modeling techniques (OMT) by James Rumbaugh and object-oriented software engineering by Ivar
Jacobson.
The main idea behind object-oriented analysis (OOA) is that software, like the real world that
surrounds us, should be modeled using many objects that interact with each other. The main
difference between OOA and other types of analysis is that in OOA, the requirements, model, and
implementation are based on objects. Contrary to the procedural approach, in which software is
based on two separate entities—procedures, representing the logic; and data—in the object-oriented
approach, objects are integrated units that contain both the object’s data and logic.
In previous and other forms of systems’ analysis, requirements are gathered to form the required
functionality of the system. In OOA, the requirements are needed in order to
• Identify the participating objects
• Build the object model diagram that defines the objects and their interactions
• Elaborate on the objects’ attributes and characteristics or the information they maintain
• Define the behavioral aspects of the objects or the operation they can perform
As part of the tools developed for supporting OOA, the unified modeling language (UML) was
defined. UML is a set of specifications and diagrams used for modeling the architecture, structure,
and behavior of the system as well as the business processes it supports. As part of the OOA, the
common models used are use cases
*
and object models
†
.
The next stage in the software development life cycle is the design. The object-oriented design is
about implementing the conceptual model defined as part of the analysis. The analysis stage and the
conceptual model defined are technology independent. Only during the design are the specific
technologies (e.g., databases, development frameworks, middleware) defined, which requires
revisiting the object model and defining the class data and methods. As part of the object-oriented
design component
‡
and deployment
Do'stlaringiz bilan baham: |
