Software Development evolution

1. The code-centric development:

It refers to an approach in software development where the primary focus is on
writing and maintaining code. But it would not support the analysis and
design activities by means of modeling.

2. Model-driven development:
It is about distinguishing between computation-independent and technology-
specific issues being reflected in corresponding model types. This is a viable
“bridge” between the “Software World” and the “Real-life World” .
But the lack of sufficient development flexibility as well as the insufficient
capability to conveniently adapt modeling to changes has justified the need for
new development paradigms.

3. Agile development:
It is based on iterative development and the continuous feedback, where
requirements and solutions evolve via collaboration between self-organizing
cross-functional teams.
Model-Driven Engineering
Model : In real life, we establish that the human mind would often “rework” reality, simplifying things, driven by an
intuitive “push” to identify similarities among objects, emphasizing those similarities in perceiving different objects

For example, both the “small Mitsubishi Colt” and the “big Cadillac Eldorado” are intuitively matched to the “car”
model by a person, firstly,(1),(2) and the huge differences between those two objects go on second place(3),(4)

(1) pointing to the capability of finding the commonality in many different observations(Abstraction)
(2) People often generalize properties of real objects (generalization)
(3) classify objects (classification)
(4) group objects into more complex objects (aggregation).

• “ABSTRACTION RELATES TO MODELING”

• A model is a simplified and/or partial representation of reality
• Models can be used to describe reality, reducing complexity , determine the scope, and details at which to study a
problem , and so on. Through modeling, features of products can be analyzed and discussed before the
corresponding products get produced.
The need for model-driven engineering ?

1. Software is becoming more and more complex, and therefore they need to be discussed at different
abstraction levels, depending on the profile of the involved stakeholders, phase of development, and
objectives of the work.
2. Software is more and more pervasive in real life, and the expectation is that the need for new pieces of
software or the evolution of existing ones will be continuously increasing.
3. Software development is not a self-standing activity: it often imposes interactions with non-developers
(e.g., customers, managers, business stakeholders, and so on) who need some mediation in the description of
the technical aspects of development.

“So, by applying model-driven engineering, software developers increase efficiency and effectiveness”
Requirements & Approach of model-driven engineering
Model-driven engineering use models to describe requirements and system design, and then
directly transforming these models into executable code that fulfills those requirements. The idea
here is that models are not just a means of documenting requirements or UMLs but are equivalent
to the code itself. for example, a car order that includes customer features is straightforwardly
reflected into reality, in the context of a current advanced automotive production line So, it aims
to find domain-specific abstractions and make them accessible through formal modeling.

To successfully apply this, three requirements must be met :

(1) Domain-specific languages are required to allow the actual formulation of models.
(2) Languages that can express the necessary model-to-code transformations are needed.
(3) Compilers, generators, or transformers are required that can run the transformations to
generate code executable on available platforms
We can summarize this into three types of models:

Example: Food order management system

1. Computation-independent models:
it capture adequately the domain features, abstracting from any computation and technical details; such models would
ideally capture the as-is situation, featuring a Blackbox view over the software system-to-be. (receiving orders, preparing
orders, and delivering orders without detailing how payments are processed or how service providers are communicated)

2. Technology-independent models:
it focus on the system-to-be (maybe both functionally and constructionally) but just conceptually, not imposing any
technical restrictions whatsoever.(describe the user interface for logging in, selecting items, and selecting a delivery location
without going into technical details)

3. Technology-specific models:
capture adequately all technical features of the software system-to-be, which models are straightforwardly reflect-able to
corresponding code.(describe specific technical details such as using the React Native library to build the UI.
Model-Driven Architecture (MDA)
 Two modeling facilities are meeting those “requirements”, namely, the Model-Driven Architecture (MDA)
and the Open Distributed Processing Architecture (ODP), with MDA’s adopting influences from ODP

 Model-Driven Architecture (MDA) is a software architecture framework consisting of a set of standards that
assist in “system creation, system implementation, system evolution, and system deployment”

 The key MDA technologies are UML, Meta-Object Facility (to be considered in the following sub-section), and
the Meta-data Interchange –XMI

 It has three-layered approach:

• Computation-Independent Model (CIM): describing a system from the computation-independent point of

view, to address structural aspects of the system. “high-level”
• Platform-Independent Model (PIM): defining a system in terms of a technology-neutral virtual machine or a
computational abstraction. “defining system functionalities, structure, and behavior”
• Platform-Specific Model (PSM): capturing the technical platform concepts and geared towards
implementation. “specific technologies, frameworks, and platforms”
 We consider enterprise modeling to be
computation-independent, with no focus on the
(partial) automation of business processes—this
corresponds to the CIM layer. Further, we consider
application modeling from a platform-
independent perspective, with no focus on the
specific technological platform(s) on which the
application components are (to be) implemented
—this corresponds to the PIM layer. As for the
PSM, it is specific about J2EE, .NET, or other
implementation platforms. A platform-specific
model is created from a platform-independent
model via a model transformation.

A taxonomy of the models that play a central role in MDA

Meta-Object Facility
 It provides an open and platform-independent meta-data management framework and associated set of
meta-data services to enable the development and interoperability of model-driven and meta-data-driven
systems.

 Examples of systems that use MOF (modeling and development tools, data warehouse systems, meta-data
repositories)

 It has four meta-levels ) These levels help define the relationships of the models and determine their structure
