معمارية_البرمجيات.pdf

Software A rch itectu re software arch itectu re  g lobal desig n? arch itect  desig ner) Overview  What is it , why bother? (A rchitecture & Desig n)  Role of the software architect  Viewpoints and view models  A rchitectural sty les  A rchitecture asssessment...

Software A rch itectu re software arch itectu re  g lobal desig n? arch itect  desig ner) Overview  What is it , why bother? (A rchitecture & Desig n)  Role of the software architect  Viewpoints and view models  A rchitectural sty les  A rchitecture asssessment SE, Software Archi tectu re, Hans van Vliet, ©2008 2 The Role of the A rch itect SE, Software Archi tectu re, Hans van Vliet, ©2008 3 Pre-arch itecture li fe cycle sta keholders (few) req u irements q ua lity ag reement development SE, Software Archi tectu re, Hans van Vliet, ©2008 4 Characteristics  Iteration main ly on functional req uirements  Few stakeholders involved (engaged )  No balancing of functional and q uality req uirements SE, Software Archi tectu re, Hans van Vliet, ©2008 5 Add i ng arch itecture, the easy way sta keholders (few) req u irements q ua lity ag reement a rchitectu re detai led desig n development implementation SE, Software Archi tectu re, Hans van Vliet, ©2008 6 A rch itecture i n the li fe cycle sta keholders (ma ny) req u irements q ua lity a rchitectu re ag reement development SE, Software Archi tectu re, Hans van Vliet, ©2008 7 Characteristics  Iteration on both functional and q uality req uirements  Many stakeholders involved  Balancing of functional and q uality req uirements SE, Software Archi tectu re, Hans van Vliet, ©2008 8 Why Is A rch itecture Im portant?  A rchitecture is the vehicle for stakeholder com m un ication  A rchitecture man ifests the earliest set of desig n decisions  Constraints on implementation  Dictates ( control ) organ izational structure  In hibits (disable ) or enable quality attributes  A rchitecture is a transferable abstraction of a system  Product lines share a common architecture  A llows for template-based development  Basis for train ing SE, Software Archi tectu re, Hans van Vliet, ©2008 9 Where d id it start?  1992: Perry & Wolf  1987: J.A. Zachman; 1989: M. Shaw  1978/79: David parnas, prog ram fam i lies  1972 (1969): Edsger Dij kstra, prog ram fam i lies  1969: I.P. Sharp @ NATO Software Engineering conference: “I thin k we have something in addition to software engineering , A rchi tecture is different from engineering.” SE, Software Archi tectu re, Hans van Vliet, ©2008 10 Software arch itecture, defi n ition (1) The architecture of a software system defines that system in terms of c om putational com ponents and interactions among those com ponents. (from Shaw and Garlan, Software A rch itecture, Perspectives on an Eme rgi ng Disci pli ne, Prentice-Hall, 1996.) SE, Software Archi tectu re, Hans van Vliet, ©2008 1 Software A rch itecture statement  procedure  modu le  (desig n) pattern  architecture SE, Software Archi tectu re, Hans van Vliet, ©2008 12 Software A rch itecture, defi n ition (2) The software architecture of a system is the structure or structures of t he system, which com prise (contains) software elements, the externally visible properties of those elements, and the relationshi ps among them. (from Bass, Clements, and Kazman, Software A rch itecture i n Practice, SEI Series in Software Engineering. Addison-Wesley, 2003.) SE, Software Archi tectu re, Hans van Vliet, ©2008 13 Software A rch itecture  Im portant issues raised in this defin ition:  mu lti ple system structu res;  externally vi sible (observable) properties of components.  The defin ition does not include:  the process;  ru les and gu ideli nes;  arch itectu ral styles. SE, Software Archi tectu re, Hans van Vliet, ©2008 14 A rch itecture & Organ ization 1  A rchitecture is those attributes visible to the prog ram mer  Instructi on set, nu mber of bits used for data representati on, I/O mechani sms, add r essi ng tech niq ues.  Organ ization is how features are im plemented  Control signals, i nterfaces, memory tech nology.  e.g. Is there a hard ware mu lti ply u nit or i s it done by repeated additi on? Structure & Function  Structure is the way in which com ponents relate to each other  Function is the operation of individual com ponents as part of the structur e A rch itectural Structures  modu le structure  conceptual, or logical structure  process, or coordination structure  physical structure  uses structure  calls structure  data flow  control flow  class structure SE, Software Archi tectu re, Hans van Vliet, ©2008 17 Software A rch itecture, defi n ition (3) A rchitecture is the fundamental organ ization of a system embodied (sh aped ) in its com ponents, their relationshi ps to each other and to the en viron ment and the princi ples g uiding its desig n and evolution (from IEEE Standard on the Recom mended Practice for A rchitectural D escri ptions, 2000.) SE, Software Archi tectu re, Hans van Vliet, ©2008 18 Software A rch itecture  A rchitecture is conceptual.  A rchitecture is about fundamental of things.  A rchitecture exists in some context. SE, Software Archi tectu re, Hans van Vliet, ©2008 19 Other poi nts of view  A rchitecture is high-level desig n  A rchitecture is overall structure of the system  A rchitecture is the structure, including the princi ples and g uidelines g overn ing their desig n and evolution over time  A rchitecture is com ponents and con nectors SE, Software Archi tectu re, Hans van Vliet, ©2008 20 Software A rch itecture & Quality  The notion of q uality is central in software architecting: a software arc hitecture is devised to gain insight in the q ualities of a system at the e arliest possible stage.  Some q ualities are observable via execution: performance, security, avai labi lity, functionality, usabi lity  A nd some are not observable via execution: modifiabi lity, portabi lity, re usabi lity, integ rabi lity, testabi lity SE, Software Archi tectu re, Hans van Vliet, ©2008 21 Overview  What is it, why bother?  A rchitecture Desig n  Viewpoints and view models  A rchitectural sty les  A rchitecture asssessment  Role of the software architect SE, Software Archi tectu re, Hans van Vliet, ©2008 22 A ttribute-Driven Design (Bass et al, Ch 7)  Choose modu le to decom pose  Refine this modu le:  choose arch itectu ral d rivers (q uality i s d rivi ng force)  choose pattern that sati sfies d rivers  apply pattern  Repeat steps SE, Software Archi tectu re, Hans van Vliet, ©2008 23 Exam ple A DD iterations  Top-level: usabi lity  separate user interface  Seeheim/three tier a rchitecture  Lower-level, within user interface: security  authenticate users  Lower-level, within data layer: avai labi lity  active redundancy SE, Software Archi tectu re, Hans van Vliet, ©2008 24 Generalized model  Understand problem  Solve it  Evaluate solution SE, Software Archi tectu re, Hans van Vliet, ©2008 25 Global workflow i n arch itecture design synthesi s arch itectu re context backlog evaluati on evaluati on req u i rements resu lts SE, Software Archi tectu re, Hans van Vliet, ©2008 26 Generalized model (cont’d) assets a rchitectu re ideas synthesis backlog eva luation constraints eva l resu lts sig n.req s SE, Software Archi tectu re, Hans van Vliet, ©2008 27 Design issues, options and decisions A desig ner is faced with a series of design issues  These are sub-problems of the overall design problem.  Each i ssue normally has several alternative soluti ons (or design options)  The designer makes a design decision to resolve each i ssue.  Th i s process i nvolves choosi ng the best opti on from among the alternatives. SE, Software Archi tectu re, Hans van Vliet, ©2008 28  Taki ng decisions Design Problem space problem sub- sub- problem problem (or issue) (or issue) Decision = best option Decision space Design Design Design Design option option option option Decision = A lternative best option A lternative solutions solutions SE, Software Archi tectu re, Hans van Vliet, ©2008 29  Decision space The space of possible desig ns that can be achieved by choosing different s ets of alternatives. fat-client client in a sepa rate Prog ra mmed in Java client-server u ser interface client layer sty le thin-client Prog ra mmed in Visua l Basic Prog ra mmed in C++ no sepa rate monolithic u ser interface layer SE, Software Archi tectu re, Hans van Vliet, ©2008 30  Tree or graph?  Issues and options are not independent... fat-client client in a sepa rate flexibi lity client-server u ser interface client layer sty le thin-client layered MVC no sepa rate monolithic u ser interface layer SE, Software Archi tectu re, Hans van Vliet, ©2008 31 More than just IT  Techn ical and non-techical issues and options are intertwined  A rch itects decidi ng on the ty pe of database versus  Management decidi ng on new strategic partnersh i p or  Management decidi ng on budget SE, Software Archi tectu re, Hans van Vliet, ©2008 32 Some (tacit) decisions are related to norms and values SE, Software Archi tectu re, Hans van Vliet, ©2008 33 Ty pes of decisions  Im plicit, undocumented  Unaware, tacit, of cou rse know ledge  Explicit, undocumented  Vaporizes over ti me  Explicit, explicitly undocumented  Tactical, personal reasons  Explicit, documented  Preferred, excepti onal situati on SE, Software Archi tectu re, Hans van Vliet, ©2008 34 Why is documenti ng design decisions i m portant?  Prevents repeating (expensive) past steps  Explains why this is a good architecture  Em phasizes q ualities and criticality for req uirements/goals  Provides context and backg round SE, Software Archi tectu re, Hans van Vliet, ©2008 35 Uses of design decisions  Identify key decisions for a stakeholder  Make the key deci si ons q u ickly avai lable. E.g., i ntrod uci ng new people and make t hem u p2date. ..., Get a rati onale, Validate deci si ons agai nst reqs  Evaluate im pact  If we want to change an element, w hat are the elements i mpacted (deci si ons, des ign, i ssues)? ..., Cleanu p the arch itectu re, identi fy i mportant arch itectu ral d rivers SE, Software Archi tectu re, Hans van Vliet, ©2008 36 Elements of a design decision  Issues: desig n issues being addressed  Decision  Status: e.g., pending, approved  Assum ptions: underly ing assum ptions  A lternatives  Rationale; the why of the decision taken  Im plications: e.g. need for further decisions SE, Software Archi tectu re, Hans van Vliet, ©2008 37 Poi nters on design decisions  Hofmei ster et al, Generalizi ng a Model of Software A rch itectu re Design from Five In d ustrial A pproaches, Jou rnal of Systems and Software, 2007  Tyree and Ackerman, A rch itectu re deci si ons: demysti fyi ng arch itectu re, IEEE Softwa re, vol. 22(2), 2005.  Kruchten, Lago and van Vliet, Bu i ldi ng u p and exploiti ng arch itectu ral know ledge, WI CSA, 2005.  Lago and van Vliet, Explicit assu mpti ons enrich arch itectu ral models, ICSE, 2005. SE, Software Archi tectu re, Hans van Vliet, ©2008 38 Overview  What is it, why bother?  A rchitecture Desig n  Viewpoints and view models  A rchitectural sty les  A rchitecture asssessment  Role of the software architect SE, Software Archi tectu re, Hans van Vliet, ©2008 39 Software design i n UML  Class diag rams, state diag rams, seq uence diag ram, etc  Who can read those diag rams?  Which ty pe of q uestions do they answer?  Do they provide enough information? SE, Software Archi tectu re, Hans van Vliet, ©2008 40 Who can read those d iagrams?  Desig ner, prog ram mer, tester, maintainer, etc.  Client?  User? SE, Software Archi tectu re, Hans van Vliet, ©2008 41 Wh ich ty pe of q uestions do they answer?  How m uch wi ll it cost?  How secure wi ll the system be?  Wi ll it perform?  How about maintenance cost?  What if req uirement A is replaced by req uirement B? SE, Software Archi tectu re, Hans van Vliet, ©2008 42 A nalogy with bui ld i ng arch itecture  Overall picture of bui lding (client)  Front view (client, “beauty” com m ittee)  Separate picture for water su pply (plumber)  Separate picture for electrical wiring (electrician)  etc SE, Software Archi tectu re, Hans van Vliet, ©2008 43 A rch itecture presentations i n practice  By and large two flavors:  Powerpoi nt slides – for managers, users, consu ltants, etc  UML diagrams, for tech nicians  A small sam ple … SE, Software Archi tectu re, Hans van Vliet, ©2008 44 SE, Software Archi tectu re, Hans van Vliet, ©2008 45 SE, Software Archi tectu re, Hans van Vliet, ©2008 46 SE, Software Archi tectu re, Hans van Vliet, ©2008 47 SE, Software Archi tectu re, Hans van Vliet, ©2008 48 SE, Software Archi tectu re, Hans van Vliet, ©2008 49 So, …  Different representations  For different people  For different purposes  These representations are both descri ptive and prescri ptive SE, Software Archi tectu re, Hans van Vliet, ©2008 50 IEEE model for arch itectural descri ptions SE, Software Archi tectu re, Hans van Vliet, ©2008 51 Some terms (from IEEE standard)  System stakeholder: an individual, team, or organ ization (or classes her eof) with interests in, or concerns relative to, a system.  View: a representation of a whole system from the perspective of a relat ed set of concerns.  Viewpoint: A viewpoint establishes the purposes and audience for a view and the techn iq ues or methods em ployed in constructing a view. SE, Software Archi tectu re, Hans van Vliet, ©2008 52 Stakeholders  A rchitect  Req uirements engineer  Desig ner (also of other systems)  Im plementor  Tester, integ rator  Maintainer  Manager  Quality assurance people SE, Software Archi tectu re, Hans van Vliet, ©2008 53 Viewpoi nt speci fication  Viewpoint name  Stakeholders addressed  Concerns addressed  Lang uage, modeling techn iq ues SE, Software Archi tectu re, Hans van Vliet, ©2008 54 Kruchten’s 4+1 view model SE, Software Archi tectu re, Hans van Vliet, ©2008 55 4 + 1: Logical Viewpoi nt  The logical viewpoint su pports the functional req uirements, i.e., the ser vices the system shou ld provide to its end users.  Ty pically, it shows the key abstractions (e.g., classes and interactions a mongst them). SE, Software Archi tectu re, Hans van Vliet, ©2008 56 4 + 1: Process Viewpoi nt  Addresses concurrent aspects at runtime (tasks, threads, processes and their interactions)  It takes into account some nonfunctional req uirements, such as perform ance, system avai labi lity, concurrency and distribution, system integ rit y, and fau lt-tolerance. SE, Software Archi tectu re, Hans van Vliet, ©2008 57 4 + 1: Deploy ment Viewpoi nt  The deploy ment viewpoint defines how the various elements identified i n the logical, process, and im plementation viewpoints-networks, process es, tasks, and objects-m ust be mapped onto the various nodes.  It takes into account the system's nonfunctional req uirements such as sy stem avai labi lity, reliabi lity (fau lt-tolerance), performance (through put ), and scalabi lity. SE, Software Archi tectu re, Hans van Vliet, ©2008 58 4 + 1: Im plementation Viewpoi nt  The im lementation viewpoint focuses on the organ ization of the actual s oftware modu les in the software-development environ ment.  The software is packaged in small chun ks-prog ram libraries or subsyste ms-that can be developed by one or more developers. SE, Software Archi tectu re, Hans van Vliet, ©2008 59 4 + 1: Scenario Viewpoi nt  The scenario viewpoint consists of a small subset of im portant scenarios (e.g., use cases) to show that the elements of the four viewpoints work together seam lessly.  This viewpoint is redundant with the other ones (hence the "+1"), but it plays two critical roles:  it acts as a driver to help designers discover architectural elements during the architect ure design;  it validates and i llustrates the architecture design, both on paper and as the starting poin t for the tests of an architectural prototy pe. SE, Software Archi tectu re, Hans van Vliet, ©2008 60 A rch itectural views from Bass et al
(view = representation of a structure)  Modu le views  Module is un it of implementation  Decomposition, uses, layered, class  Com ponent and con nector (C & C) views  These are runtime elements  Process (commun ication), concurrency, shared data (repository), client-server  A llocation views  Relationship between software elements and environ ment  Work assign ment, deploy ment, implementation SE, Software Archi tectu re, Hans van Vliet, ©2008 61 Mod ule views  Decom position: un its are related by “is a submodu le of”, larger modu les are com posed of smaller ones  Uses: relation is “uses” (calls, passes information to, etc). Im portant for modifiabi lity  Layered is special case of uses, layer n can on ly use modu les from layers