Software Architecture

Model Driven Architecture Approach

3 Day(s)

🎯 LEARNING OBJECTIVES

Understand the principles and benefits of Model-Driven Architecture (MDA).
Distinguish between Platform-Independent Models (PIMs) and Platform-Specific Models (PSMs).
Explain how model transformation and code generation support software development.
Evaluate the benefits and limitations of model-driven development for different projects.

🧠 PREREQUISITES

Basic understanding of software architecture and object-oriented programming.
Familiarity with UML diagrams and software modeling concepts.

📖 Topics / Lesson

1.Problem statement

2.Architecture challenges

3.Components Generation: When To Create Component?

General Approach

Architect for Reusability

Over Engineering

4.UML models and architecture

5.Solution architecture modeling

6.Wrong Practices in MDA using UML

7.Software Architecture Pitfalls

9.Architecture levels

10.MDA And estimation

Video Sessions

Research References

MDA: Model Driven Architecture

1.Problem statement

Most of #softwarecompanies have a critical issues regarding their solutions(legacy and new one), the core source of revenue stream, and always are looking for experts that can lead the #developmentteam to resolve these challenges.

As a simplification of the problem, challenges can be mentioned briefly as following:

1. What is the existing solution building blocks?

2. To which level the solution #asis model is compatible with the expected one?

3. Do we have the correct relationships between solution building blocks?

4. Do we select the correct technology for building the solution?

5. Did solution be built with consideration to quality attributes?

The same problem statement can be applied also on new solutions.

We will tackle the concepts of software architecture. From the mentioned problem statement.

Software Architecture is the fundamental organization of a system into components and relations between them and the working environment, considering the quality attributes (Performance, availability, usability, security, and adaptability), and enhance developing pattern solutions-repetitive solution development tasks.

We have the following elements:

Solution components (building blocks)
Components relationship
Deployment model of the components
Relationship between nodes
How to consider quality attributes in architecture

Component can be:

Business Component, according to business decomposition
Technical: According to infrastructure reusable components that is result from scanning different operations (Security, Caching, Reporting, DAL)

Node can be:

Client machine
Server machine
Smart device (Mobile and TV)

So, Why We need component diagram?

1. Design clarity

2. Standardization

3. Planning clarity

4. Drilling down the composition

5. Reveal hidden facts

6. Clear sizing approach

Component implementation approach?

You have two approaches to creating reusable components:

Business component: Create reusable components with the same source code nature(OOP) in case you have
Cross-cutting Technical Component: like logging, security, and caching, Use Aspect-Oriented architecture development approach,

2.Architecture challenges

Software architecture is the process of determining the solution building blocks, relationship between them, and its relationship with the environment

The challenges:

1.How can we detect/find (reusable components) the solution building blocks?

2.Which technology/tool to build it with?

3.And what are the objectives of reusable components?

Regarding the first challenge, no more time to waste in building #SRS and more documents

Immediately shift your mindset to #MDA( model driven architecture), which you should represent your solution in models, in all #sdlc and solution elements

Then you should have 2 types of #components:

1. Business components ( include the implementation of business requirements ), which the current #ddd (domain driven design) is focused on

Ex:

PayrollMdl: payroll component

AccPayable: account payable component

2.Technical components (include component or more for each operation type within the system)

Operation types: like

CRUD Operation component, like DAL (Data access layer)
Reporting Component
Logging Component
Database administration component
Security operations

You will need one or more for each

#UML is the best fit for building the models, that support architecture modeling and take decisions before implementation.

Why We need reusable components?

Reusable components is totally independent that detecting normal solution building blocks, where your are looking for the following perspectives:

How to decrease solution cost, by buildig components once, and reuse it every where
By keeping high maintainability, since you maintain at one place, and solution cascaded everywhere

3.Components Generation: When To Create Component?

General Approach

We can create components on the following cases:

When reusability probability found, make it component.
When it’s hard to do, do it.
When you want to classify and organize your outputs

Otherwise, You are over-engineering your product.

Decompositions approach:

Good decomposition should provide the following:

Single responsibility
Cohesion
Completeness
Reusability

Architect for Reusability

You should scan your solution for repeated operations types like the following, to create reusable components:

- - CRUD Operation component, like DAL (Data access layer)
  - Reporting Component
  - Logging Component
  - Database administration component
  - Security operations
  - Caching
  - Payment

You will need one or more for each

Over Engineering

You should take care from the over engineering that leads you to extreme expected reusability rather than rational one, so derive your reusability levels from your engineering strategy.

You can eliminate over-engineering by the following checklist:

Prove of use: Same module vs other solutions and cross program
Value demonstration: What will be the value on cost/quality/and delivey time
Avoid Wrapper components: do not create modules for just delegate calls to others
Prevent fragmentation: keep each function encapsulated

4.UML models and architecture