and concepts(

• (M0) —Instance “Data”

• (M1) —Model [ EX: a class is given the name “Person” and has a number of attributes “surname” and “first
name,”]
• (M2) —Meta-model [Construct Class: M1 models are instances of the elements of the meta-model & the
MOF serves to define modeling languages e.g., UML]
• (M3) —Meta-meta-model
• Models can be located at different
abstraction levels even though they can be
located at the same meta-level, for example,
CIM, PIM, and PSM

• Transformations are used to map models at

a higher abstraction level to models at a
lower abstraction level

• If we take the PIM-to-PSM transformation

(where we reflect the higher abstraction
level model PIM to lower level PSM), we
stay at the level because no matter the
abstraction level, both PIM and PSM
represent models. Each of those models thus
has a corresponding meta-model (at the
level): the PIM is an instance of the PIM
meta-model and the PSM is an instance of
the PSM meta-model. In turn, both meta-
models are instances of MOF, MOF being
positioned at the level.
Infrastructures evolution
• Mainframe Infrastructure:
is based on a mainframe and terminals. A mainframe can be looked upon as a
“giant server” since only it serves “dumb” terminals; a terminal has no
drives, no independent operating system, and so on—it has just a screen and
a keyboard. Any information changed or added from a terminal would
change the data in the mainframe accordingly

• Client/Server Infrastructure:
infrastructure assumes the partitioning of tasks or workloads between the
providers of a resource or service, called servers, and service requesters,
called clients. those principles are underlying about current “distributed
computing environments”. But this nfrastructure is not “outside”

• Cloud infrastructures:
infrastructures assuming the provision of shared computer processing
resources and data to computers and other devices on demand. So, it become
underlying about current mobile computing environments.
Cloud Computing
 Consolidated enterprise-IT solutions have proven to enhance business efficiency when significant fractions of
local computing activities are migrating away from desktop PCs and departmental servers and are being
integrated and packaged on the Web into the computing cloud. Instead of investing in and maintaining expensive
applications and systems, users access and utilize dynamic computing structures to meet their fluctuating
demands on IT resources efficiently and pay a fixed subscription or an actual usage fee.

 There are usually Three cloud service models under consideration:

1. Software as a Service (SaaS):
SaaS moves the task of managing software and its deployment to third-party services, such as security services,
caching services, networking services, and so on.
2. Platform as a Service (PaaS):
PaaS functions at a lower level than SaaS, typically providing a platform on which software can be developed
and deployed, such as streaming platforms, application development platforms, web platforms, and so on.
3. Infrastructure as a Service (IaaS) / Cloud provider:
IaaS in turn comprises highly automated and scalable computing resources, complemented by cloud storage and
network capability which can be self provisioned, metered, and available on-demand, such as e-mail building
blocks, ERP building blocks (“ERP” standing for “Enterprise Resource Planning”), CRM building blocks
(“CRM” standing for “Customer Relationship Management”), and so on.
• The cloud provisioning is bottom-lined by a (SaaS-PaaS-
IaaS) basis and reaching out to customers via the
Internet, such that the customers’ computers, servers,
databases, mobile devises, and so on. They can benefit from
corresponding cloud services that are in turn utilized by
customers in the form of images, news, music, chat
facilitations, ID management, TV, and so on.

• Customers utilize cloud services at high level, in an

intuitive and seamless way, such that the underlying SaaS-
PaaS-IaaS-related technical complexity remains hidden
and would only become explicit for the customer as
reflections in corresponding (subscription) contracts.
Aspect-Oriented Software Development
Let's say you have a school application that allows students to log in, view
their schedules, and send messages to teachers. One important issue is
security, as the application needs to be secure to protect student data.

In traditional development, you might write security-related code in each

part of the application separately. For example, you might add user
authentication on the login page and data encryption on the messaging page.

But with aspect orientation, you can isolate security requirements into
separate aspects. For instance, you can create a security aspect that
contains all the code related to user authentication and data encryption.
Then you can integrate this aspect into all parts of the application that
require security, such as the login page and the messaging page.

This way, security is effectively achieved without the need to repeat code
throughout the application. Thus, aspect orientation allows you to address
non-functional issues like security in a way that aligns with the functional
requirements of the application.
Aspect-Oriented Software Development

 For enterprise systems and EIS

Privacy, transparency, traceability, and so on are labelled values that are to be weaved in the functioning of
enterprise systems and EIS, and for this reason, they are considered as cross-cutting concerns because:

• Weaving them in the functioning of a system would not assume reflections in one component only; instead,
multiple components would need to be “re-factored” as well as their interrelations, and their relations to other
components.
• Addressing such values in the software development context would come through all the phases of the software
development life cycle.

Further, such values / cross-cutting concerns have a non-functional essence because they do not have any particular
purpose or function; instead, they represent something like “desired system qualities.”

Finally, even though the values / cross-cutting concerns are non-functional, we should find functional solutions for
them, because we argue that a system could only functionally achieve effects with impact on its environment.
 For software systems:

• it is about crosscutting concerns that are particularly touching upon software development issues, such as
security, distribution, recoverability, logging, performance monitoring, and so on

• That addressing such non-functional concerns is to be functional which means that:

• We should “translate” those concerns into system requirements.

• System development should not go in any unusual way; it should just ensure that all requirements are
properly reflected in the design and implementation.
• Introducing metrics and/or performance indicators would be necessary for establishing how well the
desired values have been reflected in the performance of the system, and if it is necessary, the
requirements may have to be refactored.

So, Aspect orientation is thus necessary for properly weaving desired values in the functioning of the
system-to-be. It is featuring non-functional issues that nevertheless have to be resolved functionally.
Thank You !