طراحی و مدل کردن مولفه ها

صفحه 1:
ai ‏و‎ 

صفحه 2:
ON ۱ Caen kena cd 000007-95 5 ‏اا‎ BUCA Rac can ‏عدا صا‎ aa aaa One ‏ی‎ acted 

صفحه 3:
و فا سای سس مس اس ‎am‏ 2 oe eee © Get nstower Peedback © erate thoouk severd releases, rack wi cew 070000 ra cans ‏ل اا‎ co ceca ad ET) ‏ا ا‎ | a ea cas ca DRCNet Baran Ceca cca RC RAs acca ‏مص‎ ‏مس‎ 

صفحه 4:
‎de Ole‏ 0 اله ‎(Coad)‏ ‎DET 2-7 ‎A ‏ل‎ cee a a aC oN ena ۱ ‏ی‎ oe en ccd ‎© Dke ‏ل‎ oo the architecture Ned hace oe Raed (nce ae tert JO) ‎© Ovuwe the ochitecturd ddvers are kaown, the Na Ne oR at ‎© Dke require wes undysis provess will thea be DN RCA at Cdn cect ARN can ee at aE cd ‎ 

صفحه 5:
Opole aay PN asia bd 

صفحه 6:
‎blanca aad‏ ا ل 00 اله ‎ord‏ ا الك ‎OAS ‏وص‎ ‎ ‎(®OO) can be wed ‏ماه رت )۱ ‎a AN As ae‏ سا ‎1۱۳۹ 0 ee Ne Aas RCo NCA PA RON Ea Ouihied Provess (ROP). ‎ 

صفحه 7:
‎ceca!‏ لق اله ‎5 ‏ل ا ا ل‎ NO AS a oe eee ee oe ae ‎4s a recursive decowpostiva process, Ta RS ‏ل‎ a as RS aoe a CS CaS ca Aer Pe FANN CANE NACE OS CZ Pac] PA CL eae aed SENSU ce ‏عدا برط لجلتنصعم ععمرؤ عنصب‎ ‏هت ده‎ ‎ 

صفحه 8:
Codd) ( Orsiqa (a Vea! ‎oa‏ ام ما ‎۹ ‎1 ‏1 ‏خأو ‏اه یمس ای ۱ عرو ‎١‏ 7052 3 هت هت ترا ۱ ۱ عا عا جوم( لس ۱ ۲ 57 ‎١‏ ‎Ne‏ ‏اك ۱ 0 ‎Ae:‏ ‎les‏ ‎ 

صفحه 9:
ا ل 000 اله ا ل 5ك ‎eaZ cd ac‏ يي ۱۳ O Whe systew ts respousible Por reistay ord OO aE an aR aa RAS ace 2 AEecd a |B | Chal Ace Ne ۱ SE DAN CASAC Sa eased Vel Cac 

صفحه 10:
0 نموه[ 0 0 a ‏ب‎ Need RN Rac acc 2 © set? gant requireweuts expressed us ۱ a oS ‏مه را‎ ‎Rrra ar ce ae Re cl‏ اا ‎the door ore dPPeredt Por the various procucts ia‏ ‎NSA CRS a a‏ ی ‎TT RR aon Be scan caries ect casa‏ ‎ 

صفحه 11:
Taput to BOD (Coad) © set oP quatiy requinewets (ova’d): ‎are)‏ ل ل ا يقت ‏ا ‏ل لي ول وس ل 0 ‎BI a Re Reed ۱ hs ca CASIO RNS SiN ol a Cat CASAL NOR cd ۱ ‏و‎ ‏او مرو‎ ‎ ‎ ‎ 

صفحه 12:
‎®OO Gteps‏ اله ‎ee RE aS a Rd ۱ 7 00 nS Ee Ee ]9 ‏من سمش مت مه مت ل‎ BO a a ea oe 00 ‏ی‎ ‏هواس عمط مت‎ Ca 210 ‏ل‎ ‎ 

صفحه 13:
الف سان الاك اله ب ۱۹۹ 0 0 ‏ا لل‎ 7 eA RE ca Bes ace cd 0 SN a AN ame eC ed PE ce Wee maces cece ean een cats) DR eae AS mS RNa ‏نله موی‎ 

صفحه 14:
‎@®OO CGteps (Coad)‏ اله ‎0 ‏ل‎ Ee eT 00 0 ‏يي‎ 0 ‏له‎ ‎as Ni Re ee] ‎ 