There were two #myths about #UML that lead to crises on most of the solutions:

1. UML is an overhead on the project

2. One of #Agile values is working software over comprehensive documention

Both #myths lead to fast delivery wothout consideration to sustainability of the solution, maintainance and rework cost, in addition, bad #management attidute that was focused only on quick wins.

As we have a proposal, well formulated as user stories, from this poiny we can model the solution from 2 perspectives:

1. Business architecture using #OOA models

2. Solution architecture using #OOD models

While #OOA models focus on the representation of what to do, the business requiremente, ##OOD focus on how to do, the design elements of the solution

from different perspectives, We will have two views of the solution:

1. static views: which will describe the solution objects

2. dynamic views: which will describe the interaction and collaboration between objects to achieve the solution objectives

5.Solution architecture modeling

As We mwntioned, solution architecture is a systematic approach, in addition, it required a talented technical hero with innovative mindset.

The architecture systematic approach is looking to formulate the archotecture by answering the following seven questions, followed by its answers:

1/7 How shall we model business architecture?

- use #activitydiagram model to represent solution workflow

- Use #usecase model to represent each requirements group

2/7 How shall we model the business work flow?

- Use the #activitydiagram model to represent each #usecase wotkflow

3/7 How shall we model solution building blocks?

-Collect all mentioned nouns in the #usecase models

-group correlated domain models and expected classed in named module/component

-Finalize all its related attributes and operations, that will be used later in design realization phase

4/7 How shall we model different objects states and its all transitions?

The remaining three questions will be mentioned in the next post ISA.

4. How shall we model different objects states and its all transitions?

-In order to represent object states, we use the #statechart diagram, all states should be driven by the previously determined #usecases

5. How shall we model the interaction between solution building blocks?

-In order to represent the interaction between different objects, use the #sequencediagram model, by placing the objects and set the messages between them

6. How shall we represent the destribution of solution building blocks over the working environment?

-After packaging the final deliverables(services, DB, configuration files, ext), you should define what component, where to be delivered, and on which sequence and procedure using the #deploymentmodel

7. How shall we assess the hardware configuration and SW configuration?

-According to enterprise vison, solution scale, and technical architecture, the hardware and software configuration can be settled, for example, if the enterprise has a vision to create #SaaS solution, cloud architecture should be applied, with different DB design.

6.Wrong Practices in MDA using UML

We can mention here in this subject the Top 10 Wrong practices while applying MDA using UML:

1. Partial implementation of the models Analysis/design/infrastructure

2. Absence of models landscape that simplify the presentation of solution models

3. Absence of transformation approach between model (Architecture context, analysis, design), which means that teams are working in silos, no tracability and relationship between the models

4. Incomplete Models: Insufficient and incomplete models make team move to the final source code, and then the objective of having models come none

5. Absence of relationships with applied patterns

6. Absence of relationships with applied non-functional requirements

7. Absence of relationships with applied digital transformation drivers

8. Absence of reporting for the tracability matrix that support the governance and assuring the completeness and consistency of the models

9. Over-engineering Modeling: complex models that are difficult to understand, maintain, and implement. The goal of MDA is simplicity and abstraction, not unnecessary complexity

10. Using non-standard models and shapes within UML models

The bonus one 👌👌👌 is the most important practices, which is:

Absence of using composite models, which enable you to architect, simplify and slice models

7.Software Architecture Pitfalls

Pitfalls of software design:

1. Over engineering

2. Under engineering

3. Absence of modularity

4. Absence of usability

5. Absence of performance consideration

6. Absence of security consideration

7. Absence of scalability

8. Lack of documentation

9. Absence of design patterns

10. Absence of architecture governance framework

9.Architecture levels

Architecture levels (Enterprise, solution, technical) and technology selection

We have mentioned a set of practices on how to model your architecture.

In this episode, We will go deeper on fifferent architecture levels.

We have three levels of architecture:

1. Enterprise level : Regarding the organization vidion and strategy, for example , our vision is to build #SaaS model, this vision will be cascaded to platform selection, technology selection, and even solution implementation approach.

2. Solution level: inherited from the enterprise architecture, with level of flexibility on the solution level, and its modules

3. Technical level, depth focus on the detailed of modules building ro class levels.

We can say: the existance of these levels will accelerate your strategy towards achieving organizational objectives, while the absence will lead to a solution, the son of development team, but not the son of the organization vision, and here is the crise.

10.MDA And estimation

One of the core values for using the MDA, is the accuracy of estimations, as you will have the visibility for the following:

All objects
Missing Objects
Missing operations
Required/Missing integrations
Effort per each layer to achieve the business scenario over technical tasks
Detect expected response
Detect missed operations
SRP according to the communication
Integration layers
Reusable components
Composite structure
The execution time to do the sequence i. Rectangle, which indicate severity and application of defensive programming and logging