Software Architecture Practices

Software Architecture Practices

• 1.
  SOFTWARE ARCHITECTURE SANTOSH BOTRE
• 2.
  WHAT IS ARCHITECTURE? •Software application architecture is the process of defining the structured solution that fulfill all the technical and operational requirement, which will optimized around all the quality attributes like performance, security and manageability. • It involves a series of decisions based on the wide range factors, and each of these decisions can have considerable impact on the quality, performance, maintainability and overall success of the application.
• 3.
  CONTINUE… • Software systemis composed of set of structured elements and their interface. • Collaboration between those elements and composition of these structural and behavioral elements builds the larger subsystems. • Keep in mind • Functionality • Usability • Performance • Comprehensibility – Dealing with all the elements • Technical constraints • Trade-off - Balance between two desirable but incompatible features.
• 4.
  WHY IS IMPORTANT? •Every complex system must be build on a solid foundation. • Failing to consider key scenarios, failing to design common problem ,or failing to appreciate longer term consequences of key decisions. This can put your application at risk. • Poor architecture leads to the unstable software. • Unsatisfied clients/businesses.
• 5.
  GOAL OF ARCHITECTURE •Design the flexible architecture to handle the natural drift that will occur over time in software and hardware. • Design the solution which will build the bridge between business requirements and technical requirements by understanding the use cases and finding the way to implement keeping various quality attributes in mind. • Design structure of the system by hiding the implementation details. • Cover all the use cases and scenarios • Handle both functionality and quality requirements.
• 6.
  ARCHITECTURE PRINCIPLES • Insoftware development now following the Agile methodology. • We don’t know everything upfront in order to fully architect the system. • Design will evolve during the implementation phases. • Create your architecture by keeping this evolution in mind so that it will adapt to the requirement which is not fully known at the start of design. • Key • Identify the fundamental modules/elements • Delay the design for the modules/elements which most likely to change. • No to assumption based decisions • Identify the risks • Rethink on the design with different conditions.
• 7.
  KEY PRINCIPLES • Separationof concerns – Divide the your application in to distinct features with little overlap in functionality as possible. • Single Responsibility – Each module should responsible for only a specific functionality. • Least Knowledge – A component should know very less about other component internal details. • Don’t repeat – Specific functionality should be implemented only once. • Minimize upfront design – Only design what is necessary.
• 8.
  DESIGN PRACTICES • Establishthe coding style and naming conventions • Prefer composition over inheritance • Understand the requirement and all possible use cases • Design before implementation • Keep the data format and communication channel consistent • Do not overload the functionality of a component • Keep crosscutting code abstracted from business logic
• 9.
  LAYERED-COMPONENT BASE ARCHITECTURE This isa pattern which will help to provide an abstract framework for a system. • Layered • Abstraction • Encapsulation • Clear defined functional layer • High cohesive • Loose coupling • Component • Reusable • Replaceable • Not context specific • Extensible • Independent • Service Oriented • Expose functionality as a service • Consume functionality as a service
• 10.
  THANKS…... SANTOSH BOTRE