صفحه 15:
« 110 جم ا" 300 A a ۱ 7 Odes a ke nod eked ek woke 5355-7 

صفحه 16:
‎eed al aca‏ تس ‎rete ant nts eae nena ee‏ كت :عروة! حامج دوجس لوجر جمحووسروخاعوم دومص 13 ‎Uae anak cd‏ ا ‎ 

صفحه 17:
Cu. Chovse the Orchitevturd ۱2 (Coat'd) 0 Oe do wt red dl requreweus us equal. 0 Dis is 0 siqaPiccct dPPereace betwera POO 

صفحه 18:
لل م ‎Rene oc‏ ا ا 0 0 5 لح ی ی ‎Does ma ceca ea‏ ۱ ‎rR RC Rn aca ee co ead‏ 5 هی وت | ‎on oe COE aca ce‏ ا ۱0 ‎as VASE a RCL Ra ae‏ 

صفحه 19:
Puttera (Ova'd) ‎a ۳‏ ۸ ۲ ۲ رت ان ‎۱۳ ۳ 7/۳ Roe ag ave ‏ا لل‎ CR ei a cd Teas aM a eo cL Sa ‏".وصرحهات‎ ‎۱۳ ee es nS Na ee ‏ما6۳ مه ‎oO‏ اله ‎ 

صفحه 20:
Patera (Ovat'd) 130 at eer eer ‏ا‎ acd oe era MET ered ocr ena as Ane a acid 1 ‏ی‎ ‎| ‏مس‎ ‎۱۳ Picdl set oP tactics is therePore! 00 hee aaa RNS Ae aCe ed OT an Raa eR aR Se ۱ ‏وت‎ AOS A nae Cel a Rade 

صفحه 21:
Patera (Ovat'd) Sa a im cad aah) 8 ee A ee a od ‏رو اعورم‎ Cass cain eas a cael ACS CAS aca ASA cad 

صفحه 22:
‎mk (Dries‏ ص۱۳۹ تا ‎۳ ‎۱ ۳ ‎ 

صفحه 23:
4 کر ]) ‎Por aacrergicry‏ 6 كت ی ‎ae ee ee eT ee‏ اله ‎OD ke woorgewedt ‏ی‎ ‎Oe aN BCL pS CLC ‏ل يي‎ eh ao RRS Oe eS ea ae ‎ 

صفحه 24:
ما مزر مسرت (Coct'd) تس تا سرت وا ‎OMe di x‏ او و و | ی ‎Ber‏ ا ا ا اهنا 500 

صفحه 25:
Opever ‏ون‎ )( ay Pi 0 اله 0 sia 

صفحه 26:
(om) DEE Oe ae Rated we haan ch aed aca Receas ed ‏عصاصط ب حامن أعصتخات عدا كباصا‎ NS ‏ها خات وتحمس‎ ‏رای اه جا مطل‎ 2 every use cose of the poreot wodule aust Le a ‏موم‎ ‏و۱۳‎ A Loe ERC ‏ل‎ a ee on ad et AAR ci Vice NMS or aa OS a ae Se an aa ee ae ‏و متا اس تسیا‎ ل ل لت اله 

صفحه 27:
(Coad) ۱۳ can avid ® Oodde deoowposiivd view — Ovctacers Por DSN Ba cee ea RS RNAS cael ee A ‏ام‎ ‎® Cpwurrewy view — Opeanic uspevis ve a ۱ as es ce Deas} ‏لجاصلدجه ججا كدص بجا هكحوج وام مرو‎ همست 1" 

صفحه 28:
(Coad) 5 aad aati Cash} ec aad ai aed NR aN a ad TL IE Ata AU al a oe ec ۱ arc eee eRe ce cee eas a ad ‏رب‎ acco eT uetwork traPPiv). @ddiicodly, thie view helps to device ee SNR Re | همست 1" 

صفحه 29:
)1( ‏كو كوه عسل‎ Or aaa Cec cx ae ics Ose Cuses NE ۳۳ ۳ ۳ ‏هس‎ ‎nome hod‏ 011 كت ‎NEU cae‏ ‎ 

صفحه 30:
ات اله و SE ee ae RC ea Tae ca oe Le Rac aa ‎oe a eR eh oe‏ 4 لآ ‎DR ae‏ ‎cash ace‏ ا ‎oP structure (wodule devowposiiva view), dyoovisw‏ ‎Ronee oc oe)‏ ] ‎RN Cet CERNE a ee ce‏ ۱۹ مت ‎ 

