SADP UNIT 1

1. SADP – Unit 1 1 The Architecture Business Cycle •For decades, systems were designed exclusively based on the technical requirements. •SD methods recognize the simplicity of this model and provide feedback loops from design to analysis (this is still not sufficient). •A software architecture is developed as the first step toward designing a system that has a collection of desired properties. ➢ Initial Definitions •The architectural view is abstract, distilling away details and concentrating on the behavior and interaction of "black box" elements. •The software architecture comprises software elements, the externally visible properties of those elements, and the relationships among them. •It serves as an important communication, reasoning, analysis, and growth tool for systems. •Software architecture is a result of technical,business, and social influences. •Its existence in turn affects the technical, business, and social environments that subsequently influence future architectures. •This cycle of influence is called Architecture Business Cycle (ABC). •ABC is used examine the following: —How organizational goals influence requirements and development strategy. —How requirements lead to an architecture. —How architectures are analyzed. —How architectures yield systems that suggest new organizational capabilities and requirements. ➢ Where Do Architectures Come From? •An architecture is the result of a set of business and technical decisions. •Even with the same requirements, hardware, support software, and human resources available, an architect designing a system today is likely to design a different system than might have been designed few years ago.

2. SADP – Unit 1 2 •In any development effort, the requirements make explicit only some of the desired properties of the final system. ❖Architectures are Influenced by System Stakeholders •Many people and organizations are interested in the construction of a software system. •The customer, the end users, the developer, the project manager, the maintainers. ❖ Architectures are Influenced by the Developing Organization •The organizational goals expressed through requirements, an architecture is influenced by the structure or nature of the development organization. • For example, if the organization has an abundance of idle programmers skilled in client-server communications, then a client-server architecture might be the approach supported by management. If not, it may well be rejected. •There are three classes of influence that come from the developing organization: immediate business, long-term business, and organizational structure. •An organization may have an immediate business investment in certain assets, such as existing architectures and the products based on them. The foundation of a development project may be that the proposed system is the next in a sequence of similar systems, and the cost estimates assume a high degree of asset re-use. •An organization may wish to make a long-term business investment in an infrastructure to pursue strategic goals and may view the proposed system as one means of financing and extending that infrastructure. •The organizational structure can shape the software architecture •For example the development of some of the subsystems can be subcontracted.

3. SADP – Unit 1 3 •This was made possible by a division of functionality in the architecture that allowed isolation of the specialties. ❖Architectures are Influenced by the background and experience of the architects •Successful architectural approaches are usually reused in future projects. •Unsuccessful architectural approaches are usually avoided in future projects. • Architectural choices may come from an architect's education and training, exposure to successful architectural patterns or techniques. ❖Architectures are Influenced by the technical environment •The environment that is current when an architecture is designed will influence that architecture. •It might include standard industry practices or software engineering techniques prevalent in the architect's professional community. ❖Ramification of Influences on an architecture •Architects need to know and understand the nature, source, and priority of constraints on the project as early as possible. •Early engagements of stakeholders help understand the constraints of the task, manage expectations, negotiate priorities, and make tradeoffs. •Architecture reviews and iterative prototyping are two means for achieving it. •It should be apparent that the architects need more than just technical skills. •For an effective architect, then, diplomacy, negotiation, and communication skills are essential Influences on the Architect ➢ INFLUENCE THEM THE ARCHITECTURES AFFECT THE FACTORS THAT

4. SADP – Unit 1 4 •The main message of this book is that the relationships among business goals, product requirements, architects' experience, architectures, and fielded systems form a cycle with feedback loops that a business can manage. •Below Fig shows the feedback loops. Some of the feedback comes from the architecture itself, and some comes from the system built from The Architecture Business Cycle Here is how the cycle works: •1. The architecture affects the structure of the developing organization. An architecture prescribes a structure for a system. •2. The architecture can affect the goals of the developing organization •3. The architecture can affect customer requirements for the next system by giving the customer the opportunity to receive a system (based on the same architecture) in a more reliable, timely, and economical manner than if the subsequent system were to be built from scratch. •4. The process of system building will affect the architect's experience with subsequent systems by adding to the corporate experience base. •5. A few systems will influence and actually change the software engineering culture, that is, the technical environment in which system builders operate and learn ➢Software Processes and Architecture Business Cycle •Software process is the term given to the organization, ritualization and management of software development activities. •Activities involved in an architectural process: ARCHITECTURE ACTIVITIES oCreating the business case for the system oUnderstanding the requirements (Ch4 &Ch5) oCreating or selecting the architecture (Ch5 & Ch7) oDocumenting and communicating the architecture (Ch 9)

5. SADP – Unit 1 5 oAnalyzing or evaluating the architecture (Ch 11 & Ch12) oImplementing the system based on the architecture oEnsuring that the implementation conforms to the architecture What Makes a “Good” Architecture ➢Process Recommendations •The architecture should be the product of a single architect or a small group of architects with an identified leader. •The architect(s) should have the functional requirements and a prioritized list of quality attributes to be satisfied by the architecture. •The architecture should be well documented, using an agreed-on notation that all stakeholders can easily understand. •The architecture should be circulated to the system's stakeholders, who should be actively involved in its review. •The architecture should be formally evaluated for quality attributes before it is too late to make changes to it. •The architecture should lend itself to incremental implementation. •The architecture should result in a specific (and small) set of resource contention areas. •The resolution of resource contention areas is clearly specified, circulated, and maintained. ➢Product (structural) recommendations •The architecture should feature well-defined modules whose responsibilities are based on information hiding and separation of concerns. •Each module should have a well-defined interface that hides changeable aspects from other software that uses its facilities. •Quality attributes should be achieved using well-known architectural tactics specific to each attribute •The architecture should never depend on a particular version of a commercial product or tool. •Modules that produce data should be separate from modules that consume data (this increases modifiability). •For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not necessarily mirror the module decomposition structure.

6. SADP – Unit 1 6 •Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps even at runtime. •The architecture should feature a small number of simple interaction patterns. •This will aid in understandability, reduce development time, increase reliability, and enhance modifiability. What is Software Architecture? ➢Introduction •The architecture is an asset that holds tangible value to the developing organization beyond the project for which it was created. •Here we focus on the value that architecture brings to a development project besides what is returned to the developing organization. •Therefore, we view the architecture from a technical (software engineering) perspective. ➢What a software architecture is and what is not? •If architecture is a set of components and connections among them, few questions needs to be answered. •What is the nature of the elements? •What are the responsibilities of the elements? •What is the significance of the connections? •What is the significance of the layout? •The software architecture of a program or computing system is the structure(s) of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. •"Externally visible" properties are those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. •The architecture explicitly omits certain information about elements that does not pertain to their interaction. •First, architecture defines software elements. •Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure can irrefutably claim to be the architecture. •Third, the definition implies that every computing system with software has a software architecture because every system can be shown to comprise elements and the relations among them.

