Essay:

Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

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.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/engineering/2016-2-18-1455798599.php > [Accessed 18.10.19].