صفحه 31:
‎een)‏ اقا ‎0 a ets fe ‏تم‎ ‎RS ee ‏ل‎ ‎See ‏د هه 02۳ .04 اله ‎۱۳ oats a Cots Se ‏و‎ oe ee ee ۱ cd SE eae a Ra cae ‏هه ا ‎sequedidizes, und perhaps blacks cols‏ ‎ 

صفحه 32:
۱ 60 0 ‏اجه‎ ‎erent een) 5 Nee er ern ty ovate on © Dhe hochowe requireweuts, suck us spevid- ‏ماس وم‎ ‏ل لاا‎ Ue Caf 000 aro OA at aR aoa aaa PA DR cas ca ‏تم و مساو سم سر مسرت‎ 5 a ‏ا‎ Maceo DM RR ROSAS 

صفحه 33:
‎Goecuivs us Coustruints‏ را لوه ‎Por the Chit Oodutes‏ ‎0 chit wodule hus respoesibiliies thot weed ty be ‏مدا ات تست ها‎ ‏یعس‎ Re maa) ‏مت‎ ‎TO eed ome ack ae cree exe ieke er acre emote aed NCAR CeCe Loca A CL LN So Ca BA a oe Sa ae Rel eR a od ‎DA ce oe a ecrmorn acc oe eRe | ee cl ‏مت‎ ‎ 

صفحه 34:
Chit Oodutes La ried Coat Asn cds cactek acacia ot as AR nod ۱ ‏ل‎ ESS CA bd Policy Puacioca ycups (ood): © Rasted/bwertay door wodde — Cvetrol actuators fo raise or lower the door. Stop the door when if INO) i ee ce a Rea ea rc SR na Pan ‏ا‎ cis ceca cn cari ۲7۲ ۲/۲ oe 

صفحه 35:
0 0 NR ele ec NCIS Eee Lec AL LN Ca Bn aA oe Cah) ©) Cow ‏وه‎ ‎Tee A asa Se eae eas ca aol ae De ‏ل‎ me acd ‏هو ا‎ مت همه سرت ۱۳ .حص ها i eo eel ON eR a cr ee acd Deas ‏هه‎ ce 

صفحه 36:
2-0 0 Por the Chi Oodutes 150 ene ann eRe Roda ae mere om ad od ‏كدان ولام" جا خام صصص وز زاس ك5‎ AIS: AD oR crac carca canoe am coe cecal ar a Deca caced ess Bo cacao Ra came SB, cites Dl cas NE poled icles aN cs ard casa aR SB acd Dd eae a ۱ a a a RS Re ۱ echoes eae Nal od aca 

صفحه 37:
eae A Oka aaa 210 5 ‏ا‎ a a eco 1۳ ons ‏ی‎ ee ee ee ee Ck ae Nae Cs ۱ acca ge aco 

صفحه 38:
Oe. ‏هر هرا‎ Ose Coser und ‏ل ااه‎ 00000 0 0 0 ‏:--ت‎ ‎۱۳ ‏وجوجحا جكلا مه و دک و هر سم‎ ۱ ‏هم و‎ ad AC ANCA NS NSIS CA He Netcast cat atc sraca none} ۱9 ‏سم‎ ASE RON DAC ad ‏ی‎ ah AB 

صفحه 39:
Op. OrrPy on Retive Ose Cuses urd (Os AC reat a an Ol rac cs oe meal od Child Oodules BO Ne ror cce remo Recei areata etiecs) to chit wodules: ربجا لج تاعمج بباجاجتاجرمومت جطا رون نوی را له سیر 00 رس 0 DIR caren careet as POL boat Bsns aR 0 لي يي ل | ‎cca eee‏ ا لل 0 