7. SADP – Unit 1 7 •Fourth, the behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. •Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that it will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. •Systems may comprise more than one structure and no one structure can claim to be the architecture. •Every system can be shown to comprise elements and the relations among them. •As such every software can have an architecture. ➢Other points of view •Software architecture is growing but still a young discipline (hence its has no single accepted definition). •Most of other definitions share the same base concepts: structure, elements and connections among them but vary in the details. •The study of architecture has evolved by observation of the design principles/actions designers’ follow/take when working on “real” systems. •Architecture is high-level design. •Architecture is the overall structure of the system. •Recall that a system may have many structures. •So this definition is not valid. •Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time. •The above definition includes the process part of the architecture which is not one of its intrinsic element. •Architecture is components and connectors. •Connectors imply a runtime mechanism for transferring control and data around a system. •Thus, this definition concentrates on the runtime architectural structures. •This makes the non-runtime architectural structures (static division into units of implementation) second-class citizens.

8. SADP – Unit 1 8 ➢Architectural Patterns, Reference Models and Reference Architectures •An architectural pattern (style) is a description of element and relation types together with a set of constraints on how they may be used. •A reference model is a division of functionality together with data flow between the pieces. •A reference architecture is a reference model mapped onto software elements and the data flows between them. ➢Why Is Software Architecture Important? •Communication among stakeholders i.e. basis for mutual understanding, negotiation, and consensus. •Early design decisions which carry much more weight as compared to the system's remaining phases. •Transferable abstraction of a system (promoting large-scale reuse). ❖Architecture is the Vehicle for Stakeholder Communication •Each stakeholder of a software is concerned with different system characteristics that are affected by the architecture. •Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved.

9. SADP – Unit 1 9 •It is difficult (without it) to understand large systems sufficiently to make the early decisions that influence both quality and usefulness. ❖Architecture Manifests the Earliest Set of Design Decisions •Early design decisions are the most difficult to get correct and the hardest to change later and they have the most far-reaching effects. •The architecture defines constraints on implementation. •Architecture dictates organizational structure. •The architecture inhibits or enables a system’s quality attributes. •Predicting system qualities by studying the architecture (done by architecture evaluation). •The architecture makes it easier to reason about and manage change. •The architecture helps in evolutionary prototyping. •The architecture enables more accurate cost and schedule estimates. ❖Architecture as a Transferable, Reusable Model •Software product lines share a common architecture. •Systems can be built using large, externally developed elements. •Less is more: it pays to restrict the vocabulary of design alternatives. •An architecture permits template-based development. •An architecture can be the basis for training. ➢Architectural Structures and Views •A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. •It consists of a representation of a set of elements and the relations among them. •A structure is the set of elements itself, as they exist in software or hardware. •These terms (structure and view) are often used interchangeably. •Module structures: Here the elements are modules, which are units of implementation. •They are assigned areas of functional responsibility.

10. SADP – Unit 1 10 •There is less emphasis on how the resulting software manifests itself at runtime. •Component-and-connector structures: Here the elements are runtime components (units of computation) and connectors (communication vehicles among components). •Allocation structures: They show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. ➢Common Software Architecture Structures ➢Module – Module based structure include the following. •Decomposition: -The units are modules related to each other by the "is a sub-module of " relation. -showing how larger modules are decomposed into smaller ones recursively until they are small enough to be easily understood. •Uses: -One module uses another if the there is a dependency between them. -One unit uses another if the correctness of the first requires the presence of a correct version (as opposed to a stub) of the second. •Layered: -A special type of “uses” where a layer is a coherent set of related functionality. •Class or generalization: -The module units in this structure are called classes. -The relation is "inherits-from”. -This view supports reasoning about collections of similar capability and differences which are captured by sub-classing. -This allows to reason about re-use and the incremental addition of functionality.

11. SADP – Unit 1 11 ➢Component and Connector- Component and connector based structure include the following. •Process, or communication processes: -Deals with the dynamic aspects of a running system. -The units here are processes or threads that are connected with each other by communication, and synchronization operations. -The relation is attachment, showing how the components and connectors are hooked together. •Concurrency: -Allows the architect to determine opportunities for parallelism and the locations where resource contention may occur. -The units are components and the connectors are "logical threads." -A logical thread is a sequence of computation that can be allocated to a separate physical thread later in the design process. •Shared data, or repository: -Comprises components and connectors that create, store, and access persistent data. -It shows how data is produced and consumed by runtime software elements, and it can be used to ensure good performance and data integrity. •Client-server : -The components are the clients and servers, and the connectors are protocols and messages they share to carry out the system's work. ➢Allocation- Allocation structure include the following. •Deployment: Shows how software is assigned to hardware-processing and communication elements. •Relations are "allocated-to," showing on which physical units the software elements reside, and "migrates-to”, if the allocation is dynamic. •Implementation:Shows how modules are mapped to the file structure(s) in the system's development, integration, or configuration control environments. • Work assignment: This structure assigns responsibility for implementing and integrating the modules to the appropriate development teams.

12. SADP – Unit 1 12 ➢Which Structure to Choose •Kruchten's four views are as follows: •Logical: The elements are "key abstractions," which are manifested in the OO world as objects or classes. This is a module view. •Process: This view addresses concurrency and distribution of functionality. It is a component-and-connector view. •Development: This view shows the organization of software modules, libraries, subsystems, and units of development.

13. SADP – Unit 1 13 •It is an allocation view, mapping software to the development environment. •Physical: This view maps other elements onto processing and communication nodes and is also an allocation view (which others call the deployment view). Quality Attributes ➢Quality (ISO 9126-1/ISO 8402) –“The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs” ➢Attribute(ISO 9126-1) –“A measurable physical or abstract property of an entity” ➢Quality attribute –A measurable property of characteristics of a software system,software architecture, or business context that bear on its ability to satisfy needs of stakeholders • Availability • Modifiability • Security • Performance • Testability • Usability Quality Attribute Scenarios: A A Q Qu ua al li it ty y A At tt tr ri ib bu ut te e S Sc ce en na ar ri io o i is s a a q qu ua al li it ty y- -a at tt tr ri ib bu ut te e- -s sp pe ec ci if fi ic c r re eq qu ui ir re em me en nt t. . T Th he er re e a ar re e 6 6 p pa ar rt ts s: :

