Transcript of "4 architecture"

1.
Software Architecture Software Architecture 1

2.
Background Any complex system is composed of sub-systems that interact While designing systems, an approach is to identify sub-systems and how they interact with each other Sw Arch tries to do this for software A recent area, but a lot of interest in it Software Architecture 2

3.
Background… Architecture is the system design at the highest level Choices about technologies, products to use, servers, etc are made at arch level  Not possible to design system details and then accommodate these choices  Arch must be created accommodating them Is the earliest place when properties like rel/perf can be evaluated Software Architecture 3

4.
Architecture Arch is a design of the sw that gives a very high level view of parts and they relate to form the whole  Partitions the sys in parts such that each part can be comprehended independently  And describes relationship between parts A complex system can be partitioned in many diff ways, each providing a useful view  Same holds true of software also  There is no unique structure; many possible Software Architecture 4

5.
Architecture Defn: Software arch is the structure or structures which comprise elements, their externally visible properties, and relationships among them  For elements only interested in external properties needed for relationship specification  Details on how the properties are supported is not important for arch  The defn does not say anything about whether an arch is good or not – analysis needed for it An arch description describes the different structures of the system Software Architecture 5

6.
Key Uses of Arch Descriptions Understanding and communication  By showing a system at a high level and hiding complexity of parts, arch descr facilitates communication  To get a common understanding between the diff stakeholders (users, clients, architect, designer,…)  For negotiation and agreement  Arch descr can also aid in understanding of existing systems Software Architecture 6

7.
Uses… Reuse  A method of reuse is to compose systems from parts and reuse existing parts  This model is facilitated by reusing components at a high level providing complete services  To reuse existing components, arch must be chosen such that these components fit together with other components  Hence, decision about using existing components is made at arch design time Software Architecture 7

8.
Uses.. Construction and evolution  Some structures in arch descr will be used to guide system development  Partitioning at arch level can also be used for work allocation to teams as parts are relatively independent  During sw evolution, arch helps decide what needs to be changed to incorporate the new changes/features  Arch can help decide what is the impact of changes to existing components on others Software Architecture 8

9.
Uses… Analysis  If properties like perf, reliability can be determined from design, alternatives can be considered during design to reach the desired perf levels  Sw arch opens such possibilities for software (other engg disciplines usually can do this)  E.g. rel and perf of a system can be predicted from its arch, if estimates for parms like load etc is provided  Will require precise description of arch, as well as properties of the elements in the description Software Architecture 9

10.
Architectural Views There is no unique arch of a sys There are different views of a sw sys A view consists of elements and relationships between them, and describes a structure The elements of a view depends on what the view wants to highlight Diff views expose diff properties A view focusing on some aspects reduces its complexity Software Architecture 10

11.
Views… Many types of views have been proposed Most belong to one of these three types  Module  Component and Connector  Allocation The diff views are not unrelated – they all represent the same system  There are relationships between elements of diff views; this rel may be complex Software Architecture 11

15.
Views… An arch description consists of views of diff types, each showing a diff structure  Diff sys need diff types of views depending on the needs  E.g. for perf analysis, allocation view is necessary; for planning, module view helps The C&C view is almost always done, and has become the primary view  We focus primarily on the C&C view  Module view is covered in high level design, whose focus is on identifying modules Software Architecture 15

16.
Component and Connector View Two main elements – components and connectors Components: Computational elements or data stores Connectors: Means of interaction between comps A C&C view defines the comps, and which comps are connected through which connector The C&C view describes a runtime structure of the system – what comps exist at runtime and how they interact during execution Is a graph; often shown as a box-and-line drawing Most commonly used structure Software Architecture 16

17.
Components Units of computations or data stores Has a name, which represents its role, and provides it identity A comp may have a type; diff types rep by diff symbols in C&C view Comps use ports (or interfaces) to communicate with others An arch can use any symbols to rep components; some common ones are shown Software Architecture 17

19.
Connectors Interaction between components happen through connectors A connector may be provided by the runtime environment, e.g. procedure call But there may be complex mechanisms for interaction, e.g http, tcp/ip, ports,…; a lot of sw needed to support them Important to identify them explicitly; also needed for programming comps properly Software Architecture 19

20.
Connectors… Connectors need not be binary, e.g. a broadcast bus Connector has a name (and a type) Often connectors represented as protocol – i.e. comps need to follow some conventions when using the connector Best to use diff notation for diff types of connectors; all connectors should not be shown by simple lines Software Architecture 20