صفحه 40:
‎OrrPy ud QePice Ose Cuses urd‏ .ع9 ‎Chi Oodutes ‎TON Me ‏ل ا‎ ‎NN a CaN RCL ca) ‎AN Ro RN A eR San al DN rire g AIR as ri core a REDD cand ‏ارس ‎ ‏۱ ‏ان ‎ ‏ای ۱۳9 ‎eed ead‏ ص وول ‎PN aa cas Rs cori racrs ceca aso ci bd ‎ 

صفحه 41:
Gare Ooor Opever Cxanple LE No Ue an ard moa ao Ric tn aod Ne ae Ee Ee Bee Re ee eae NAR aac Ns cas ar eR ‏ما‎ ‎۱۳ ‏و‎ This scesariv is deleted to the ‏.عان و وی‎ Saeco eee ae ace See eRe eA Ra eA wwodule bevowes respousible Por ant usta provessor- 

صفحه 42:
Reticed Quality Goecanivs Por the Garay 8 Opever Exanvple (Cont'd) 155 eed cee choi ea a hE nome cat oe cake Cat desved, the door cust kot (or re-open) wikia ©. second. Crea a ACR ol ANN CaS RCA DL cn eo ‏يك‎ 0 ‏يي‎ ‎ANN EL ROS RSC od ee CA aL Eo CaS DSCs CAS el SASS BS Cae a CC ۱ Wn aca cg cee Beit ead SN NN Co RT FAO ‏هم همم ا‎ Dare Aa cel CL Roe ‏جومت صا أموصامح‎ a ROL Oe SEAL ۱۳ CAS Died SAS CARS DAR NS NS ocd CACC oe ۱ Cc oe cco 

صفحه 43:
“ل ا لل ال اله eT ee WTR eee eccrine erica ods cao ‏دص رت‎ ۱ ee cane | ‏ل‎ ‎| ‏ا‎ amd ۳ 0 000-0000215 ‏ع ا يمر‎ 5 

صفحه 44:
۳! Oe Git Ov Oot Kaw ‏ت۱۹‎ as ic ON al GAN amar aed NN aM ca wodudes 8 8 0-53 5 و۱۳ تست eee noe ate acreage eer cad 

صفحه 45:
0 ۳ 7 eee eee oad FN ‏ا‎ cA Noa a od Nee Ca Co DET aE enced hacia cee od ae canine Ped ا 0 نزن و تون ‎rc).‏ 

صفحه 46:
‎Structure‏ م م۱۹ اله ‎(Coct'd)‏ ‎LO ead Ee oe on ‏اج‎ ‎SE ee a ea 1۱ NB eis cons cece Viens ceed ® Or, the requireweuts Por those eleweuts were ‏سا« ا اه‎ ۳ 1۳9 een ‏ا‎ eee eee a ed FEN ea ‎ ‎ 

صفحه 47:
‎Moxa Cl ard‏ ال اله ‎(Coed)‏ ‎Ne AN Real eee a ee ea) seal domaia (area oP spevidized here Paced ‎LN aa an Ca Re Ra iE nrg ‎OD ke ePReniive use oP stoPP, therefore, is tv MeN ICA oe CA ANCA Aca ‏تا‎ ‎Se ‎ 

صفحه 48:
‎Moxa Cl ard‏ ال اله ‎(Coed)‏ ‎۲1 ‏موس‎ dos 1 Narn ae ‎RO lara a teat daca tam acd nace) NRSC aR a ac ae hl at us) ۱۳۱ RAS bcs MN CaS eI PO projects. ‎ 

صفحه 49:
ee RON hear raed eee nr oe ae crete os Renee oaecred 0 ae 0 Whe onchitecture provides a quide as to the order ia whic Fee aA bec AS ROS CACC Ca i ee ee ‏م‎ ‎Stas a ec A Ce aS cat ae | ‏ا‎ AO ce ا لل ‎RN‏ ‏ب ۱ 