14. SADP – Unit 1 14 1 1. .S So ou ur rc ce e o of f s st ti im mu ul lu us s ( (e e. .g g. ., , h hu um ma an n, , c co om mp pu ut te er r s sy ys st te em m, , e et tc c. .) ) 2 2. .S St ti im mu ul lu us s – – a a c co on nd di it ti io on n t th ha at t n ne ee ed ds s t to o b be e c co on ns si id de er re ed d 3 3. .E En nv vi ir ro on nm me en nt t - - w wh ha at t a ar re e t th he e c co on nd di it ti io on ns s w wh he en n t th he e s st ti im mu ul lu us s o oc cc cu ur rs s? ? 4 4. .A Ar rt ti if fa ac ct t – – w wh ha at t e el le em me en nt ts s o of f t th he e s sy ys st te em m a ar re e s st ti im mu ul la at te ed d. . 5 5. .R Re es sp po on ns se e – – t th he e a ac ct ti iv vi it ty y u un nd de er rt ta ak ke en n a af ft te er r a ar rr ri iv va al l o of f t th he e S St ti im mu ul lu us s 6 6. .R Re es sp po on ns se e m me ea as su ur re e – – w wh he en n t th he e r re es sp po on ns se e o oc cc cu ur rs s i it t s sh ho ou ul ld d b be e m me ea as su ur ra ab bl le e s so o t th ha at t t th he e r re eq qu ui ir re em me en nt t c ca an n b be e t te es st te ed d. . AVAILABILITY: ➢ ➢A Av va ai il la ab bi il li it ty y i is s c co on nc ce er rn ne ed d w wi it th h s sy ys st te em m f fa ai il lu ur re e a an nd d d du ur ra at ti io on n o of f s sy ys st te em m f fa ai il lu ur re es s. . ➢S Sy ys st te em m f fa ai il lu ur re e m me ea an ns s … … w wh he en n t th he e s sy ys st te em m d do oe es s n no ot t p pr ro ov vi id de e t th he e s se er rv vi ic ce e f fo or r w wh hi ic ch h i it t w wa as s i in nt te en nd de ed d ➢A system failure occurs when the system no longer delivers a service consistent with its specification T Ta ab bl le e - - A Av va ai il la ab bi il li it ty y G Ge en ne er ra al l S Sc ce en na ar ri io o. . S Sc ce en na ar ri io o P Po or rt ti io on n P Po os ss si ib bl le e V Va al lu ue es s S So ou ur rc ce e I In nt te er rn na al l t to o s sy ys st te em m o or r e ex xt te er rn na al l t to o s sy ys st te em m S St ti im mu ul lu us s C Cr ra as sh h, , o om mi is ss si io on n, , t ti im mi in ng g, , n no o r re es sp po on ns se e, , i in nc co or rr re ec ct t r re es sp po on ns se e A Ar rt ti if fa ac ct t S Sy ys st te em m’ ’s s p pr ro oc ce es ss so or rs s, , c co om mm mu un ni ic ca at ti io on n c ch ha an nn ne el ls s, , p pe er rs si is st te en nt t s st to or ra ag ge e E En nv vi ir ro on nm me en nt t N No or rm ma al l o op pe er ra at ti io on n; ; d de eg gr ra ad de ed d ( (f fa ai il ls sa af fe e) ) m mo od de e R Re es sp po on ns se e L Lo og g t th he e f fa ai il lu ur re e, , n no ot ti if fy y u us se er rs s/ /o op pe er ra at to or rs s, , d di is sa ab bl le e s so ou ur rc ce e o of f f fa ai il lu ur re e, , c co on nt ti in nu ue e ( (n no or rm ma al l/ /d de eg gr ra ad de ed d) ) R Re es sp po on ns se e M Me ea as su ur re e T Ti im me e i in nt te er rv va al l a av va ai il la ab bl le e, , a av va ai il la ab bi il li it ty y% %, , r re ep pa ai ir r t ti im me e, , u un na av va ai il la ab bi il li it ty y t ti im me e i in nt te er rv va al l

15. SADP – Unit 1 15 MODIDIABILITY: ➢M Mo od di if fi ia ab bi il li it ty y i is s a ab bo ou ut t t th he e c co os st t o of f c ch ha an ng ge e, , b bo ot th h i in n t ti im me e a an nd d m mo on ne ey y. . T Ta ab bl le e - - M Mo od di if fi ia ab bi il li it ty y G Ge en ne er ra al l S Sc ce en na ar ri io o. . S Sc ce en na ar ri io o P Po or rt ti io on n P Po os ss si ib bl le e V Va al lu ue es s S So ou ur rc ce e E En nd d- -u us se er r, , d de ev ve el lo op pe er r, , s sy ys st te em m- -a ad dm mi in ni is st tr ra at to or r S St ti im mu ul lu us s A Ad dd d/ /d de el le et te e/ /m mo od di if fy y f fu un nc ct ti io on na al li it ty y o or r q qu ua al li it ty y a at tt tr r. . A Ar rt ti if fa ac ct t S Sy ys st te em m u us se er r i in nt te er rf fa ac ce e, , p pl la at tf fo or rm m, , e en nv vi ir ro on nm me en nt t E En nv vi ir ro on nm me en nt tA At t r ru un nt ti im me e, , c co om mp pi il le e t ti im me e, , b bu ui il ld d t ti im me e, , d de es si ig gn n- -t ti im me e R Re es sp po on ns se e L Lo oc ca at te e p pl la ac ce es s i in n a ar rc ch hi it te ec ct tu ur re e f fo or r m mo od di if fy yi in ng g, , m mo od di if fy y, , t te es st t m mo od di if fi ic ca at ti io on n, , d de ep pl lo oy ys s m mo od di if fi ic ca at ti io on n R Re es sp pM Me ea as su ur re eC Co os st t i in n e ef ff fo or rt t, , m mo on ne ey y, , t ti im me e, , e ex xt te en nt t a af ff fe ec ct ts s o ot th he er r s sy ys st te em m f fu un nc ct ti io on ns s o or r q qu ua al li it ti ie es s SECURITY •Security is a measure of the system's ability to resist unauthorized usage while still providing its services to legitimate users. •Security can be characterized as a system providing 1.Nonrepudiation is the property that a transaction (access to or modification of data or services) cannot be denied by any of the parties to it. 2.Confidentiality is the property that data or services are protected from unauthorized access.

16. SADP – Unit 1 16 3.Integrity is the property that data or services are being delivered as intended. 4.Assurance is the property that the parties to a transaction are who they purport to be. 5.Availability is the property that the system will be available for legitimate use. 6.Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct them. Sample security scenario S Se ec cu ur ri it ty y G Ge en ne er ra al l S Sc ce en na ar ri io o. . S Sc ce en na ar ri io o P Po or rt ti io on n P Po os ss si ib bl le e V Va al lu ue es s S So ou ur rc ce e U Us se er r/ /s sy ys st te em m w wh ho o i is s l le eg gi it ti im ma at te e/ /i im mp po os st te er r/ /u un nk kn no ow wn n w wi it th h f fu ul ll l/ /l li im mi it te ed d a ac cc ce es ss s S St ti im mu ul lu us s A At tt te em mp pt t t to o d di is sp pl la ay y/ /m mo od di if fy y d da at ta a; ; a ac cc ce es ss s s se er rv vi ic ce es s A Ar rt ti if fa ac ct t S Sy ys st te em m s se er rv vi ic ce es s, , d da at ta a E En nv vi ir ro on nm me en nt t N No or rm ma al l o op pe er ra at ti io on n; ; d de eg gr ra ad de ed d ( (f fa ai il ls sa af fe e) ) m mo od de e R Re es sp po on ns se e A Au ut th he en nt ti ic ca at te e u us se er r; ; h hi id de e i id de en nt ti it ty y o of f u us se er r; ; g gr ra an nt t/ /b bl lo oc ck k a ac cc ce es ss s; ; e en nc cr ry yp pt t d da at ta a; ; d de et te ec ct t e ex xc ce es ss si iv ve e d de em ma an nd d… … R Re es sp pM Me ea as su ur re e T Ti im me e / /e ef ff fo or rt t/ /r re es so ou ur rc ce es s t to o c ci ir rc cu um mv ve en nt t s se ec cu ur ri it ty y m me ea as su ur re es s w wi it th h p pr ro ob ba ab bi il li it ty y o of f s su uc cc ce es ss s TESTABILITY •Software testability refers to the ease with which software can be made to demonstrate its faults through testing. •Testability refers to the probability that it will fail on its next test execution.

