Introduction to Software Architecture The top level.... (and design revisited) 1
System Software What are we doing? Architecture • Top-level design • software system architecture • We use ‘system architecture’ or simply ‘architecture’ as a short name for ‘system software architecture’ • The high level/low level boundary is fluid • Architecture guides code • Code realizes architecture Software construction 2
The BIG questions for us at this stage in the course • What is architecture? • What do we have to do to create an architecture? • How much architecture is enough? 3 3
What is Architecture? 4 4
The purpose of architecture • Architecture provides coherency, understanding • Architecture acts as a guide for subsequent construction • ‘Architecture acts as the skeleton of a system … . There is no single right architecture, but there are more or less suitable skeletons for the job.’ • Choose your architecture well to achieve what you need to. • ‘Architecture influences quality attributes eg security, usability, latency, or modifiability.’ Quotes from [Fairbanks, Just enough Software Architecture, 2010] 5 5
What is an architecture • Very general definition: An architecture is a model that defines • the component parts of a system, and • how they work with each other to meet both functional and non-functional requirements � • It should help us think about • Delivery of quality attributes • Technology choices • Where the challenges in implementation are 6 6
How do we express an architecture? • We produce a model of the system to be built, expressed with • Text • Boxes and lines, possibly arrows • Relatively formalised boxes and lines • Unified Modeling Language (UML) • Phillipe Kruchen’s 4+1 architecture • Walking skeletons • Depicts both structure and dynamic behaviour One of the most effective guidelines is not to get stuck on a single approach. If diagramming the design in UML isn't working, write it in English. Write a short test program. Try a completely different approach. McConnell, 5.3 7 7
The output of system architecture • The key output of system architecting is • a shared (and shareable) understanding • of the structure and dynamic behaviour of the system • and the relation of structure to critical qualities • An understanding of the architecture should • facilitate communication • support predictions about the system • guide planning • Architecture is good to the degree it is graspable and that grasping works 8 8
Architecture provides constraints on the (subsequent) design space • Eg you want to address maintainability and extensibility • Separation of concerns aids maintainability and extensibility • So you decide to separate code into three blocks, for UI, business logic and persistence • This is a 3 tier architecture • Localisation of these 3 kinds of code into the 3 layers http://weblogs.asp.net/fredriknormen/ using-web-services-in-a-3-tier- is now a constraint on your system architecture 9 9
Architecture provides constraints on the (subsequent) design space • Eg you need to ensure security of data for a financial application, so adopt • Database encryption • Transport Layer Security (TLS aka SSL) • Example constraint, all data accesses to persistent data must now go through an encryption/decryption layer • For all services that you add to process data • Similarly all HTTP-based communications are encruypted using TLS � 10 10
Different uses for the same architecture • ‘Architecture is [mostly] orthogonal to functionality.’ [Fairbanks, Just enough Software Architecture, 2010] • Within limits, you can use the same architecture to implement systems with different functionality • Eg, the basic web architecture is used for millions of different systems browser <---HTTP---> server <----> db 11 11
Different architecture for the same use / end-user functionality • Systems implemented with different architectures may supply the same functionality • Eg I could construct a single-user FileMaker-like application that runs locally using • A brain-dead program in C that uses a database • A Smalltalk-implemented system that uses the Model-View-Controller architecture and no database • An in-browser implementation that uses JavaScript and browser-based persistence mechanisms 12 12
Different architecture for the same use / end-user functionality • Different architectures providing the same functionality may (previous slide) have different external properties • Eg where the system runs • What limitations there are on the UI • How performant it is • And different internal properties • How the system is structured • How maintainable and extensible it is 13 13
The effect of competencies and organisational structure • A team that has worked with a given architecture • May find it more understandable • May have tools and practices that support it • This is an advantage • Conway’s ‘Law’ states that architectural form is influenced by the structure of the organisation that is developing the architecture • This may be a disadvantage 14 14
What do we have to do? 15 15
Architecture is essentially about • Interconnecting functional blocks • And how these blocks then interact to provide functionality 16 16
The conventional advice • Evaluate a few different architectures to see how they support your desired quality attributes • Within the available resource profile for the project � • The smart CTO chooses an architect who has already performed this kind of evaluation for the target system, and can start without an evaluation phase • Being able to do architecture well depends on how many system you have seen • Faster with knowledge of architectural patterns 17 17
Design, a reminder • Characteristics of design • Relies on domain knowledge in two kinds of domain • The application domain • The technical domain • Informed by knowledge and insight • Based on past experience • Multi-faceted at variable levels of detail • Knowing what to take account of • Knowing what to ignore • Making motivated choices • Making tradeoffs while making choices 18 18
No magic box to do design 19 19
But there may be some strategies • Strategy: A way of going about doing something • Strategies are high-level • (Tactics are low level) • We consider these in a few slides time 20 20
‘Easy’ architectural design • Sometimes it’s relatively easy • Similar to our last two systems, which have been proven to work well • Adoption of a presumptive architecture • Realistically constrains the solution to a space of architectures known to work • What if there is some aspect to the system that is overlooked and that has a profound effect? • “No brainer” architecture • Variant of well understood problem • E.g., straightforward web site • Good technology and team support 21 21
But by and large, it’s hard • For any significant system architecture is likely to be hard to design • Some of the things that ‘conspire’ to make architecture hard are • Functional and non-functional requirements • Time-to-market minimisation • Project resourcing constraints, cost and available HR resources • Unknown performance of the architecture when implemented in real life settings 22 22
Some approaches to architecture • We know that • The architecture expresses those things that it will be too expensive to change later in the system development • The architecture satisfies quality attributes / non-functional requirements • Yeah, so what? How does this help us design an architecture? • Let’s examine two strategies, top-down and bottom-up design 23 23
System Software Direction of Design Architecture • Top down • Start with the general problem • Break it into manageable parts • Each part becomes a new problem • Decompose further • Bottom out with concrete code • Bottom up • Start with a specific capability • Implement it • Repeat until confident enough • to think about higher level pieces 24 Software construction 24
Opportunistic focus • Top down and bottom up aren’t exclusive • “Thinking from the top” • Focuses our attention on the whole system • “Thinking from the bottom” • Focuses our attention on concrete issues • Being able to choose where you focus your attention opportunistically is a great help • Eg working at the top level, yu may wonder will this really work, so you consider realisation at a lower level of detail • Will have to rework the top level if doesn’t work at a greater level of detail 25 25
Technology and architecture • The technology you choose influences architecture, so you may want to find out about it, or prove something • Typically we do a spike (a short experiment in the use of technology) when we want to find out something specific for our architecture • A prototype is really an exploration of or proof of concept of all or some part of a system • We build a “walking skeleton” if we want to provide a loose proof for our architecture 26 26
Recommend
More recommend