22.
An Example Design a system for taking online survey of students on campus  Multiple choice questions, students submit online  When a student submits, current result of the survey is shown Is best built using web; a 3-tier architecture is proposed  Has a client, server, and a database components (each of a diff type)  Connector between them are also of diff types Software Architecture 22

24.
Example… At arch level, details are not needed The connectors are explicitly stated, which implies that the infrastructure should provide http, browser, etc. The choice of connectors imposes constraints on how the components are finally designed and built Software Architecture 24

25.
Extension 1 This arch has no security – anyone can take the survey We want that only registered students can take the survey (at most once)  To identify students and check for one-only submission, need a authentication server  Need to use cookies, and server has to be built accordingly (the connector between server and auth server is http with cookies) Software Architecture 25

27.
Extension 2 It was found that DB is frequently down For improving reliability, want that if DB is down, student is given an older survey result and survey data stored The survey data given can be outdated by at most 5 survey data points For this, will add a cache comp, which will store data as well as results Software Architecture 27

29.
Example… One change increased security, 2 nd increased performance and reliability I.e. Arch level choices have a big impact on system properties That is why, choosing a suitable arch can help build a good system Software Architecture 29

30.
Architectural Styles for C&C View Diff systems have diff C&C structure Some structures are general and are useful for a class of problems – architectural styles An arch style defines a family of archs that satisfy the constraint of that style Styles can provide ideas for creating arch for a sys; they can be combined also We discuss a few common styles Software Architecture 30

31.
Pipe and filter Well suited for systems that mainly do data transformations A system using this style uses a network of transforms to achieve the desired result Has one component type – filter Has one connector type – pipe A filter does some transformation and passes data to other filters through pipes Software Architecture 31

32.
Pipe and Filter… A filter is independent; need not know the id of filters sending/receiving data Filters can be asynchronous and are producers or consumers of data A pipe is unidirectional channel which moves streams of data from one filter to another A pipe is a 2-way connector Filters have to perform buffering, and synchronization between filters Software Architecture 32

33.
Pipe and filter… Filters should work without knowing the identify of producers/consumers A pipe must connect the output port of one filter to input port of another Filters may have indep thread of control Software Architecture 33

34.
Example A system needed to count the frequency of different words in a file One approach: first split the file into a sequence of words, sort them, then count the #of occurrences The arch of this system can naturally use the pipe and filter style Software Architecture 34

38.
Example A student registration system of a university Repository contains all the data about students, courses, schedules,… Accessors like admin, approvals, registration, reports which perform operations on the data Software Architecture 38

40.
Example.. Components do not directly communicate with each other Easy to extend – if a scheduler is needed, it is added as a new accessor  No existing component needs to be changed Only one connector style in this – read/write Software Architecture 40

41.
Client-Server Style Two component types – clients and servers Clients can only communicate with the server, but not with other clients Communication is initiated by a client which sends request and server responds One connector type – request/reply, which is asymmetric Often the client and the servers reside on different machines Software Architecture 41

42.
Client-server style… A general form of this style is the n-tier structure A 3-tier structure is commonly used by many application and web systems  Client-tier contains the clients  Middle-tier contains the business rules  Database tier has the information Software Architecture 42

43.
Some other styles Publish-subscribe style  Some components generate events, and others subscribe to them  On an event, those component that subscribe to it are invoked Peer-to-peer style  Like object oriented systems; components use services from each other through methods Communication processes style  Processes which execute and communicate with each other through message passing Software Architecture 43

44.
Architecture and Design Both arch and design partition the system into parts and their org What is the relationship between design and arch?  Arch is a design; it is about the solution domain, and not problem domain  Can view arch as a very high level design focusing on main components  Design is about modules in these components that have to be coded  Design can be considered as providing the module view of the system Software Architecture 44

45.
Contd… Boundaries between architecture and design are not clear or hard It is for designer and architect to decide where arch ends and design begins In arch, issues like files, data structure etc are not considered, while they are important in design Arch does impose constraints on design in that the design must be consistent with arch Software Architecture 45

46.
Preserving the Integrity ofArchitecture What is the role of arch during the rest of the development process Many designers and developers use it for understanding but nothing more Arch imposes constraints; the implementation must preserve the arch I.e. the arch of the final system should be same as the arch that was conceived It is very easy to ignore the arch design and go ahead and do the development Example – impl of the word frequency problem Software Architecture 46