17. SADP – Unit 1 17 •For a system to be properly testable, it must be possible to control each component's internal state and inputs and then to observe its outputs. Sample testability scenario T Ta ab bl le e – – T Te es st ta ab bi il li it ty y G Ge en ne er ra al l S Sc ce en na ar ri io o. . S Sc ce en na ar ri io o P Po or rt ti io on n P Po os ss si ib bl le e V Va al lu ue es s S So ou ur rc ce e U Un ni it t d de ev ve el lo op pe er r, , i in nc cr re em me en nt t i in nt te eg gr ra at to or r, , s sy ys st te em m v ve er ri if fi ie er r, , c cl li ie en nt t a ac cc ce ep pt ta an nc ce e t te es st te er r, , s sy ys st te em m u us se er r S St ti im mu ul lu us s A An na al ly ys si is s, , a ar rc ch hi it te ec ct tu ur re e, , d de es si ig gn n, , c cl la as ss s, , s su ub bs sy ys st te em m i in nt te eg gr ra at ti io on n, , s sy ys st te em m d de el li iv ve er re ed d A Ar rt ti if fa ac ct t P Pi ie ec ce e o of f d de es si ig gn n, , p pi ie ec ce e o of f c co od de e, , c co om mp pl le et te e s sy ys st te em m E En nv vi ir ro on nm me en nt t A At t d de es si ig gn n t ti im me e, , a at t d de ev ve el lo op pm me en nt t t ti im me e, , a at t c co om mp pi il le e t ti im me e, , a at t d de ep pl lo oy ym me en nt t t ti im me e R Re es sp po on ns se e P Pr ro ov vi id de e a ac cc ce es ss s t to o s st ta at te e d da at ta a v va al lu ue es s, , o ob bs se er rv ve es s r re es su ul lt ts s, , c co om mp pa ar re es s R Re es sp pM Me ea as su ur re e % % c co ov ve er ra ag ge e; ; p pr ro ob b. . o of f f fa ai il lu ur re e; ; t ti im me e t to o p pe er rf fo or rm m t te es st ts s; ; l le en ng gt th h o of f t ti im me e t to o p pr re ep pa ar re e t te es st t e en nv vi ir ro on nm me en nt t PERFORMANCE •Performance is about timing. •Events (interrupts, messages, requests from users) occur, and the system must respond to them. •One of the things that make performance complicated is the number of event sources and arrival patterns. •A performance scenario begins with a request for some service arriving at the system. Satisfying the request requires resources to be consumed. While this is happening the system may be simultaneously servicing other requests. •An arrival pattern for events may be characterized as either periodic or stochastic.

18. SADP – Unit 1 18 Sample performance scenario Sample performance scenario Performance General Scenario Generation Portion of Scenario Possible Values Source One of a number of independent sources, possibly from within system Stimulus Periodic events arrive; sporadic events arrive; stochastic events arrive Artifact System Environment Normal mode; overload mode Response Processes stimuli; changes level of service Response Measure Latency, deadline, throughput, jitter, miss rate, data loss USABILITY Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. It can be broken down into the following areas: •Learning system features. If the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier? •Using a system efficiently. What can the system do to make the user more efficient in its operation? •Minimizing the impact of errors. What can the system do so that a user error has minimal impact? •Adapting the system to user needs. How can the user (or the system itself) adapt to make the user's task easier? •Increasing confidence and satisfaction. What does the system do to give the user confidence that the correct action is being taken?

19. SADP – Unit 1 19 Sample usability scenario Sample usability scenario S Sc ce en na ar ri io o P Po or rt ti io on n P Po os ss si ib bl le e V Va al lu ue es s S So ou ur rc ce e E En nd d u us se er r S St ti im mu ul lu us s W Wa an nt ts s t to o: : l le ea ar rn n s sy ys st te em m, , u us se e s sy ys st te em m, , r re ec co ov ve er r f fr ro om m e er rr ro or rs s, , a ad da ap pt t s sy ys st te em m, , f fe ee el l c co om mf fo or rt ta ab bl le e A Ar rt ti if fa ac ct t S Sy ys st te em m E En nv vi ir ro on nm me en nt t A At t r ru un nt ti im me e, , o or r c co on nf fi ig gu ur re e t ti im me e, , i in ns st ta al ll l- -t ti im me e R Re es sp po on ns se e ( (s se ee e b be el lo ow w) ) R Re es sp p M Me ea as su ur re eT Ta as sk k t ti im me e, , n nu um mb be er r o of f e er rr ro or rs s, , n nu um mb be er r o of f t ta as sk ks s a ac cc co om mp pl li is sh he ed d, , u us se er r k kn no ow wl le ed dg ge e, , a am mo ou un nt t o of f t ti im me e/ /d da at ta a l lo os st t s sa at ti is sf fa ac ct ti io on n, , g ga ai in n o of f u us se er r S Sy ys st te em m r re es sp po on ns se es s t to o s st ti im mu ul li i: : T To o l le ea ar rn n s sy ys st te em m ◼Help system is context sensitive ◼Interface familiar, consistent T To o u us se e s sy ys st te em m e ef ff fi ic ci ie en nt tl ly y ◼Reuse of command or data already entered ◼Navigation support, comprehensive searching T To o r re ec co ov ve er r f fr ro om m e er rr ro or rs s ◼Undo, cancel, recover from system failures ◼forgotten passwords T To o a ad da ap pt t s sy ys st te em m: : c cu us st to om mi iz ze e t th he e s sy ys st te em m t to o u us se er r l li ik ki in ng g

20. SADP – Unit 1 20 T To o f fe ee el l c co om mf fo or rt ta ab bl l COMMUNICATING CONCEPTS USING GENERAL SCENARIOS Quality Attribute Stimuli Quality Attribute Stimulus Availability Unexpected event, nonoccurrence of expected event Modifiability Request to add/delete/change/vary functionality, platform, quality attribute, or capacity Performance Periodic, stochastic, or sporadic Security Tries to display, modify, change/delete information, access, or reduce availability to system services Testability Completion of phase of system development Usability Wants to learn system features, use a system efficiently, minimize the impact of errors, adapt the system, feel comfortable 5. Other System Quality Attributes •Scalability •Portability •Interoperability 6. Business Qualities •Time to market. •Cost and benefit. •Projected lifetime of the system. •Targeted market. •Rollout schedule. •Integration with legacy systems. 7. Architecture Qualities •Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels. The architecture should do similar things in similar ways. Conceptual integrity is the most important consideration in system design. •Correctness and completeness are essential for the architecture to allow for all of the system's requirements and runtime resource constraints to be met. A formal evaluation is the architect's best hope for a correct and complete architecture. •Buildability allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progresses.

