Software Architecture have a persuasive impact on the system. It acts as the logical
supporting structure of the system. Also, it gives emphasis to quality attributes. Furthermore,
an impression of the functionality of the system can also be seen in the
architecture. Design and development of an architecture can be done in many methods
like Risk driven model. However, ATAM is used in the chapter 3 to extract the quality
attributes respected to the business goals. Subsequently, architecture is modeled based
on those quality attributes. [4]
4.1 Architecture Description Language
As described earlier, functionality of the system shall be demonstrated by an architecture.
In order to do that, Architecture Description Language(ADL) are supposed to
stress on the functionality. With Unified Modeling Language (UML), clear representation
can be made of an architecture. Besides these facts, UML is an universal language
and it is easy to understand. The basic reason behind the usage of UML is that, it
matches with our needs of representation and it is understandable by almost everyone.
UML influence stable architectures. UML helps in visualizing the architecture. The tool
can be anything until the visualization is understandable and accurate. This can be
compared to cutting your hair. Tool used to cut the hair can be of anything such as
scissor, electronic trimmer or a knife. In ancient times, primitive things are used. Despite
of the tools being used, the target is achieved. UML which is understandable and usable
by majority is used in this report. [4]
4.2 Software Development process
In the context of design, modeling and development, process plays an effective role. The
Software Development Life Cycle (SDLC) illustrates wide variety of process models such
18 Chapter 4. Architecture Modeling
as waterfall model, spiral model, V model, etc. One of the primitive process model is
waterfall model. It is followed in a sequential methodology and there is an urge to finish
every step before proceeding to the next one. On the other hand, spiral model operates
in iterative methodology. Every step in the development process are visited again and
again in the entire process. It enables the entire model to be in alignment with the
design. In the event of change of requirement during the design, spiral process model
enables the design or the architecture to be as expected. ATAM can be used with spiral
model which might result in unprecedented quality output.
4.3 Modeling
There is always a question, how much you have to model? Or, it can be rephrased
as, how far a model supposed to cover? The researchers suggest that there shall not
be a Big Design Up Front (BDUF). Design is valuable and significant for a success of
system. Nevertheless, too much design will mostly fail to meet the required output on
time. Modeling requires the understanding of the architecture. Classification of scenarios
based on positive and negative impacts on the systems and association with the design
patterns yield in an effective model. Instead of designing a new model for a specific
problem, it is better to use the available basic models. Conceptual models exhibit the
representation of business and it’s needs. The main reason behind using models is to
keep track of path of requirement. Models keep the understanding aligned and produce
results as expected. [4]
Canonical Model Structure
Models are basically classified into conceptual, logical and physical entities. Conceptual
models outlines about domain and the business logic behind every requirement. This
serves the core concept for the requirement need and the benefit behind the change. Actual
change that happened after the development are illustrated by the physical models.
Clear view of the development can be foreseen. Model, that acts as a bridge between
the domain and the physical, is the logical model. This bridge aids to understand the
conversion process of every requirement into a physical entity. In other words, three
basic models of the canonical model structure is stated as the domain, design and code.
Obviously domain model briefs about the domain and the business, it’s needs and requirements.
Similar to logical model, design binds both domain and code or the physical
world. It gives the visualization of the real world. To sum up, the process from abstraction
to solid results are demonstrated in canonical model structure. [4]
In the context of civil engineering world, bridges serve the purpose to reduce the traffics
while commutation or to connect two lands and etc.. Construction of a bridge needs
proper planning and this will have direct effect on human lives in case of failure. Transformation
of this requirement into action plans and designs will result in logical structure.
On testing and validating the design, a physical bridge is constructed. Canonical
4.3 Modeling 19
Figure 4.1: Canonical Model Structure
model structure is similar to the process used for constructing a bridge which has plan,
design and implement. However, canonical model structure is applied in the software
engineering.
4.3.1 Domain Model
In this domain model, access to the changes on domain is limited or with no access. To
be precise, architecture are derived from the domain. It is the real world system. This
model outlines the domain and their characteristics.
The figure 4.2 depicts the high level domain model and data flow in the business. Dashboard
database server receives data from other systems such as AMAM, IDOLS, ISAIM,
Airbus Spare and AIRNAV. These data are imported as a data file. Data integrity in
the current scenario is questionable. Hence, a powerful data transmission system needs
to be developed.
20 Chapter 4. Architecture Modeling
Figure 4.2: Data Flow Domain Model
4.3.1.1 Information Model
Information model is a part of domain model which exhibits only the current scenario
and not the design to be built. Usually, the actors and actions are mentioned in the
information model. They are related using associations. the maintenance process optimization
is illustrated in the figure 4.3. [4]
MPO Engineers work on tasks to create evolution dossier. As explained, tasks are usually
of two types such as fleet level tasks and customer specific tasks. Each task analysis
phase contains many number of tasks to process and it is aligned to an aircraft type.
However, in both types of task analysis, many aircrafts of same type play their part in
the maintenance evolution. Based on the findings of tasks, every task is documented,
despite of the number of findings. Usually, statistical analysis comes into picture only
when we deal with aircrafts for an entire fleet, as every data for the fleet is hard to
obtain. Evolution dossier is the final outcome of any task, but it is not always that we
get evolution dossier from every task.
4.3.1.2 Snapshot
Information model is generic and it can be applied to any scenarios. For example, the
above information model 4.3 is applicable to all type of aircrafts, tasks and MPO engineers.
Snapshot is a scenario based information model. It explains the information
4.3 Modeling 21
Figure 4.3: Information Model
model by practically applying in a scenario so that it persuades the understanding of its
structure and design. A snapshot is demonstrated as one specific variation of the information
model. This figure 4.4 explains application of information model in a scenario
where fleet level task analysis is being done by an engineer. The expected outcomes are
also visualized.
4.3.2 Design Model
This is the middle man in the canonical model structure. Design model acts as a bridge
between the domain world and the code world. It aligns both in the direction of the requirements.
Domain is not modifiable as it represents the actual picture. Nevertheless,
design in the other hand is modifiable and controllable. When there is a understanding
about the domain, architectural styles and pattern, design will come out as a masterpiece.
It is agreed that design is a time taking process. Probably, it makes everybody
confusing. Some may start code model by skipping the design. This will always come
with the price.
There are always plenty of choices in the visualization of a design with views and models.
In a high level, models can be divided into two. They are boundary model and internal
model. It is also self understandable by it’s name. Boundary model skips much details
and describes from high point of view. Alternatively, internal model discuss more specific
deep stuffs. With respect to views, it is more interesting that models and views are
22 Chapter 4. Architecture Modeling
Figure 4.4: Snapshot of Information model
connected. They are equal in the matter of representation but are unique in how they
represent. Views are basically three types such as Module view, runtime view and allocation
view. Apart from this, there is one more called spanning view which illustrates
the attributes of the design. Combining ATAM and architecture design, it is better to
design the architecture by knowing its attributes than evaluating it after the initial
messed up design. Spanning view type covers the broader range of views as it deals with
the attributes and trade-offs. All these above are discussed in detail in this chapter 4. [4]
4.3.2.1 Boundary Model
As explained previously, the high level outline of a system is often portrayed using a
boundary Model. Quality attributes and activities are illustrated here. While speaking
of quality attributes, Utility tree which describes the quality attributes and its corresponding
scenarios is the right model to start with. Two more important representations
which pictures that outline are use cases and system context diagram.
Utility tree for the integration system for maintenance operations can be depicted in
the figure 4.5. Various attributes and the corresponding scenarios are broken down for
a better understanding. Fault tolerance corresponds to availability of the integration
system. Availability is also one more valuable asset that ensures the data flow without
any interruption. Due to the changing needs and different types of external system,
the integration system should be modifiable. To avoid breaching or any other possible
security related attacks, system should be secure. Thus, utility tree describes the quality
attributes which are architecture drivers derived from business drivers. Scenarios with
4.3 Modeling 23
respect to the quality attributes are also explained in the utility diagram. [4]
Use Cases
When there is a new tool or application in the market, the very first question comes to
mind is, "What is it's use case?". In other words, "How can we use this tool and benefit
from it?". The clear answer for this question would be the goal or vision of the tool, that
the tool is supposed or promised to satisfy. In our case, its the inverse case. we need to
define the use case for our tool. So, the use case should state clear vision and goal of
the tool which will be developed in the future based on this use case.
The behavior of the system is visualized in the form of use cases. The stake holders are
represented as actors in the use cases. Use case are modeled based on Alistair Cockburn
use case principles. [8] [9]
Characteristics Information
Use Case Automated transfer of data from different data sources to
Data management server
System under discussion Scheduled Maintenance System
Scope Airbus systems
Preconditions 1. Server details and access credentials for multiple senders
and a receiver.
2. Unique allocated ports for data transmission.
3. Authentication and authorization for reading data from the
sender and writing data in the receiver's end
Success End condition Automated transfer of data to the end system with expected
quality attributes
Failure End condition 1. Failure of data transmission to the end system
2. Successful transfer with false data
3. Successful transfer but not with the expected quality attributes
Primary Actor Messaging System
Other Actors 1. Senders
2. Receiver
3. Scheduler
24 Chapter 4. Architecture Modeling
Trigger Whenever a new data arrives in the publisher's side or on the
every scheduled time
Main success Scenario 1. Connect to data systems such as ISAIM, OI, AMAM, AIRNAV,
IDOLS and SPARE
2. Grab necessary data
3. Transmit data as messages to Messaging Server
4. Delivery of the data as messages to Subscriber
5. Loading data into receiver's end database
Extensions 1a. Data Adapter connects to the database systems as scheduled
by the scheduler.
2a. Using the right access credentials, Data adapter pulls data
with the necessary authorization
2b. Transformation of data into right data transmission format
3a. Transmission of data into the unique predefined port of
the messaging system
4a. Messaging system finds the authentic receiver for the message
and delivers after data transformation if needed.
5a. Data Adapter in the receiver's side receives data and loads
into the database system.
Variations Messaging Server is a system
Sender or Publisher is a system
Receiver or Subscriber or Client is a system
Scheduler is a system.
Data Adapter is a system.
Database system can be anything like
1. SAP system
2. SQL Server
3. Mongo DB server
4. Oracle or etc.
Data format may be of
1. Csv
2. XML
3. JSON
Table 4.1: Use case
4.3 Modeling 25
4.3.2.2 System Context
System Context is a another version of use case diagram but with functional specifications.
In other words, system context outlines the functionality in a boundary model.
System context diagram takes a use case into next level and much closer to the code
model. In addition to this, it exhibits the functionalities with connector instances, ports
and the systems. The systems are represented in components. This includes both old
and new systems as components. [4]
System context diagram for the integration architecture is depicted in the figure 4.6.
Messaging system gets the data from ISAIM system and pushes it into the data management
system. They are connected through the TCP/IP connector instances and
ports. The systems and data stores are pictured as components. Components interact
and exchange data through ports. Runtime view of an use case is illustrated by a system
context diagram. [4]
4.3.2.3 Internal Model
Informations which are not exposed by boundary models are described in Internal model.
In a high level view, boundary and internal model denotes similar results. Only the level
of information, that the model exposes in understanding the architecture, distinguishes
between them. Both models can be represented using components, connector instances
and ports. [4]
Component Model
As described previously, components are represented as systems and data stores. Components
interact and exchange data only through ports. They are connected using connector
instances. In the figure 4.7, the integration of maintenance operation is described.
The components of different systems send data via ports using the messaging system.
Messaging system acts as a middle man who exchanges information. Ports are distinguished
as read ports and read / write ports. Most of the systems provide data while
the other receives and stores data. Thus the different ports are used for appropriate
needs. [4]
Deployment Model
Nodes are the hardware systems where an application or software can be hosted or
deployed. Nodes play an important role in the performance. Clusters and Racks are
multiple number of nodes which help to decrease the load and increase the availability.
This prevents from system crash due to overload. Clusters are collection of hardware
nodes where the identical software is deployed on every one of them. In our integration
26 Chapter 4. Architecture Modeling
architecture, two different types of deployment is explained with and without fail-over
techniques. [4]
Failover technique enables to jump among the distributed surplus nodes in case of load
and to prevent the system from failure. Using this failover methodology, systems are
prevented from crashing. Availability of the systems for the user is increased. Roughly, a
well distributed system with failover techniques in place, can provide of almost 99.999%
uptime. This is nearly 100% uptime or availability of the system. [10]
In the figure 4.8, deployment with only ISAIM system is described. The other external
systems such as IDOLS, AIRNAV, AMAM, SPARE and Alerting System, possess
same configuration and characteristics identical to ISAIM in the deployment context.
So, the figure 4.8, is much understandable for the other systems. This deployment is
based on Apache Kafka which is a messaging system described in the section 5.3. As
described before, main components of Apache Kafka are message broker and Zookeeper.
Zookeeper and Kafka broker are distributed in single node each. However, the availability
is not considered in the process of this deployment architecture. In this project,
system availability using deployment architecture is analyzed later in the chapter 6.
4.3.3 Code Model
Code model is the representation of actual working system. Domain and the design
model helps in structuring and achieving the code model. Final output will only be the
code and not the designs and diagrams. However, code model will be successful only
when it aligns with the design model and architecture designs. Architectures and code
speak about the same stuff but in a different representations. Designs are just abstraction
which contains less detail and description about the system. On the other hand, code
has more specific details and it represents the real world results of the design. Apart
from just code, there are many small aspects in the code model that are needed to be
taken care of. For instance, the code are expected to be understandable and structured.
They evolve quicker than any tangled code. [4]
4.3.3.1 Architecture Styles
A common problem is often solved by a architecture style or a pattern. This prevents us
doing the same mistake again and again. It provides a way to reuse an existing pattern
or style. Difference between pattern and style is a big research topic. In the book "Just
Enough architecture" by George Fairbanks [4], the author explained both in detail and
made a conclusion that patterns and architecture styles possess common features. But,
patterns are applied in a low level than styles. Nevertheless, Architectural patterns and
architectural styles are substitutable and almost represent same things. [4]
Styles related to messaging system are discussed predominantly here as it is concentrated
towards the success of the system. Conventional messaging system has two type of styles
4.3 Modeling 27
such as Queuing and Publish-Subscribe. A detailed explanation can be found later
in this chapter about the above mentioned styles for messaging system. [11]
4.3.3.2 Queue
Connection between a messaging server and a client is often called as a Queue. The
process of connecting using a separate channel for each customer or a client is called
Queuing. There can be more than one client for a messaging server and a router. Multiple
clients receive messages which are meant for them. The clients are tracked using a client
id. This acts like an address to a person in the real world. The mails are delivered to
a particular person by using a specific address known. Messaging system works very
similar. Using that unique id, messages are sent. Queue is similar to point-to-point
communication which is detailed in the figure 5.3. [11]
4.3.3.3 Publish Subscribe
In this project, Publish-Subscribe is being used for data transmission from source to destination.
As described previously, Apache Kafka is used for the development of message
oriented middleware. When there is more than one client or a group of clients receive
a same message, then the message is sent or published to that group of clients in a
common channel. On the other side, clients subscribe to the particular channel where
they will get messages. A detailed figure 5.4 describes clearly.