50.
Example… First impl clearly preserves the arch Second can also be considered as preserving the arch The third ones does not preserve arch, even though it is a correct impl. This type of mismatch, where the final arch of the sys is different from the one designed should be avoided Software Architecture 50

51.
Documenting Arch Design While designing and brainstorming, diagrams are a good means Diagrams are not sufficient for documenting arch design An arch design document will need to precisely specify the views, and the relationship between them Software Architecture 51

52.
Documenting… An arch document should contain  System and architecture context  Description of architecture views  Across view documentation A context diagram that establishes the sys scope, key actors, and data sources/sinks can provide the overall context A view description will generally have a pictorial representation, as discussed earlier Software Architecture 52

53.
Documenting… Pictures should be supported by  Element catalog: Info about behavior, interfaces of the elements in the arch  Architectural rationale: Reasons for making the choices that were made  Behavior: Of the system in different scenarios (e.g. collaboration diagram)  Other Information: Decisions which are to be taken, choices still to be made,.. Software Architecture 53

54.
Documenting… Inter-view documentation  Views are related, but the relationship is not clear in the view  This part of the doc describes how the views are related (eg. How modules are related to components)  Rationale for choosing the views  Any info that cuts across views Sometimes views may be combined in one diagram for this – should be done if the resulting diagram is still easy to understand Software Architecture 54

55.
Evaluating Architectures Arch impacts non-functional attributes like modifiability, performance, reliability, portability, etc  Attr. like usability etc are not impacted Arch plays a much bigger impact on these than later decisions So should evaluate a proposed arch for these properties Q: How should this evaluation be done?  Many different ways, we briefly discuss ATAM Software Architecture 55

57.
ATAM… Collect Scenarios  Scenarios describe interactions  For analysis we should pick key scenarios of interest for which analysis will be done; important exception scenarios should be included Collect requirements or constraints  Define what is expected from the system in these scenarios  They should specify the desired levels for the attributes of interest Software Architecture 57

58.
ATAM… Describe architectural views  The views of the system that will be evaluated are collected  Diff views may be needed for diff types of analyses Attribute specific analysis  The views under diff scenarios are analyzed for diff quality attributes separately  Provides levels that the arch can provide  Becomes basis of selecting arch  Any modeling or technique can be used Identify sensitivities and tradeoffs  Tradeoff analysis Software Architecture 58

59.
An Example The student-survey system, the arch with the cache For analysis, we add the cache between the database and server  Diff from having a separate cache Software Architecture 59

61.
Example – scenarios of interest S1: A student submits the survey form and gets current results (normal scenario; all servers are up, load normal) S2: A student tries to take the survey many times S3: The database server is temporarily down S4: The network/system is highly loaded Software Architecture 61

62.
Example – Sys req or constraints Security. A student should be allowed to take the survey at most once Response Time. A student should get a response time of less than 2 sec on an average, 80% of the time Availability. The system should at least have availability of 0.85 Data Currency. The survey result given to a student should not be older than 5 submissions before Software Architecture 62

63.
Example – analysis We evaluate the three architecture proposals We will consider each attribute and study each arch under scenarios where it is relevant For security and data currency – subjective evaluation based on understanding For availability and response time – simple model based analysis done Software Architecture 63

65.
Example – availability.. Avail for first arch is the prob that both servers and db are up, i.e. .9*.9=0.81 Avail of 2nd and 3rd - when db down still half reqs are serviced by cache  Extra Avail: 0.5*0.9*0.1=0.045  Total avail: 0.81+0.045 = 0.855 Software Architecture 65

68.
Example – Eval summary… Security and data currency requirements are satisfied by all three architecture options Resp time req is also met by all as it is less than 2 sec in normal scenario, whose prob is 0.8 Availability is met by the second and third options only (third is preferred as it has a smaller response time) Software Architecture 68

69.
Summary Arch of a sw system is its structures comprising of elements, their external properties, and relationships Arch is a high level design Three main view types – module, component and connector, and allocation Component and connector (C&C) view is most commonly used Software Architecture 69

70.
Summary… There are some C&C styles that are commonly used, e.g. pipe-and-filter, shared data, client server,.... An arch description should document the different views and their relationship – views can be combined Rationale and other supporting information should also be captured Software Architecture 70

71.
Summary… Arch can be analyzed for various non- functional attributes like performance, reliability, security, etc ATAM is one approach for analyzing architectures, which evaluates attributes of interest under different scenarios Software Architecture 71