21. SADP – Unit 1 21 Moving From Qualities to Architecture •Qualities provide general guidelines and goals for a system but qualities by themselves are too vague to enable the design of a system •Patterns have in common: oPre-designed chunks that can be tailored to a given situation and about which certain characteristics are known. Each pattern represents a package of design decisions that has already been made and can be reused, as a set •Architectural style: oConsists of a few key features and rules for combining those features so that architectural integrity is preserve •Architectural style is determined by: oA set of component types (data repository, process, procedure) that perform some function at runtime oA topological layout of these components indicating their runtime interrelationship oA set of semantic constrains (data repository is not allowed to change the values stored in it) oA set of connectors that mediate communication, coordination, or cooperation among components •Data-centered architectures: oThe goal of achieving the quality of integrability of data oSystems in which the access and update of a widely accessed data store is an apt description oRepository is a passive data storage, Blackboard is an active data repository (subscribe-publish-notify) oData-centered styles offer a structural solution to integrability; clients are relatively independent of each other, and the data store is independent of the clients oData-centered style is scalable and modifiable; new clients can be easily added and old clients modified •Data-flow architectures: oThe goal of achieving the qualities of reuse and modifiability oCharacterized by viewing the system as a series of transformations on successive pieces of input data. Data enter the system and then flows through the components one at a time until they are assigned to some final destination oBatch-sequential; processing steps are independent programs, and they run to completion before the next step starts. Each batch of data is transmitted as a whole between the steps oPipe-and-filter; filters are connected by pipes. Constrains so that pipe’s source end can be connected only to filter’s output port and a sink end can only be connected to filter’s input port ▪Composition of the functions from its primitives; no complex component interactions to manage ▪Simplifies system maintenance and enhances reuse ▪Easily made parallel or distributed

22. SADP – Unit 1 22 ▪Problems: batch mentality so interactive applications difficult, filter ordering, performance (tokenizer, buffers) •Virtual machine architectures: oSoftware styles that simulate some functionality that is not native to the hardware and/or software on which it is implemented oInterpreters, rule-based systems, syntactic shells, and common language processors (JVM) oFlexibility through the ability to interrupts and query the program and introduce modification at runtime oPerformance cost •Call-and-return architecture: oQualities of modifiability and scalability oDominant architectural style for the past 30 years oSub-styles: ▪Main-program-and-subroutine; decomposition of program ▪Remote procedure call; decomposed parts live in different computers ▪Object-oriented; emphasizes the bundling of data and the knowledge of how to manipulate and access that data; to achieve reusability and modifiability by separation of concerns oLayered systems; rarely pure layers, layer bridging ▪Portability, modifiability, and ease of system parameterization •Independent component architectures: oConsists of a number of independent processes or objects that communicate through messages oGoal to achieve modifiability by decoupling various portions of the computations oSend data but do not directly control each other; named or unnamed participants oEvent systems: ▪Publish-subscribe ▪Data producer published data ▪Data consumers subscribe to certain data ▪Message manager ▪Loose decoupling of producers and consumers oCommunicating processes: ▪Classical multiprocessor-style ▪Client-server ▪Quality of scalability •Heterogeneous styles: oSystems are seldom built from a single style oKinds of heterogeneity: ▪Location heterogeneity; runtime structures reveal different styles in different areas ▪Hierarchy heterogeneity; different styles in decomposed areas ▪Simultaneous heterogeneity; any of the several styles may well be apt descriptions of the system

23. SADP – Unit 1 23 •A system designer’s primary impression of architecture often focuses on the character of the interactions among components. Thus, the major axes of classification are the control and data interactions among components •Feature categories: oComponents and connectors; the allowable kinds of components and connectors are important discriminators among styles oControl; how the control passes among components and how the components work together temporally; topology, synchronicity, binding time oData; how data move around the system; topology, continuity, mode, binding time oControl/data interaction; shape, directionality •Which style should you choose to design a system? It depends on the qualities that most concern you. Start with the architectural structure that provides the most leverage on the qualities that you expect to be most troublesome. From there, consider a style appropriate to that structure that addresses the qualities. At that point, other structures and styles can come into play to help address secondary issues Unit operations A unit operation is a codification of design operations that can be applied directly to an architecture. Examples include •abstraction •compression •part-whole decomposition •is-a decomposition •replication •resource sharing • Styles Vs. Unit Operations •Styles are pre-packaged off-the-shelf design solutions that have known quality properties. •Unit operations are the steps that one applies to derive styles, patterns, and reference architectures. •Unit operations affect the quality properties of the styles they lead to, but are not design solutions by themselves. Reference Architecture •Reference architecture: a division of functionality, together with data flow between the pieces Using Unit Operations to Build Reference Architectures •Strengths and weaknesses of unit operations can be demonstrated by exploring human-computer interface (HCI) reference architectures.

24. SADP – Unit 1 24 •HCI reference architectures are important in their own right since user interface typically accounts for 50% of the cost of a system. Unit Operations and HCI Reference Architectures Monolithic Reference Architecture for Interactive Systems An interactive system provides three functions. •presentation: controls interaction with user (example: windows interface) •application: underlying purpose of system (example: database system) •dialogue: decomposes/sequences user tasks (example: interaction) When functions are lumped together in a single structure, it is a monolithic architecture. Monolithic Reference Architecture Achieving User Interface Quality Goals Through Unit Operations •The typical user interface goals are modifiability and portability. •Applying the unit operation of part-whole decomposition supports the modifiability goal and abstraction supports the portability goal. •Separation: oPlaces a distinct piece of functionality into a distinct component that has a well- defined interface to the rest of the world; isolates a portion of a system’s functionality; modifiability and portability

25. SADP – Unit 1 25 oUniform decomposition ▪Decomposition is the operation of separating a large system component into two or more smaller ones. Uniform decomposition limits the composition mechanism to a small, uniform set. Eases integration of components and scaling of the system as a whole Decomposition as a Unit Operation •Decomposition breaks up a large component into smaller pieces. It can be done in two ways: •part-whole •is-a Part-Whole Decomposition •Every component in the system can be built from a fixed small set of subcomponents. Example: model view controller, flight simulators •Used for supporting integrability, extensibility, and understandability •A small number of component types gives a small number of component type interfaces. Is-A Decomposition •Each subcomponent represents a specialization of its parent’s functionality. Examples: PAC, class hierarchies •Used for reuse by increments. ▪Part-whole; non-overlapping portions of the functionality, and every component in the system can be built only from these subcomponents ▪Is-a; subcomponents represent a specialization of its parent’s functionality oReplication

26. SADP – Unit 1 26 ▪Duplicating a component within an architecture; reliability and performance •Abstraction: oOperation of creating a virtual machine; a component whose function is to hide its underlying implementation oVirtual machines are found everywhere •Compression: oOperation of removing layers or interfaces that separate system functions; opposite of separation oPurposes ▪Improve performance ▪Circumvent layering when it does not provide needed service ▪To speed system development •Resource sharing: oOperation that encapsulates either data or services and shares them among multiple independent consumers; resource manager oCostly to build initially but enhance integrability, portability, and modifiability; reduce coupling among components •Model-View-Controller: oDivide system into several Model (dialogue and application), View (output), and Controller (input) triplets oEach MVC triplet can be modified independently Seeheim model: oDeveloped to address modifiability and portability oUser <-> Presentation <-> Dialogue <-> Application, and layer bridging oProblems: idiosyncrasies of presentation present in dialogue •Comparing Seeheim and MVC oSeeheim considers porting from UI toolkit to toolkit as the most important scenario. MVC assumes that modifications are most likely to occur between different functional objects Seeheim Reference Architecture •The Seeheim reference architecture applies part -whole decomposition to the monolithic reference architecture.

