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.
CIM: Computation Independent Model, focus on the business models
PIM: Platform independent Model,focus on the design models in abstracted approach
PSM: Platform specific Model, focus on detailed specification of design models according to the target platform
Practice
Reference Standard
Benefit
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.
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,
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
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
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
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.
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
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.
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
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
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
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
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.
#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
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.
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.
in order to make reverse engineering using MDA approach, you should do follow one of the following strategies:
Horizontal
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:
Mature models will be delivered
Rework effort reduced
Vertical
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:
Immature models according to learning curve
Rework effort increased
Faster model
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
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
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?
Reduce coupling, because it does not know the consumer of the solution
When you do notify others by your significant changes
When you need to listen for external components changes
Why Components do not ask itself?
-Because it’s my responsibility to notify others by internal changes
-Decrease coupling
-Simplify solution
-Real time notification, not batch execution
Software Architecture scale can be differed according to the following factors:
Platform (Desktop/web/mobile)
Connectivity (online/offline)
Integrations (Aggregation/EDA/Database level)
Business model (SaaS/provisioning module/B2B/B2C/social media integration)
Availability (cloud/dedicated/on prime)
Security (hybrid cloud/WAF/SSL/Encryption/OWASP)
Realtime operations (Realtime database/notification)
Communication (SMS/MAIL/PN/Geo-fencing)
Data volume (distributed DB/big data)
Data structure (Relational/ non-relational)
Scale (Micro-services/docker containers/kubernetes)
Response time (CDN/Caching/load balancing/Deployment nodes)
Feature based(data marts/data warehouse/MLAAS)
Sensitivity: backup plans/disaster recovery
Customer experience: social media accounts integration, e-payment gateways
We will discuss them in depth in the following sections.
Maintainability Index - Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability. For more information, see Maintainability index range and meaning.
Cyclomatic Complexity - Measures the structural complexity of the code. It is created by calculating the number of different code paths in the flow of the program. A program that has complex control flow requires more tests to achieve good code coverage and is less maintainable. For more information, see the Wikipedia entry for cyclomatic complexity.
Depth of Inheritance - Indicates the number of different classes that inherit from one another, all the way back to the base class. Depth of Inheritance is similar to class coupling in that a change in a base class can affect any of its inherited classes. The higher this number, the deeper the inheritance and the higher the potential for base class modifications to result in a breaking change. For Depth of Inheritance, a low value is good and a high value is bad.
Class Coupling - Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. For more information, see Class coupling.
Lines of Source code - Indicates the exact number of source code lines that are present in your source file, including blank lines. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5).
Code coverage.
Response time.
MTBF: The average time it takes alive between each failure.
MTTR: Mean time to repair, how much it takes to resolve the issues
SaaS provisioning time : how much it takes to create new instance
Fault- tolerance: to which level there is an isolation and modularity, that prevent the spread of negative impacts on the overall system when part of it fail, so if a module failed, the others are still working.
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
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.