Software Architecture

Introduction to sw architecture

What is MDA?


MDA means model driven architecture, a new approach of formulating software requirements and technical specifications in graphical representation, which leads to higher understanding and les confusion about product to be built.


It consists of the following models types, each type is a pre-requisite to the next on:

CIM, PIM, PSM, then the code is the realization for all previous models.







Practice

Reference Standard

Benefit

Benefits Of MDA


1. Visual Representation

- Relationship between actors and business

- Business decomposition

-What deployment nodes required

- Relationship between components, nodes and connected devices, usng deployment model

- Different solution object states  and related events, using statechart diagram

- Process flow, using activity diagram

- Technical solution flow for internal and external use(integration)

2. Improved Communication

3. Requirements Clarification (Analysis Models)

4.Design Documentation

5. Design Validation and completeness

6. Design Reusability

9. Reverse Engineering with no visiting to the code

10. Project Management and estimation enabling

11. Standardization

12. 360 degree modeling






The following session presents the different types of UML models, and the flow of generating the models from each others.

Architecture episodes

episode 01 : 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:

Component can be:


Node can be:


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:

episode 02 : Architecture challenges

Software architecture is the process of determining the solution buding 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 (domaim 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 

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:



When To Create Component?

We can create components on the following cases:

Otherwise, You are over-engineering your product.

Decompositions approach:

Good decomposition should provide the following:


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.

episode 03 : 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


episode 04 : 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.

episode 05: Solution architecture modeling Cont

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. 

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:


Expected Activities for Assessing the effort from architecture perspective

1. New micro-services

2. New classes

3. New APIs

4. New schemas

5. New tables

6. New database objects

7. New integration

8. POC

9. New MDA models

10. Code quality activities

11. FE page

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

MDA governamce approach

One of the key feature to be used in software engineering, and can't be achieved without using the MDA tools, is the relationship matrix, which used to validate the models.

In Enterprise architect tools, one of the key features, is the relationship matrix, which you can select the source object (use case as example), and target object, and the relation type and direction between them. 

Using the relationship matrix can provide the following capabilities for engineering team:

1.      Relationships between objects over all models

2.      Inconsistency between models

3.      Irrelevant objects.

So, you can determine as example the following:

1.      The missing implementation, like which digital transformation drivers (represented in requirements) are still not implemented within the components/micro-services.

2.      The missing implementation, like which digital transformation drivers are still not implemented within the components/micro-services.

3.      Relationships between actors(Business users)

4. Actors Vs Actors relationships, which show you the different levels of actors and their authorities for performing actions more than normal employees

5. Devices Vs Nodes, Which show you which devices connect to your solutions nodes, which will be used for service providing and integration purposes, and find missed scope


episode 06 : 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. 

episode 07: Architecture validation process

#softwarearchitecture validation process


previously, We have focused on the architectutre process, from start to end.


But, We have a set of challenge that face the architecture:

1. How shall we guaranttee the completenes of architecture models

2. How shall we guaranttee the #softwarequality of the models(next episode)


Regarding the completeness of the models


1. Solution journey should be represented using activity diagram, and reviewed with top and mid management level


2.All #usecases should be inherited from main solution scenarios, and reflecting #userstories


3. All #usecases should include pre-conditions, post-conditions, and all #usecases alternative scenarios


4. Process of collecting static models from mentioned names in the use case models, with consolidation and abstraction for correlated objects


5. Then packaging them in suitable correlated components according to #SRP approach, including also the communication responsibility to other parties(internal/external components for integration)


5. Clear definition of the components, #deployment for each component should be configured clearly, and documented


episode 08 : Architecture and quality attributes

We will cover the role of quality attribures in solution architecture.

Quality attributes in software architecture represents the question :"How should the system deliver the business requirements and guatantee its qualities?".

Since we achieve this level, we can't accept narratives about quality attributes without its consequences on architecture.

As an example of architecture quality, we canentikn the following as an example:


• Performance

• Interoperability 

• Usability 

• Reliability 

• Availability

• Security

• Maintainability 

• Modifiability 

• Testability

• Scalability 

• Reusability


In each of the above mentioned, #solutionarchitecture should provide:

1. Solution for each attribute, like caching component for performance


2. Component for each factor, like securiry module at all level.


3. Standards and approaches for each factor, like #OWASP for security


Finally, quality attributes and its consequences on architecture is challenging, as sometimes, we can have a contradiction between these attributrs, like usability, and security in bank account recovery as example.


episode 09: Pattern Vs Anti-Pattern approaches

Pattern vs anti-pattern approaches

The pattern is a solution for a specific problwm within a context.

We have a lot of patterns/standards/approaches regarding:

1.Layered architecture: to for the connectivity between solution building blocks, like tiers, how many tiers should we have, and why.

2.Components types: like com objects, portable components, SOA, Micro services architecture

3. Communication between components ( queueing, callbacks or event driven)

4.Solution design patterns to resolve specific problems

5. Database design, relational and non relational


With all of the above mentioned patterns, supported by researches, and scientific reviews, we have anti-patterns approach that stick to find the solution his way.

This is a great debate, but we should respect considering the following conditions:

1. You should be aware of what you are againest

2. Understand/appreciate That patterns is the contribution of researchers to support the community

3. Proof your new provided solution to yourself and then to the market.

4. It's not enough to make things work, you should go deeper after details in order to meet/exceed pattern oriented approach.

episode 10: Refactoring and reverse Engineering the models

in order to make reverse engineering using MDA approach, you should do follow one of the following strategies:

Focusing on finalizing business journey, from all models, static and dynamic models, Analysis and architecture models, So there is a collaboration between the team members within the agile SQUAD to deliver mature models.

Benefits:


Focusing on finalizing business journey, from all models, static and dynamic models, Analysis and architecture models, So there is a collaboration between the team members within the agile SQUAD to deliver mature models.


Benefits:


episode 11: Refactoring as a process

Focus on reverse egineering

1. Why solution is deployed this way...with focusing on: product technical requirement and non functional requirements 

2. What is the solution building blocks...from w perspective...business modules..product components...reusable components...enterprise architecture 

3. What is the relation between building block...and does it meet non functional req 

4. Determine each building block that meet sysrwm requirements 

5. Determine business solution architecture...wirh mapping to each component

episode 12: Data Architecture

As a process you should do the following:

1. Database informal design rules

-Semantic(Naming convention)

Use suitable naming convention for both attributes and relations, also it should be cascaded to all database objects, like indexes, functiins and triggers.

-Data redundancy and anomalies problems: 

Do not merge relations in one relation as it will leads to insert/update/delete anomalies

-Null values Tuples

-Spurious tuples(fake joins) 


2. Database formal design (Normalization forms)

Functional Dependency is a relationship between two attributes. This represents the relationship between the primary key and non-primary key attributes. An arrow denotes a functional dependency. 

1NF : atomic, multi valued columns, repeated griups, no composite keys

2NF: Remove data depends on partial key

3NF :Remove data depends on non-key attribute 

BCNF : keys depend on non-key column

4NF=MVD split tables with multi value dependency like (customer vendor item)

5NF=Assure non data loss 


3. Query simplification techniques

 like Views, CTE, stored procedures, stored functions

4. When to create index

5. Non relational database : when, why and how

6. Realtime database, for real-time databases updates and notification models

As the business may need immediate update to relevant, you should do the following:

- Notification

-Realtime database that support them type of operations, like firebase real-time database

7. Big data application for mega models

episode 13: Event Driven Architecture

What is Event?

Significant change in state, for example: Car is marked for Sold, if we sold it the status will be Sold and not available.


How EDA works?

Component interact with others throw invoking events.

Other system components can register to the component as interest of receiving events, that what we call "implicitly".

It provides reuse components, since it decreases the coupling between components.

EDA Elements?

•You have the following elements in the model:

•Publisher

•Event bus

•Event

•Subscriber

•Event response

Benefits Of EDA?

-Because it’s my responsibility to notify others by internal changes

-Decrease coupling

-Simplify solution

-Real time notification, not batch execution

episode 14: Architecture Scale

Software Architecture scale can be differed according to the following factors: 

We will discuss them in depth in the following sections.

episode 15: Key source code metrics

episode 16: Software Architecture Pitfalls

Pitfalls of software design:

episode 17: Software Developer Vs Software Engineer

Most of companies use the two terms interchangeably.

In fact,

While Software Developer Focuses on Coding and implementation.


Software Engineer Focus on:

1. Engineering practices and standards👌👌👌

2. identification of technology landscape👍👍👍

3. High-level architecture modeling✌️✌️✌️

4. Detailed design✈️✈️✈️

5. Right-Fit design patterns

6. Right-fit design principles

7. Application for non functional requirements, modularity, and reusability of the solution


Software engineering are mostly required in product-based and large enterprises, instead of small and operation-based enterprises, which they have the room for applying mentioned practices.


So, if your focus is only to implement what required with no consideration to what we mentioned up in systematic approach, you are setting in the developer Zone.


As well, hiring software engineering mentality in small enterprises with no vision for growth may cause turnover issues as expectations will not be matched between calipers and enterprises.


Video liberariy

MDA at the scale Sessions

Research References