27. SADP – Unit 1 27 Improved Seeheim Strengths of Seeheim Reference Architecture •A separate presentation function supports portability and modifiability. •A separate application layer allows modification of function without affecting user interface. •A separate dialogue allows modifications to user interaction without rewriting the presentation. Weaknesses of Seeheim Reference Architecture •Many modifications affect all three functions. •There are performance problems with sophisticated semantic feedback (which result in the need for compression). •Use of the architecture leads to separate notations for dialogue, presentation, and application layer; this is cumbersome. •Quality attributes are too abstract to be directly useful. For example, there are different kind of modifiability, both Seeheim and MVC address modifiability but different kind •Arch/Slinky: oInsert a function between presentation and dialogue that maps between the two; virtual presentation toolkit to the dialogue oVirtual application between application and dialogue oSlinky portion for expanding and contracting the allocation of function to components oCompression to speed system creation and performance •PAC (Presentation – Application – Control ): oModifiability and scalability oControl module controls its parts and the interaction between application and presentation oPoor support for portability (does not localize the effects of porting) The problem for the developer using unit operations:

28. SADP – Unit 1 28 oUnderstanding the requirements oMapping the requirements to a structural solution (identified as a design pattern or architectural style that may be derived using unit operations) oIdentifying and resolving conflicting structural solutions Achieving Quality Attributes Introducing Tactics • A system design consists of a collection of decisions • Tactic – a design decision that influences the control of a qualityattribute response –each tactic is a design option for the architect – • Architectural strategy – a collection of tactics Availability Tactics • Availability – concerned with system failure and its associated consequences – System failure • when the system no longer delivers a service consistent with its spec. • observable by the system's users • a fault (or combination of faults) has the potential to cause a failure – All approaches to maintaining availability • some type of redundancy • some type of health monitoring to detect a failure • some type of recovery when a failure is detected – Goal of availability tactics

29. SADP – Unit 1 29 • Fault detection – Ping/echo • One component issues a ping and expects to receive back an echo, within a predefined time • used within a group of components mutually responsible for one task • used by clients to ensure that a server object and the communication path to the server are operating within the expected performance bounds – Heartbeat (dead man timer) • one component emits a heartbeat message periodically • another component listens for it – If the heartbeat fails, the originating component is assumed to have failed • heartbeat can also carry data: e.g., ATM – Exceptions • to encounter an exception, which is raised when one of the fault classes is recognized • the exception tactic operates within a single process • Fault recovery – Voting • processes running on redundant processors each take equivalent input and compute a simple output value that is sent to a voter – if the voter detects deviant behavior from a single processor, it fails • voting algorithm – majority rules, preferred component, some other algorithm • used to correct faulty operation of algorithms or failure of a processor • if the consequence of a failure is extreme (critical), the redundant

30. SADP – Unit 1 30 components can be diverse – one extreme of diversity » software for each redundant component is developed by different teams » executes on dissimilar platforms – less extreme » to develop a single software component on dissimilar platforms • Simplex approach – uses the results of a "preferred" component unless they deviate from those of a "trusted" component – Active redundancy (hot restart) • all redundant components respond to events in parallel – all in the same state – the response from only one component is used and the rest are discarded • when a fault occurs, the only time to recover is the switching time • used in a client/server configuration – such as database management systems, where quick responses are necessary • in a highly available distributed system – the redundancy may be in the communication paths – e.g., LAN with a number of parallel paths and place each redundant component in a separate path • Synchronization – all messages to any redundant component are sent to all redundant components – To recover lost communication, reliable transmission protocol can be used » e.g., TCP – Passive redundancy (warm restart/dual redundancy/triple redundancy) • the primary component responds to events and informs the other standby components of state updates

31. SADP – Unit 1 31 when a fault occurs, the system – first ensure that the backup state is sufficiently fresh before resuming services – next switch from the primary to the backup • this tactic depends on the standby components taking over reliably • forcing switchovers periodically increases the availability of the system • Synchronization – the responsibility of the primary component –use atomic broadcasts to the secondaries to guarantee synchronization – Spare • a standby spare computing platform is configured to replace many different failed components • when a failure occurs – rebooted to the appropriate software configuration – have its state initialized • to set to the appropriate state – making a checkpoint of the system state to a persistent device periodically –logging all state changes to a persistent device – Shadow operation • a previously failed component may be run in "shadow mode“ – to make sure that it mimics the behavior of the working components before restoring it to service – State resynchronization • the passive and active redundancy tactics require the component being restored to have its state upgraded before its return to service • updating approach depends on – the downtime that can be sustained – the size of the update – the number of messages required for the update

32. SADP – Unit 1 32 – Checkpoint/rollback • a checkpoint is a recording of a consistent state • sometimes a system fails in an unusual manner, with a inconsistent state – should be restored using a previous checkpoint and a log of the transactions that occurred since the snapshot was taken • Fault prevention – Removal from service • to remove a component of the system from operation to undergo some activities to prevent anticipated failures • e.g., rebooting a component to prevent memory leaks – Transactions • used to prevent any data from being affected if one step in a process fails • used to prevent collisions among several simultaneous threads accessing the same data c.f. transaction – the bundling of several sequential steps such that the entire bundle can be undone at once – Process monitor • when a fault in a process has been detected, a monitoring process – can delete the nonperforming process –can create a new instance of it, initialized to some appropriate state Summary of availability tactics Modifiability Tactics

33. SADP – Unit 1 33 –Goal of modifiability tactics – Tactics for modifiability • localize modifications – reducing the number of modules that are directly affected by a change – those whose responsibilities are adjusted to accomplish the change • prevent the ripple effect – limiting modifications to the localized modules – those whose responsibilities remain unchanged but whose implementation must be changed • defer binding time –controlling deployment time and cost • Localize modifications – Maintain semantic coherence • semantic coherence – the relationships among responsibilities in a module • coupling and cohesion vs. semantic coherence – coupling & cohesion » measure semantic coherence, but missing the context of a change – semantic coherence » measure against a set of anticipated changes » expected changes will be semantically coherent • abstract common services – if common services have been abstracted, » modifications to them will need to be made only once rather than in each module