صفحه 50:
| (Coet'd) ‎neta d wokeree brane ene eke ced‏ ريم ‎UEC ac‏ ‎DA ot Nod rt on Ree een neo ‏55 ۳ 5 5 = و۳ 0 ۱ 000 ‎ 

Designing the Architecture Outline  Architecture in the life cycle  Designing the architecture  Forming the team structure and its relationship to the architecture  Creating a skeletal system Architecture in the Life Cycle  The evolutionary delivery life cycle    Get customer feedback Iterate through several releases, each with new or modified functionality Deliver limited versions if necessary  When does one begin designing?  Some idea of system requirements is needed – the shaping requirements are called architectural drivers Architecture in the Life Cycle (Cont’d)  When does one begin designing? (cont’d)  Identify the highest priority business goals and turn them into quality scenarios or use cases  The ones that have the most impact on the architecture are the architectural drivers (there should be fewer than 10)  Once the architectural drivers are known, the architectural design can begin  The requirements analysis process will then be influenced by questions generated during the architectural design, Evolutionary Delivery Life Cycle Software Concept Deliver Final Version Preliminary Requirements Analysis Design of Architecture and System Core Develop a Version Incorporate Customer Feedback Deliver the Version Elicit Customer Feedback Designing the Architecture  A method called Attribute Driven Design (ADD) can be used to design an architecture to satisfy both quality and functional requirements.  ADD can be viewed as an extension to other developments methods, such as the Rational Unified Process (RUP). Attribute-Driven Design  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. Attribute-Driven Design (Cont’d)  The system is described as a set of containers for functionality and the interactions among them.  This is a coarse grained framework for achieving the functionality. Example Application of ADD  Sample problem: A garage door opener within a home information system.  The system 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. Input to ADD  A set of requirements (typically expressed as use cases) and constraints  A set of quality requirements expressed as system-specific quality scenarios including, in this case:  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 Input to ADD (Cont’d)  A set of quality requirements (cont’d):    The processor used in different products will differ. If an obstacle (person or object) is detected by the garage door during descent, it must halt (alternately re-open) within 0.1 second. The garage door opener should be accessible for diagnosis and administration from within the home information system using a product-specific diagnosis protocol. ADD Steps Choose the module to decompose – the module to start with is usually the whole system. 2. Refine the module according to the following steps: 1. a. b. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. Choose an architectural pattern that satisfies the architectural drivers based on the tactics that can be used to achieve the drivers. ADD Steps (Cont’d) 2. Refine the module according to the following steps (cont’d): c. d. Instantiate modules and allocate functionality from the use cases and represent using multiple views. Define interfaces of the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module. ADD Steps (Cont’d) 2. Refine the module according to the following steps (cont’d): e. Verify and refine use cases and quality scenarios and make them constraints for child modules. 3. Repeat the steps above for every module that needs further decomposition. 1. Choose the Modules to Decompose  In our example, we start with the whole system, the garage door opener system.  One constraint at this level is that the opener must interoperate with the home information system. 2a. Choose the Architectural Drivers  The four scenarios previously given indicate requirements for:    real-time performance modifiability to support product lines online diagnosis  In general, a detailed investigation may be required to determine whether given requirements are really drivers. 2a. Choose the Architectural Drivers (Cont’d)  We do not treat all requirements as equal.  The less important requirements are satisfied within the constraints of the most important.  This is a significant difference between ADD and other architecture design methods. 2b. Choose an Architectural Pattern  The use of an interpreter is an excellent technique for achieving modifiability at runtime, but it has a negative influence on performance.  The decision to use an interpreter depends on the relative importance of modifiability versus performance.  A possible decision is to use an interpreter for only a portion of the pattern. 2b. Choose an Architectural Pattern (Cont’d)  The modifiability tactics are “localize changes,” “prevent the ripple effect,” and “defer binding time.”  In this case, where we are concerned primarily with changes that will occur during system design, the primary tactic is “localize changes.”  We choose semantic coherence and information hiding as our tactics and combine them to define virtual machines for the affected areas. 2b. Choose an Architectural Pattern (Cont’d)  The performance tactics are “resource demand” and “resource arbitration.”  We choose one example of each: “increase computational efficiency” and “choose scheduling policy.”  The final set of tactics is therefore:  Semantic coherence and information hiding – Separate responsibilities dealing with the user interface, communication, and sensors into their own modules (virtual machines). 2b. Choose an Architectural Pattern (Cont’d)  The final set of tactics (cont’d):   Increase computational efficiency – The performance-critical computations should be made as efficient as possible. Schedule wisely – The performance-critical computations should be scheduled to ensure the achievement of the timing deadline. Architectural Pattern that Utilizes Tactics to Achieve Garage Door Drivers User Interface Non-PerformanceCritical Computation Performance-Critical Computation Virtual Machine Schedule that Guarantees Deadlines 2c. Instantiate Modules and Allocate Functionality Using Multiple Views  We allocate the responsibility for managing obstacle detection and halting the garage door to the performance-critical section since the functionality has a deadline.  The management of the normal raising and lowering of the door has no timing deadline so we can treat it as non-performance-critical 2c. Instantiate Modules and Allocate Functionality Using Multiple Views (Cont’d)  The diagnosis capabilities are also non- performance-critical.  Thus, the non-performance-critical module becomes instantiated as diagnosis and raising/lowering door modules.  We also identify several responsibilities of the virtual machine: communication and sensor reading and actuator control. First-Level Decomposition of Garage Door Opener User Interface Diagnose Communication Virtual Machine Raising/Lowering Door Sensor/Actuator Virtual Machine Obstacle Detection Scheduler that Guarantees Deadlines 2c. Instantiate Modules and Allocate Functionality Using Multiple Views (Cont’d)  Applying use cases that pertain to the parent module helps the architect gain a better understanding of the distribution of functionality.  Ultimately, every use case of the parent module must be representable by a sequence of responsibilities within the child modules.  Enough must be done to gain confidence that the system can deliver the desired functionality.  The architecture should be represented by one view from each of the three major groups. 2c. Instantiate Modules and Allocate Functionality Using Multiple Views (Cont’d)  The three common views   Module decomposition view – Containers for holding responsibilities and the major flow relationships among the modules Concurrency view – Dynamic aspects of a system such as parallel activities and synchronization can be modeled 2c. Instantiate Modules and Allocate Functionality Using Multiple Views (Cont’d)  The three common views (cont’d)  Deployment view – The virtual threads of the concurrency view are decomposed into virtual threads within a particular processor and messages that travel between processors to initiate the next entry in the sequence of actions (thus is a basis for analyzing network traffic). Additionally, this view helps to decide if multiple instances of some modules are needed and supports reasoning about special purpose hardware. Understanding Concurrency in a System – Helpful Use Cases  Two users doing similar things at the same time  One user performing multiple activities simultaneously  Starting up the system  Shutting down the system 2d. Define Interfaces of the Child Modules  An interface of a module shows the services and properties provided and required.  It documents what others can use and on what they can depend.  Analyzing and documenting the decomposition in terms of structure (module decomposition view), dynamism (concurrency view) and runtime (deployment view) uncovers the interaction assumptions for the child modules. 2d. Define Interfaces of the Child Modules (Cont’d)  The module view documents:   Producers/consumers of information Patterns of interaction that require modules to provide services and to use them  The concurrency view documents:    Interactions among threads that lead to the interface of a module providing or using a service The information that a component is active The information that a component synchronizes, sequentializes, and perhaps blocks calls 2d. Define Interfaces of the Child Modules (Cont’d)  The deployment view documents:    The hardware requirements, such as specialpurpose hardware Some timing requirements, e.g., the computational speed of a processor Communication requirements, e.g., the information should not be updated more than once a second  All this information should be available in the modules’ interface documentation. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  Each child module has responsibilities that need to be translated into use cases for the module. Use case can also be defined by splitting and refining the parent use cases.  For the garage door opener system, the responsibilities are decomposed into the following functional groups  User interface – recognize user requests and translate them into the form expected by the raising/lowering door module 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  For the garage door opener system, the responsibilities are decomposed into the following functional groups (cont’d):   Raising/lowering door module – Control actuators to raise or lower the door. Stop the door when it reaches either fully open or fully closed. Obstacle detection – recognize when an obstacle is detected and either stop the descent of the door or reverse it. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  For the garage door opener system, the responsibilities are decomposed into the following functional groups (cont’d):     Communication virtual machine – Manage all communication with the home information system. Sensor/actuator virtual machine – Manage all interactions with the sensors and actuators. Scheduler – Guarantee that the obstacle detector will meet its deadlines. Diagnosis – Manage the interactions with the home information system devoted to diagnosis. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  The constraints of the parent module can be satisfied in one of the following ways:   The decomposition satisfies the constraint, e.g., if the constraint is to use a certain operating system, by defining the operating system as a child the constraint is satisfied. The constraint is satisfied by a single child module, e.g., if the constraint is to use a special protocol, it can be satisfied by defining an encapsulation child module for the protocol. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  The constraints of the parent module can be satisfied in one of the following ways (cont’d):  The constraint is satisfied by multiple child modules, e.g., using the Web requires two modules (client and server) to implement the necessary protocols. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  In the garage door opener system, one constraint is that the communication with the home information system is maintained.  The communication virtual machine will recognize if this communication is unavailable, so the constraint is satisfied by a single child. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  Quality scenarios also need to be refined and assigned to child modules:   A quality scenario may be completely satisfied by the decomposition without any additional impact and thereby marked as satisfied. A quality scenario may be satisfied by the current decomposition with constraints on child modules. 2e. Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules  Quality scenarios also need to be refined and assigned to child modules (cont’d):   The decomposition may be neutral with respect to a quality scenario, e.g., a usability scenario, in which case it should be assigned to one of the child modules. A quality scenario may not be satisfiable with the current decomposition. Either the decomposition should be reconsidered or rationale justifying its omission must be provided. Refined Quality Scenarios for the Garage Door Opener Example  The devices and controls for opening and closing the door are different for different products in the product line. They may include controls from within a home information system. This scenario is delegated to the user interface module.  The processor used in different products will differ. This scenario is delegated to all of the modules. Each module becomes responsible for not using processorspecific features not supported by standard compilers. Refined Quality Scenarios for the Garage Door Opener Example (Cont’d)  If an obstacle is detected by the garage door during descent, the door must halt (or re-open) within 0.1 second. This scenario is delegated to the scheduler and the obstacle detection module.  The garage door opener should be accessible for diagnosis and administration from within the home information system using a product-specific diagnosis protocol. This scenario is split between the diagnosis and communication modules. The communication module is responsible for the protocol to communicate with the home information system, and the diagnosis module is responsible for other diagnosis interactions. Status at the End of the Iteration  We now have a decomposition of a module into its children.  Each child has a collection of responsibilities:     A set of use cases An interface Quality scenarios A collection of constraints  This is sufficient to start the next iteration of the decomposition Things We Still Do Not Know Regarding Our Sample Problem  The language for communication between the user interface module and the raising/lowering modules  The algorithm for performing obstacle detection  How the performance-critical section communicates with the non-performance critical section Forming the Team Structure  Once the first few levels of the architecture’s module decomposition structure are fairly stable, those modules can be allocated to development teams.  Within teams there needs to be high-bandwidth communications.  Between teams, low-bandwidth communications are sufficient (and in fact crucial). Forming the Team Structure (Cont’d)  If interactions between the teams is complex, either:   The interactions among the elements they are creating are needlessly complex Or, the requirements for those elements were not sufficiently “hardened” before development commenced  Like software systems, teams should strive for high cohesion and low coupling. Forming the Team Structure (Cont’d)  Each module of the system constitutes its own small domain (area of specialized knowledge or expertise).  This makes for a natural fit between teams and modules of the decomposition structure.  The effective use of staff, therefore, is to assign members to a team based on their expertise. Forming the Team Structure (Cont’d)  The organizational structure also affects the architecture.  Organizational entities formed for one project are motivated to preserve their existence and will want to maximize their importance in new projects. Creating a Skeletal System  Once an architecture is sufficiently designed and teams are in place to build it, a skeletal system can be constructed.  The architecture provides a guide as to the order in which portions of the system should be implemented.   First implement the software that deals with the execution and interaction of architectural components. Add some simple functions.  The result is a running system onto which useful functionality can be added Creating a Skeletal System (Cont’d)  To lower risk the most problematic functions should be added first.  Then the functionality needed to support those problematic functions is added.  This process is continued, growing larger and larger increments of the system until it is complete.