Loading in 2 Seconds...
Loading in 2 Seconds...
Software Architecture versus Software Design Suren K Poruri. Problem statement. Problem description . Causes of the Problem. The Need of Architecture ( Analogy 1) The Winchester “Mystery” House. 38 years of construction – 147 builders 0 architects
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
The Need of Architecture ( Analogy 1)The Winchester “Mystery” House 38 years of construction – 147 builders 0 architects 160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors 65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors No architectural blueprint exists
Construction Analogy 2 Architecting a house Built most efficiently and timely by a team Requires Architecture Well-defined process Power tools Can be built by one person Requires Minimal Architecture Simple process Simple tools Can be built by multiple teams/partners Heavy duty Architecture Complex process Sophisticated costly tools Architecting a high rise
Differences • Scale • Process • Cost • Schedule • Skills and development teams • Materials and technologies • Stakeholders • Risks
Architecture definition Design definition Design is structure/behavior of a module. Process structure UI structure Logic structure Data access structure Data structure
Car analogy Software Architecture Modules Modules Modules Interfaces Modules
Architecture scope • Navigation structure • Page structure • Maintenance • Transactions • Report • Validation structure – consolidation of client side validations across the system • Logging structure – What information need to be logged at a process level, layer level, module level • Exception handling structure – System /process/layer level exceptions • Use case/processs flow structure ( Presentation to business logic to data access layer) • Identification of unique use case flows. • Design patterns that we need to use? • Deployment decisions • Architectural style ( client/server, web , soa etc., ) • Layering decision ( How many layers, responsibility of each layer, Layer interfaces etc., ) • Business objects representation ( EJB, Pojo, etc., ) • Database usage ( data repository only or data repository + business logic) • Database access layer structure • Security structure ( authentication, authorization, audit etc., ) Template Pages
Design Scope • Internal structure/behavior of each module • Concrete UI pages design • Algorithms design • Class design based on SRP ( Single responsibility principle)
Here’s the Point! • If functionality is the only thing that matters, any software architecture will do! • Other things that really matter: • design constraints • quality attributes