34. SADP – Unit 1 34 where the services are used » modification to the modules using those services will not impact other users – e.g., the use of application frameworks, the use of other middleware software – Anticipate expected changes • For each change, does the proposed decomposition limit the set of modules that need to be modified to accomplish it? • concern minimizing the effects of the changes • usually used in conjunction with semantic coherence – Do fundamentally different changes affect the same modules? – it is not possible to anticipate all changes – Generalize the module • allows a module to compute a broader range of functions based on input • The more general a module, the more likely that requested changes can be made by adjusting the input language rather than by modifying the module – Limit possible options • within a product line, modifications may be far ranging and hence affect many modules • restricting the possible options reduce the effect of these modifications • Prevent ripple effects – ripple effect • the necessity of making changes to modules not directly affected by a modification B) – various types of dependencies (A ? • Syntax of data/service – consistency for data type/signature of services • Semantics of data/service • Sequence of data/control • Identity of an interface of A – the identity (name or handle) of the interface must be consistent

35. SADP – Unit 1 35 • Location of A (runtime) • Quality of service/data provided by A – e.g., data provided by a particular sensor must have a certain accuracy • Existence of A • Resource behavior of A –resource usage of A, resource ownership – Hide information • information hiding – decomposition of the responsibilities for an entity into smaller pieces » private, public • its goal is to isolate changes within one module and prevent changes from propagating to others • strongly related to "anticipate expected changes“ – because it uses those changes as the basis for decomposition – Restrict communication paths • reduce the number of modules that consume data produced by the given module • reduce the number of modules that produce data consumed by it – Maintain existing interfaces • If B depends on the name and signature of an interface of A, maintaining this interface and its syntax allows B to remain unchanged • interface stability is achieved by separating the interface from the implementation • Patterns – adding interfaces » newly visible services or data can be made available through new interfaces » allowing existing interfaces to remain unchanged and provide the same signature – adding adapter » add an adapter to A that wraps A and provides the signature of the original A

36. SADP – Unit 1 36 – providing a stub A » If the modification calls for the deletion of A, then providing a stub for A will allow B to remain unchanged if B depends only on A's signature. – Use an intermediary • intermediary – manages activities associated with the dependency between two entities • intermediaries are – data (syntax) » repositories can convert the syntax produced by A into that assumed by B » publish/subscribe patterns, MVC and PAC patterns – service (syntax) » facade, bridge, mediator, strategy, proxy, and factory patterns » convert the syntax of a service from one form into another – identity of an interface of A » broker pattern can be used to mask changes in the identity of an interface – location of A (runtime) » name server enables the location of A to be changed without affecting B – resource behavior of A or resource controlled by A » resource manager that is responsible for resource allocation – existence of A » factory pattern has the ability to create instances as needed • Defer binding time – another modifiability scenarios • time to deploy • allowing nondevelopers to make changes – deferring binding time supports both of the scenarios • supports allowing the end user or system administrator to make settings or provide input that affects behavior

37. SADP – Unit 1 37 – Many tactics have impact at load time or runtime • Runtime registration – supports plug-and-play operation at either runtime or load time • Configuration files – set parameters at startup • Polymorphism – allows late binding of method calls • Component replacement – allows load time binding • Adherence to defined protocols –allows runtime binding of independent processes • Summary of modifiability tactics Performance Tactics

38. SADP – Unit 1 38 – Goal of performance tactics – Two basic contributors to the response time • Resource consumption – Resources: CPU, data stores, network communication bandwidth, memory, … – it contributes to the overall latency of the processing of the event • Blocked time – A computation can be blocked from using a resource » because of contention for it » because the resource is unavailable » because the computation depends on the result of other computations • Resource demand – Two characteristics of demand • how often a request is made in a stream (the time between events) • how much of a resource is consumed by each request – One tactic for reducing latency is to reduce the resources required • Increase computational efficiency – Improving the algorithms used in critical areas – intermediate data may be kept in a repository or it may be regenerated depending on time and space resource availability • Reduce computational overhead – If there is no request for a resource, processing needs are reduced – The use of intermediaries increases the resources consumed in processing an event stream » removing them improves latency » classic modifiability/performance tradeoff

39. SADP – Unit 1 39 – Another tactic for reducing latency is to reduce the number of events processed • Manage event rate – reduce the sampling frequency » if an unnecessarily high sampling rate is used to establish harmonic periods • Control frequency of sampling – If there is no control over the arrival of externally generated events, queued requests can be sampled at a lower frequency – Other tactics for reducing or managing demand involve controlling the use of resources • Bound execution times – For iterative, data-dependent algorithms, limiting the number of iterations • Bound queue sizes – controls the maximum number of queued arrivals and consequently the resources used to process • Resource management • management of the resources affects response times – Resource management tactics • Introduce concurrency – If requests can be processed in parallel, the blocked time can be reduced – appropriately allocating the threads to resources (load balancing) is important in order to maximally exploit the concurrency • Maintain multiple copies of either data or computations – Clients in a client-server pattern are replicas of the computation » reduce the contention that occur if all computations took place on a central server – Caching is a tactic in which data is replicated » different speed repositories or separate repositories, to reduce contention • Increase available resources – faster processors, additional processors, additional memory, and faster networks

40. SADP – Unit 1 40 – cost/performance tradeoff • Resource arbitration • if there is contention for a resource, the resource must be scheduled – Scheduling policies • First-in/First-out – if some requests are of higher priority than others, it is problematic • Fixed-priority scheduling – semantic importance » assigns a priority statically according to some domain characteristic of the task – deadline monotonic » assigns higher priority to streams with shorter deadlines – rate monotonic » assigns higher priority to periodic streams with shorter periods • Dynamic priority scheduling – round robin » orders the requests and then assigns the resource to the next request in that order » a special form of round robin is a cyclic executive where assignment possibilities are at fixed time intervals – earliest deadline first Performance Tactics • Summary of performance tactics

41. SADP – Unit 1 41 Security Tactics – Goal of security tactics Tactics for achieving security • resisting attacks • detecting attacks • recovering from attacks • Resisting attacks – Authenticate users • ensures that a user or remote computer is actually who it purports to be – with passwords, digital certificates, or biometric identifications – Authorize users • ensures that an authenticated user has the rights to access and modify either data or services – with some access control patterns – Maintain data confidentiality • data should be protected from unauthorized access – with some form of encryption to data and to communication links • encryption provides extra protection to persistently maintained data beyond that available from authorization • communication links typically do not have authorization controls – Maintain integrity • data should be delivered as intended – with checksums or hash results

42. SADP – Unit 1 42 – Limit exposure • Attacks typically exploit a single weakness to attack all data and services on a host • The architect can allocate services so that limited services are available on each host – Limit access • Firewalls restrict access based on message source or destination port • It is not always possible to limit access to known sources – e.g., public Web site can get requests from unknown sources – One configuration used in this case is the demilitarized zone (DMZ) » A DMZ is used when access must be provided to Internet services » It sits between the Internet and a firewall in front of the internal network » The DMZ contains devices expected to receive messages from arbitrary sources such as Web services, e-mail, and domain name services • Detecting attacks – through an intrusion detection system • the systems work by comparing network traffic patterns to a database – In the case of misuse detection • the traffic pattern is compared to historic patterns of known attacks – In the case of anomaly detection • the traffic pattern is compared to a historical baseline of itself – the packets must be filtered in order to make comparisons • Filtering can be on the basis of protocol, TCP flags, payload sizes, source or destination address, or port number • Recovering from attacks – Tactics used in restoring the system or data to a correct state • overlap with those used for availability – since they are both concerned with recovering a consistent state from an inconsistent state • special attention is paid to maintaining redundant copies of system administrative data

43. SADP – Unit 1 43 – Tactic for identifying an attacker • for either preventive or punitive purposes • to maintain an audit trail – audit trail » a copy of each transaction applied to the data in the system together with identifying information – Audit information can be used » to trace the actions of an attacker » to support nonrepudiation (it provides evidence that a particular request was made) » to support system recovery Security Tactics • Summary of security tactics Testability Tactics – Goal of testability tactics • to allow for easier testing when an increment of software development is Completed

44. SADP – Unit 1 44 – Two categories of tactics • providing input and capturing output • internal monitoring • Input/Output – Record/playback • capturing information crossing an interface • using it as input into the test harness • Recording this information during normal operation allows – test input for one of the components to be generated – test output for later comparison to be saved – Separate interface from implementation • allows substitution of implementations for various testing purposes – c.f., stub, test harness – Specialize access routes/interfaces • allows the capturing or specification of variable values for a component through a test harness independently from its normal execution • Internal monitoring – Built-in monitors • component maintain – state, performance load, capacity, security, other information – these information can be accessible through an interface • this interface can be – a permanent interface of the component – or it can be introduced temporarily via an instrumentation technique • A common technique is to record events when monitoring states have been activated • Summary of testability tactics

45. SADP – Unit 1 45 Usability Tactics – Usability • how easy it is for the user to accomplish a desired task • the kind of support the system provides to the user – Goal of usability tactics • Runtime tactics – Usability is enhanced when a system is executing • by giving feedback as to what the system is doing • by providing the ability to issue usability-based commands – e.g., cancel, undo, aggregate – user initiative tactics • architect must enumerate the responsibilities of the system to respond to the user command

46. SADP – Unit 1 46 • e.g., cancel command – the user issues a cancel command, the system must be listening for it; – the command to cancel must be killed; – components that are collaborating with the canceled command must be informed so that they can also take appropriate action – system initiative tactics • Maintain a model of the task – task model is used to determine context of what the user is attempting – it is used to provide various kinds of assistance – e.g., knowing that sentences usually start with capital letters & auto correction • Maintain a model of the user – it determines the user's knowledge of the system – determines the user's behavior in terms of expected response time – determines other aspects specific to a user or a class of users – e.g., to pace scrolling so that pages do not fly past faster than they can be read • Maintain a model of the system – it determines the expected system behavior so that appropriate feedback can be given to the user – system model predicts items such as the time needed to complete current activity • Design-time tactics – Separate the user interface from the rest of the application • user interfaces are changed frequently – both during the development and after deployment – in order to localize changes to them » maintaining the user interface code separately • software architecture patterns – Model-View-Controller

47. SADP – Unit 1 47 – Presentation-Abstraction-Control – Seeheim –Arch/Slinky • Summary of usability tactics Architectural Patterns and Styles •An architectural pattern in software, also known as an architectural style, is analogous to an architectural style in buildings, such as Gothic or Greek Revival, etc. •It consists of a few key features and rules for combining them so that architectural integrity is preserved. •An architectural pattern is determined by: •A set of element types (such as a data repository or a component that computes a mathematical function). •A topological layout of the elements indicating their interrelation-ships. •A set of semantic constraints (e.g., filters in a pipe-and-filter style are pure data transducers—they incrementally transform their input stream into an output stream, but do not control either upstream or downstream elements). •A set of interaction mechanisms (e.g., subroutine call, event-subscriber, blackboard) that determine how the elements coordinate through the allowed topology. •Mary Shaw and David Garlan's influential work attempted to catalog a set of architectural patterns that they called architectural styles or idioms. •These are now more commonly known as architectural patterns, analogous to design patterns and code patterns (idioms). Architectural Patterns and Styles: A Example Catalog Organized by “IS-A”

48. SADP – Unit 1 48 Designing the Architecture Designing the Architecture ➢Architecture in the Life Cycle •Several life-cycle models exist in the literature, but one that puts architecture squarely in the middle of things is the Evolutionary Delivery Life Cycle model (see next slide). •The intent of this model is to get user and customer feedback and iterate through several releases before the final release. •The model also allows the adding of functionality with each iteration and the delivery of a limited version once a sufficient set of features has been developed. Evolutionary Life Cycle

49. SADP – Unit 1 49 Software Deliver Preliminary concept Final Requirements Design of Version Analysis Architecture And System Develop A version Deliver Incorporate The Version Customer Elicit Feedback Customer Feedback ➢When Can I Begin Designing? •Architecture is "shaped" by some collection of functional, quality, and business requirements. •We call these shaping requirements architectural drivers. •To determine the architectural drivers - identify the highest priority business goals (few). - Turn these business goals into quality scenarios or use cases . - From this list, choose the ones that will have the most impact on the architecture. •These are the architectural drivers, and there should be fewer than ten. •Once the architectural drivers are known, the architectural design can begin. •The requirements analysis process will then be influenced by the questions generated during architectural design. ➢Designing the Architecture •Attribute-Driven Design (ADD) is a method for designing an architecture to satisfy both quality requirements and functional requirements. •ADD takes as input a set of quality attribute scenarios. •ADD employs knowledge about the relation between quality attribute achievement and architecture in order to design the architecture. •The ADD method can be viewed as an extension to most other development methods, such as the Rational Unified Process (RUP).

50. SADP – Unit 1 50 •ADD bases the decomposition process on the quality attributes the software has to fulfill. •It is a recursive decomposition process where, at each stage, tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is allocated to instantiate the module types provided by the pattern. •ADD is positioned in the life cycle after requirements analysis and, can begin when the architectural drivers are known with some confidence. The output of ADD is the first several levels of a module decomposition view of an architecture and other views as appropriate. •Not all details of the views result from an application of ADD. •The system is described as a set of containers for functionality and the interactions among them. •This is the first articulation of architecture during the design process and is therefore necessarily coarse grained. •The difference between an architecture resulting from ADD and one ready for implementation rests in the more detailed design decisions that need to be made. •We demonstrate the ADD method by using it to design a product line architecture for a garage door opener within a home information system. •The opener is responsible for raising and lowering the door via a switch, remote control, or the home information system. •It is also possible to diagnose problems with the opener from within the home information system. An Example: Garage Door Opener The functional requirements are ⚫To open/close the door on request, either locally or remotely; ⚫To stop the door within 0.1 second when an obstacle is detected; ⚫To interact with the home information system and support remote diagnosis. 1. The device and controls for opening and closing the door are different for the various products in the product line. •They may include controls from within a home information system. •The product architecture for a specific set of controls should be directly derivable from the product line architecture. 2. The processor used in different products will differ. •The product architecture for each specific processor should be directly derivable from the product line architecture. 3. If an obstacle (person or object) is detected by the garage door during descent, it must halt (alternately re-open) within 0.1 second. 4. The garage door opener should be accessible for diagnosis and administration from within the home information system using a product-specific diagnosis protocol. •It should be possible to directly produce an architecture that reflects this protocol. ➢Designing the Architecture: ADD steps