 |
|
Domain-Frontier Architecture
(New-age software development methodology)
Corporate software system development is a multidimensional puzzle. Domain complexity, business rules, technology diversity, existing system structure, overall scale, number of stakeholders, everlasting changes are some of those dimensions. In order to resolve the puzzle, software teams need new development paradigm.
|
Software development nowadays
Two main problems of modern software development are:
- inadequate abstraction management, and
- lack of development tools
Those two problems are strongly coupled and together they form a "knot" which makes almost impossible some significant improvement in the software engineering. In order to "untangle a knot", one of those problems have to be resolved first.
While the abstraction level of the systems under development has risen significantly during the last 20 or so years, the software engineering methods have not followed this tendency. Instead of developing system drivers and applications for common use (text editors, spreadsheets, etc), over 95% of the software built today falls into very abstract category of "corporate" software. On the other hand, software teams use practically same methodologies and similar textual programming languages.
|
|
Abstraction Management
New methodologies and new software tool generations always build a higher abstraction wrapper around the previous ones, making some of their important features "disappear" from the developer's point of view.
Same happens with Domain-Frontier Architecture. A simple example is data base. As a technology-need and not real-world concept's feature, it is left behind to automatic compilers and generators.
|
The one and only "formal" software development tool is still a standard compiler (Java, .NET, etc). Software teams are bound to corresponding IDEs and forced to resolve the previously mentioned software-puzzle by writing textual source code! There is no formal way either to separate concerns or possibility to look at the problem from a higher abstraction point of view. |
If there would be a formal tool which separates developer from the source code, the "knot" might start to untangle.
Domain-Frontier Approach
Domain-Frontier Architecture defines an abstract view of a software system, created with a clear aim to formally separate concerns in its development process:
- Functional from non-functional features
- Analysis from design
- System logic and business rules from user interaction/navigation logic
Functional vs. Non functional separation. Developers first need to know WHAT the system is supposed do, and later to think about HOW it is going to do it. If those two concerns are not formally separated by a tool, developers naturally dive into programming, mixing everything in a "source code stew".
Analysis vs. Design. The traditional A&D phase must be finally broken! Analysis deals with understanding and formalizing the problem, and design resolves it in a light of available technology and resources. Those two concerns are a way to different and widely separated in a modern, large-scale development.
System logic vs. User interface. User interface is a "needed evil" of a software system. Users need it only to extract the useful information from domain logic. No business or system domain itself contains user interaction logic. They must be formally kept apart from the beginning, not only from the application structure point of view (like in 3-Tier architecture or MVC design pattern).
The following scheme represents Domain-Frontier Architecture:
Every system can be logically decomposed in following parts:
- Domain: concepts of system logic, their relationships, attributes business rules and behavior
- Frontier: Presentation of information and user navigation logic, access to Domain
- World: system users and external systems
This extremely simple model is a starting point for new-age software methodologies and platform-independent software architecture.
Enterprise Analyst
Enterprise Analyst is a software development tool, based on UML, MDA and Domain-Frontier Architecture, implementation-technology free, which permits:
- Domain modeling, using Class and State diagrams, as well as Operation implementation
- Frontier modeling, with Use Case diagrams
In Enterprise Analyst, the Domain structure is modeled separately from the Frontier structure, to
build a functional system prototype in an early development phase, before having to resolve non-functional aspects, such as development platform and implementation languages, data bases, security, etc.
After having the model fully composed, it can be formally tested and adjusted, before beginning expensive tasks like implementation and systems testing.
In the near future, Enterprise Analyst will introduce use case execution and UI prototype generation feature.
The final idea is to come up with full code-generation features.
Untangling a "knot"
With Enterprise Analyst (EAn) and Domain-Frontier approach (DF), the previously mentioned "knot" can be resolved. Developers finally have a tool which FORCES them to think different way and to tackle a highly complex software development project concerns in a proper order.
EAn and DF naturally draws a line between functional and non-functional system features, between system logic (domain) and user interface (frontier) and of course between the Analysis and Design phases.
With EAn and DF the analysis phase ends with an executable product, with a final system prototype, which can really be tested even by end users. An approval of this prototype is a new milestone is a software project.
With EAn and DF the software project is broken in two and the overall risk is drastically reduced, due to an early agreement on all the user-relevant aspects. There is no need to invest in technology, implementation, programmers, data-base design, testing, hardware, etc, etc. before having resolved all the major project concerns.
EAn and DF make software development real engineering!
|
|
|
|
|
