connected - Services: Software engineering
«A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.»
Antoine de Saint-Exupéry
For more than a decade our understanding of system architecture and design has been informed and guided by software engineering theory, concepts, and methodologies:
- Model-driven architecture and engineering
- Increases productivity by maximising compatibility between systems via re-use of standardised models.
- Simplifies the process of design via models of recurring design patterns in the application domain.,
- Promotes communication between individuals and teams working on the system via a standardisation of the terminology and the best practices used in the application domain.
- Domain-specific models and languages
- Dedicated to a particular problem domain, problem representation, and/or solution technique.
- Supports higher-level abstractions than general-purpose modeling.
- Requires less effort and fewer low-level details to specify a given problem domain.
- RESTful web services
- Scalability of component interactions.
- Generality of interfaces.
- Independent deployment of components.
- Intermediary components to reduce latency, enforce security, and encapsulate legacy systems.
In pursuit of code quality: design principles and coding standards
In our search for better ways of writing high-quality, maintainable, and testable code we have adopted coding standards that comply with our design principles:
- Separation of Concerns principle
a technique to separate aspects of a subject matter into well-defined layers, allowing in-depth study and focus on one aspect at a time in isolation from others for the sake of its own consistency. Examples of aspects are:
- Separate 'what is to be done' from 'how to do it'.
- Separate content from form, presentation (view) from business logic, data processing, and database access (model).
- Use modular design to separate program classes into distinct features that overlap in functionality as little as possible to achieve encapsulation, that is, information hiding and transparency of operation.
- Dependency Inversion principle
to avoid and untangle tightly coupled code:
- Objects should dependent upon abstractions and not upon implementations,
- High level modules should not depend upon low level modules. Both should depend upon abstractions,
- Abstractions should not depend upon details. Details should depend upon abstractions.
- Don’t Repeat Yourself principle
to allow modification of any single element in a system without changing other logically-unrelated elements:
- Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
What is Good Software Design?
We consider software that exhibits any or all of the following traits as bad design:
It is hard to change because every change affects too many other parts of the system
When making a change, unexpected parts of the system break
It is hard to reuse in another application because it cannot be disentangled from the current application
We consider software design as good, if it exhibits none of those traits, i.e. is flexible, robust, and reusable.
Our software engineering practice aims for a systematic best practice approach to development, operation, and maintenance of software, covering the following disciplines:
- Distributed systems architecture, design, interfaces
- Application design, development
- Application security
- Data modeling, mapping, conversion
- Database design, administration, query optimisation, performance tuning, database conversion
- Data analysis, reporting, data warehousing, extract-transform-load development, data capture, conversion, cleaning, migration
- Quality assurance testing, implementation
Email - none provided
Print this page