Software Architecture and the UML

صفحه 1:
‎aad‏ مت را(00©) عدا أده ‎Grady Ooock ‎ 

صفحه 2:
Can be built by one person Requires Minimal modeling Simple process Simple tools 

صفحه 3:
ilt most efficiently and timely by a team equires Modeling Well-defined process Power tools 

صفحه 4:


صفحه 5:
الس مانا ‎ee‏ 

صفحه 6:
cd ۳ 6 0 od 

صفحه 7:
RATIONAL 

صفحه 8:
مس له ص ما 0 ener ‏شیاه‎ ee ۱ 5 ا 0 (6۳) و نك ‎ie Oodera wovewedt (Oright, LeCorbusier)‏ 

صفحه 9:
تاس یمه سسوم ری دا 7 LCA cai Bn ANS IN UAC NAN CPA A CaS مس سر سرا ache SPINS Cacao ‎Oc aid‏ و ‎a ACS SN Co NLDA oa NS No‏ رت ‎0 ‏عمجم 2 سا راو ‎ 

صفحه 10:
۱ to vivid achitertune 1 ۴ ‏دما‎ ‎ee ‎“lhe ba 9 5 ۳ ‏مب ها یرت‎ -Odw heme - ea aie ‏تس‎ Cd ede a ee ad ‏اس ام ای یت‎ Ra et Ree 0 

صفحه 11:
‎aeel‏ وس تا ‎ 

صفحه 12:
تست اجه مه و9 ۳ 5 coh dents ‏سای 4و‎ | 

صفحه 13:
(aa EOE ia 5 Functionality 992۹ Compatibility Capacity ۹ ‏وم‎ > ۳ Availability —> 7 <=—Fault tolerance sy Ac ir) SS (۱۱۱6 / Throughput Technology churn ‏كات لتنا‎ ie challenge over the next 20 years will not be speed or cost or perform will be a question of complexity. Raduchel, Chief Strategy Officer, Sun Microsystems Our enemy is complexity, and it’s our goal to kill it. ۳ 

صفحه 14:
OI at Ee gr cad a] ‎aad Leen)‏ انا 0و لت ‎res‏ ‏ات 6 | تا ميات مشا بر رس ‏5۵ وه ورن ‎sta Tt‏ نامه ‎ ‎7 ‎Definerha “how”‏ ا ‎ ‎ ‎ ‎ ‎Pligg ‎re ‏توت ات لت ‏ووععممط ‏ات ‎ 

صفحه 15:
022025-85 دص اا ee ‏جك كك‎ ees افص لكا ری ری ار کی مرو مره و یو ی رورت وس 1 امس او ع لا اا د ۱ مت يت اننا (iil Shoo oe oe ‏اما دمم سس مس سم‎ Mee a Rela asa اي اك 

صفحه 16:
| ‏وت‎ eel eal eee ۵ رس هه هس سم ‎evict eae DA Nake a Bes a ea a‏ ۱۳ ‎oa‏ م ‎OAS ce ASIA SCA ASE La aN‏ ‎Sb‏ ۱ ‎Ne ea cael CRIN UEC ae Nace eae ad‏ ‎structure <the upvel backs ~>‏ 

صفحه 17:
Orchitevture dePiced (oa) me > ۱4۳2 architecture purowpusses the set oP SNe Ae INN Ct oa Cana ‏ل‎ AN) aS ST ۱ ‏هواس سا مت مه دا متس‎ cd AN ON eo ae a 1 LCL CAS CISC ‏عومكاا‎ ‏سس تا‎ Deas, eed ACR cence aU ee Ree ‏جلوجصوصات امسصصد‎ ES Pale nd ci oaN o220 irl card rans ia ee Ber PL ce ase NSCs coe ca as ‏تمه‎ 

صفحه 18:
عصحر ‎DACA aN CARSON BN Cie‏ امه لت جوم ‎esd‏ 00 ‎ 

صفحه 19:
©0000 وس وت ویو ۴و بامه ه حول ارزو متام و) خ مه ۱ 7 Sa ee ee Ne ae ONS AEBS, CAN CAN SARS ACA id cae Ocoee 0 ae ha oe AE VOM SUA aE ce CANT Neca Ee eA NCS oe ‏ل‎ ‎Pee emcee rac eca ceo a oie esr cas arated ۱ ceca ol vas oa 

صفحه 20:


صفحه 21:
۱ مس Valen ceed ned ck cae ean aera نها مورو با ناهوس ست طعلن() خ فاعم | راچد > Oise wodels, bluepricts 0 en coi Ra hs aot aca e apa aa aa ‏و‎ 

صفحه 22:
NA aed RAN, ea > Orchterture ‏ما روم ها‎ to ‏مخ روم‎ ۱۳ Pan ce وت ورس تياد Poet wocager eel ES Aca cial ای 7 viker developers > Oulidkrecsizcd rect > Dutiple stakeholders ۲ OE ceca 

صفحه 23:
Orchtecturd view > @a achiecturd view ts u siwplPted descriptiva 000 clas cca) Re cA AS Cac Dee ‏حور رو ار و وه‎ ۱ ‏تم‎ ‎۱ 

صفحه 24:


صفحه 25:
سس سم مت تست هب9 ‎aoe‏ 0 ern 0 عصس اه مه موه وال < اا ماو اه ‎ee‏ 0 ‎at 8‏ موم عوومولن) خ ‎ 

صفحه 26:
Implementation View Programmers Software management Deployment View System engineering System topology Delivery, installation Communication | RATIONAL Logical View Functionality Process System integrators W Performance Scalability Throughput 

صفحه 27:


صفحه 28:
Wow wey views? اصمسه لا 2۱ ها عاطلسب للم خ جرب ‎Ake tele serena ake ey‏ ‎Giclee provessor: drop deploysedt view‏ ‎Gingle provess: drop provess view‏ ‎tara eC ar or, od casio ees Og‏ 00ت ‎@ddhoy views!‏ > Ota view, sevurity view 

صفحه 29:
۱ و صاصروعتناا | 0 > ۱ crn erica CN ENN Aa an DOW UT ‎a‏ موی ح ‎ 

صفحه 30:
کر 6 OMG Acceptance, Nov 1997 Final submission to OMG, Sep ‘97 1 a Coke Cee Le 2 UML partners UML 1.0 ee Teel UML 0.9 OOPSLA ‘95 Unified Method 0.8 Other methods Booch method ‏وله‎ 005۴ 

صفحه 31:
۱۱/۱/۹۵ تمس نا امس وس ۳ و ۳ راخ 9 ۷ Wee Ne تست كاقل و اسان 9 aoa سا1 00 ee Cav ioad 2 00 VVVVVVVY ۳ 

صفحه 32:
Oa AU Asal PAOLO) Harel ‎Gamma, et al‏ وت ت۱ ‎Statecharts‏ ‎er ET re Ce LTR eT aren‏ 1 ‎conditions‏ ‎HP Fusion‏ تفر 0 کوهنام 0256 009۳2600 ‎aired‏ | = 0وطاعجم ۱ ‎Embley‏ ةم معنا 7 ۳ وى الس ا انين ‎LANGUAGE Tae oe)‏ ‎eens‏ 4 م 4 یتسین ‎[cele ve‏ ‎ees Responsibilities‏ ‎Odell‏ ۸۲ - 5۱۵6۲ ‎Object lifecycles Classification ‎ 

صفحه 33:
Overview oF the DOL < ۳ AO an aa UNIFIED MODELIN LANGUAGE 

صفحه 34:
ا هتسسگ 01 SS Gia 02 مب < 

صفحه 35:
‎Cleweuts‏ سم ‎0 ‎RS a RS ees nC ae ‏,امجدممددمت ,عجدات جمطامهد‎ ca cd 5 ‏موه‎ ‎۱ aS Ras CNS > Croup pees pockuye, subspstew 7” 1 ‎0 ‏وا ‎۵ ۵ transformations ‎ ‎ ‎ 

صفحه 36:


صفحه 37:
tagged value Femava(n : Inte 

صفحه 38:
Oe om Oiews, ‏مسر در كت‎ model is a complete scription of a system ‏ا ل اناه‎ ‏ع اأناعع مومه‎ 

صفحه 39:
4۱/۹ va CON Nata aR UUM acoA ot ‏كا‎ ae eR ae ad ON a ‎cdc cd ard‏ لي ا ‎Oecd‏ عجكاه كلابب اوجاكتكووص الدج ‎rae‏ ۱۸ ‎dt KOO eee CT ‏ا‎ Rn aR aoe ca Aaa ries ‏هم‎ ‎Oa ‏ا‎ ‏سس‎ ‎ 

صفحه 40:
Receive pho Use scheduler system boundary — Cellular Telephone 

صفحه 41:
ل 6210ل ‎arene cra 5 hyp by‏ 0 0 ‎ult ia cody stayes oP develop‏ 2 ری ‎a‏ ‎Ce a weer ee ee‏ ‎eee eS‏ جنا 0 ل ا 20111111111111 11 و ا > 

صفحه 42:
(Oo ON acitrd > Cuptures the vocabulary oP a spstew 

صفحه 43:
21 ‏زر ۱6 و‎ 4 > ۱۱۶2۹ Mar a ca Daa AUN Dc aerial] دوووس ) و ‎casa mE Neca ase‏ 10 ‎CT BRN as asd‏ ‎Ce BALA at RS asc a ASA‏ Pak en Caen oe oe eee ‏ترا‎ 

صفحه 44:
0 ‏0ادورهاموو‎ > 462 tile = “VP of Sale: 

صفحه 45:
Oy ‏را‎ ane, اسب م6 ط سس ورس تشه ‎Purpose‏ > Gee dM aa aad ‏ما‎ > ‏ل‎ eee Panera ‏ا‎ ‎NaS ed 

صفحه 46:
۱0 One mcnerd ۲ ١ ۵ executable 

صفحه 47:
ام مر سم مه او وج یب در ‎CAT‏ هر | ‎Bult os port of achiterturd sperPicct‏ > ‎are‏ خ لو مرس سیم ‎cd‏ لجحجوج جه اسسصاوو )0‏ ‎Core eat Rca‏ ‎acd‏ پر سس( ‎ 

صفحه 48:
“processor ‘processor leaching server icaching server networks I processor «processor» server server «| ‘processor processor» primary server, server | RATIONAL 

صفحه 49:
دجوعند(1) اججدوررصاحج (]) 01 at ae dd es a > Bult os pot of architecturd specification 0 يي ‎Cee eM aA‏ مس مس مت ا ‎Oe eR A‏ و ‎NN or ONAN cc acd‏ 

صفحه 50:
Interaction ‎message‏ اعطق ‎ 

صفحه 51:
)8 ‏ععجروج‎ ON echt > Purpose ۱٩ام ‏ام مات‎ Ne eee Wel rs Roa cane eed 

صفحه 52:
collaboration diagrary| 

صفحه 53:
67 ant Oi ached Nees ‏تناكف‎ eae as acl A Ne et oe ‏ل‎ act 

صفحه 54:
nested state guard action 

صفحه 55:
م ص۹۱ ‎(Coal‏ ‏سم تست اناما وتو الج با د > Purpose ‏لك‎ ‏ل 0 ل‎ devices, et.) 

صفحه 56:


صفحه 57:
۱6/۳ ۹ nner < ‏امس رس ییاجر جببین)‎ 9 (Purpose Oodel busicess workPows عوصةسججرت أعلكن(]) 

صفحه 58:
Implementation View Design View Emlasses, interfaces, ep liaborations Process View Deployment View ctive classes Organization 

صفحه 59:
تمه دمص مت Ce ‏و و‎ Oars DOAN a RAN Na cic ND CANN PAU oa PAA eT ‏اود‎ ae cds a Pe ‏عاد‎ CAA NONI ANN ‏شحف‎ ۰ ‎Orchitecturd provess‏ و ‎rl ccd ad‏ ممم جكاا صا لمجا اكلا جصارهامه خأم جموجدوج 8) ماس سم 1 ‎iat‏ 10 ‎ 

صفحه 60:
تم اه ده دا نمی < 01 ere ae a Val eerie a ot 0 Ne ere aan 

صفحه 61:
Mo تست م۱ 

صفحه 62:
ع و هت ‎Key‏ > Pkose, Tercivas ‏ما(‎ oes: 7 0 eid جما ص دا(0 ‎aad‏ نا ‎eed ‘Oka 3‏ 0 ‎proses‏ سم مه سم ما ‎0 0 eri? ‎ 

صفحه 63:
| ec) se ea cn aCcneotay Transition OePice the svope of the project oot develop busisess vase ‎a‏ و۱ ‎ae‏ سم هر ‏مور ‏وموك صلا صا امسعصصحم ‎Dee oe‏ ‏كنك ‎ 

صفحه 64:
وصدصاوصا(1) عجره (1) | كنك ۹ 4 ۹ ۹ Vision ۱ ‏الیل دییات‎ Product Architecture Capability ‏تستات ها‎ 

صفحه 65:
‎acd :‏ هت او هت )۱ ‏ا | ا( __| ‏1 0 1 0 "اعد ‎1 ‎0 ‎1 ‎Alecia ۱ ‎۱ 0 ‏1 0 1 ا 0 ل لت ‎Iteration, _; Iteration,‏ ‎ ‎AAAAA A A A ‎led‏ ات ات ات وا ات وتات را ‎An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable release ‎ ‎ ‎ 

صفحه 66:
سس سم ا ططلن() خ ‎Ae aN RO NON Ra aN acd‏ > Dke Ouihied Proves presuribes the survessive rehicewedt oP oo exevutble urchitevtune ۱ کیت 

صفحه 67:


صفحه 68:


صفحه 69:
0 3 on > Oot everpihiag is acchitectune ON NI CN eM ‏وعوكهات‎ ‎۱۸ BRST Ns cane ‏ها هم م۱‎ 0 UN ‏مس وی‎ Va ars RC ei aed lara ar ak ec) 

صفحه 70:
0 ‏او له‎ el an OR ae een ne mae eg ne ees beste eae 0 trade ee emcee ۱۳ oN ca Re eared ee 0 nn or tae = a rence Ran a aac ced ‏سم‎ | ok eed aren 0 carn aad 25-5 

صفحه 71:


صفحه 72:
(esd ‏ی جات لو سا سیم ()) ا‎ ee 02 1 Pa ‏ا‎ ene ere Lg ASA ce Pict aS RRR AACS > Ol welbstructured spstews ure Pull oP putteras dios ۱0۱ ‏اا‎ potteras 

صفحه 73:
مس وس( (OT Cand 2 ‏ل‎ 0 * Os Td نون ۰ سین ۰ وا و مق ‎Pres, ates, shots‏ * ‎٠ 05‏ مهن ۰ 0 ‏ب ا ا‎ oe 0 ‏ا ا‎ rece 000“ 00 0 ee eae 0 aye ne eee یه ۰ 

صفحه 74:
یت QOestya putercs > Creciowd poterus Clean ae Care eed ” aa a ۱0 cad ‏لس‎ ‏و‎ Va eas cs acd 9 respoosibttiy Deda 9 07 ure the soul oP oc architecture 

صفحه 75:
Command: 1 Command ل ‎Command‏ Received یه ] Command \ Invoker Menuitem | 

صفحه 76:
‎(vou)‏ هت مات هه بت ما ‎‘addCommand() ‎ ‎ ‎ 

صفحه 77:
امس هتم لته هه بت ما executel ‏و‎ ۱ 

صفحه 78:
ام ها م۱۱ 00 ۰. 000 10 ۰ لس مس رم ‎acl‏ ل لاك ‎ved Filters + Disposuble‏ ۱۹ ‎(Nocera eas aed‏ CO esas! oterpreter Rue-bused 

صفحه 79:


صفحه 80:


صفحه 81:
RATIONAL 

صفحه 82:
از مه سونو ۱۳ هم سم ‎Omer‏ مرو 

صفحه 83:
۲ 4 و وه( 0 acd ea a a 0 ee ao Va en een at ra < arn er aed eed 

صفحه 84:
اس رو عمج جك الجطااونا و عه رج د ا 0 > Oot the project woeeyer * Out “ptoed at the hip” > Ovtu Dera Lean Ug ۳۳۳۲ * Purpose oP the spstew, “Pi”, Veh ean) | "0 

صفحه 85:
Gower architecture tea charter LAO ea Laan aes eae aad > Qaitatciag the acchitevturd tateqriy of the ۱ ‎aed oe eae aad‏ ممووویو) خ سل ‎> ۱۹ ACAI Dc LS NONI CAN ae eae ‏هس اه‎ Ao ‎> Or ‏ار‎ ‎ee ۲ ‎ 

صفحه 86:
هه دس مها بت سم he tPe oP a soPiwore orchitert is a troy (cord devisives woude purty io the dark. 

صفحه 87:
سس او | وسناج سوج (1) ‎va (CO) Cran Nad‏ ار لق اك اراك لس ۱۱ 17171712715 و موق و ب ا ۱۵۹۳2۹۹ ماما ا ك4 ف هديك فص ‎OTe‏ و 

صفحه 88:
مها هو اس له ۰ ول LU A TU AUC) CO RC BO AC Be Ace ae EC ea ae ‏ناك‎ LCL ۰ اا 0 00 ©0966 بعاد( مصلل 9 ا | .©0266 بحاد 0 سمط 0 Ra ‏نت0 ۵+0 ۲۲۰ ,حالس‎ 02 ar ere 1666 ‏و62‎ COM Cee eet aloe 2080. ۱ 3 | Seed ae RO mee A CO anc ered ۱ Tee ON ee eed Cola 

صفحه 89:
ere ‏مسا مسق 0 ا‎ 0 ee or ‎ee hee a Me. ROBO ed CACC‏ ات و و9 9 بو ,۳6۵ ‎1 ‎042 LO Ca IL Aces ae lee ‏نيفيك‎ Orrphe, Opper Gadde Rver, OU, Precice-Ld, (O99. ‏ا ل 010 ره ۱ ‏م 2 ‎erat oa ‎ 

صفحه 90:
0 و لل 

صفحه 91:
ا ‎KRU a Ro‏ بي نك يفف شل ,ساد 12802 ",وممصم «سوس امد جما بو اام ‎RC‏ ‏999۰ تک 9 1 000 Ca be ee ea es Kee eee Ca ees tere a Koon > Reacod Dobed Process 8.0, Ravad, Ouperta, O8, 188 < CS eK perc nee RL eee Rg ‏يك‎ AeA a AN at AU Tea Cee a 

Software Architecture and the UML Grady Booch Architecting a dog house Can be built by one person Requires Minimal modeling Simple process Simple tools Architecting a house uilt most efficiently and timely by a team equires Modeling Well-defined process Power tools Architecting a high rise Early architecture Progress - Limited knowledge of theory Modern architecture Progress - Advances in materials - Advances in analysis Scale - 5 times the span of the Pantheon - 3 times the height of Cheops Modeling a house Movements in civil architecture  Bronze age/Egyptian (Imhotep)  Grecian/Roman (Vitruvius)  Byzantine/Romanesque  Gothic Progress - Imitation of previous efforts - Learning from failure - Integration of other forces - Experimentation  Mannerism (Michelangelo, Palladio)  Baroque  Engineering/Rational/National/Romantic  Art noveau  Modern movement (Wright, LeCorbusier) Kinds of civil architecture Neufert Architect’s Data The Handbook of Building Types  Community ­ houses, flats and apartments, gardens, education, hospitals, religion  Commerce ­ shops and stores, restaurants, hotels, office buildings, banks, airports  Industry ­ industrial buildings, laboratories, farm buildings  Leisure ­ sport, theaters and cinemas, museums Forces in civil architecture Load Compression Kinds of loads - Dead loads - Live loads - Dynamic loads Tension Avoiding failure - Safety factors - Redundancy - Equilibrium Load Any time you depart from established practice, make ten times the effort, ten times the investigation. Especially on a very large project. - LeMessuier Brand, How Buildings Learn Shearing layers of change Space plan Services Stuff Structure Skin Site Walker Royce Dimensions of software complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance An average software project: - 5-10 people - 10-15 month duration - 3-5 external interfaces - Some unknowns & risks Lower management complexity - Small scale - Informal - Single stakeholder - “Products” Defense Weapon System Telecom Switch Embedded Automotive Software National Air Traffic Control System Commercial Compiler Large-Scale Organization/Entity Simulation CASE Tool Small Scientific Simulation IS Application Distributed Objects (Order Entry) Enterprise IS (Family of IS Applications) IS Application GUI/RDB (Order Entry) Business Spreadsheet Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance Defense MIS System Higher management complexity - Large scale - Contractual - Many stake holders - “Projects” Forces in Software Functionality Cost Capacity Availability Performance Technology churn Compatibility Fail safe Fault tolerance Throughput Resilience he challenge over the next 20 years will not be speed or cost or perform will be a question of complexity. Raduchel, Chief Strategy Officer, Sun Microsystems Our enemy is complexity, and it’s our goal to kill it. Jan Baan Wojtek Kozaczynski The domain of architecting The “why” The “what” Architecture Qualities Architecture Architecture Representation Produces The “who” System Features Satisfies Constrain S/W Requirements System Quality Attributes Technology Defines The “how” Follows Architect Process Skills Stakeholders Defines role Organization Philippe Kruchten We all know that ... Architecture and design are the same thing Architecture and infrastructure are the same thing <my favorite technology> is the architecture A good architecture is the work of a single architect Architecture is flat, one blueprint is enough Architecture is just structure System architecture precedes software architecture Architecture cannot be measured and validated Architecture is a Science Architecture is an Art Architecture defined (again) Merriam Webster’s Collegiate Dictionary 10th edition Architecture n (1555) 1: the art of science of building, specifically, the art or practice of designing and building structures and esp. habitable ones 2 a: formation or construction as or as if as the result of conscious act <the ~ of the garden> b: a unifying or coherent form or structure <the novel lacks ~> Architecture defined (yet again) Mary Shaw, CMU Grady Booch, Philippe Kruchten, Rich Reitman Kurt Bittner, Rational  Software architecture encompasses the set of significant decisions about the organization of a software system ­ selection of the structural elements and their interfaces by which a system is composed ­ behavior as specified in collaborations among those elements ­ composition of these structural and behavioral elements into larger subsystem ­ architectural style that guides this organization Architecture defined (continued)  Software architecture also involves ­ ­ ­ ­ ­ ­ ­ ­ usage functionality performance resilience reuse comprehensibility economic and technology constraints and tradeoffs aesthetic concerns Mary Shaw, CMU Grady Booch, Philippe Kruchten, Rich Reitman Kurt Bittner, Rational Mary Shaw, CMU Architectural style  An architecture style defines a family of systems in terms of a pattern of structural organization.  An architectural style defines ­ a vocabulary of components and connector types ­ a set of constraints on how they can be combined ­ one or more semantic models that specify how a system’s overall properties can be determined from the properties of its parts Architecture metamodel Software Architecture Software Architects is part of are actors in System architecture is represented by Architecture Design Process produces Software Architecture Description has Logical view Process view is made of relates to is a Architecture Style guide Architectural view has Architectural style is a Architectural Pattern Deployment view Use case view is made of has Implementation view constrains Form Component Connection depicts Constraints satisfies constrains Requirements Architectural Blueprint Models  Models are the language of designer, in many disciplines  Models are representations of the system to-be-built or as-built  Models are vehicle for communications with various stakeholders  Visual models, blueprints  Scale  Models allow reasoning about some characteristic of the real system Many stakeholders, many views  Architecture is many things to many different interested parties ­ ­ ­ ­ ­ ­ ­ ­ end-user customer project manager system engineer developer architect maintainer other developers  Multidimensional reality  Multiple stakeholders multiple views, multiple blueprints Architectural view  An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective Architecturally significant elements  Not all design is architecture  Main “business” classes  Important mechanisms  Processors and processes  Layers and subsystems  Architectural views = slices through models Characteristics of a Good Architecture  Resilient  Simple  Approachable  Clear separation of concerns  Balanced distribution of responsibilities  Balances economic and technology constraints Representing System Architecture Logical View End-user Functionality Process View System integrators Performance Scalability Throughput Conceptual Implementation View Programmers Software management Use Case View Deployment View System engineering System topology Delivery, installation Communication Physical Relation Between Views Logical view Component view  Process view  Deployment view How many views?  Simplified models to fit the context  Not all systems require all views: ­ Single processor: drop deployment view ­ Single process: drop process view ­ Very Small program: drop implementation view  Adding views: ­ Data view, security view The Value of the UML  Is an open standard  Supports the entire software development lifecycle  Supports diverse applications areas  Is based on experience and needs of the user community  Supported by many tools Creating the UML UML 1.3 OMG Acceptance, Nov 1997 UML 1.1 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 public feedback UML partners UML 0.9 Web - June ´96 OOPSLA ´95 UML 1.0 Unified Method 0.8 Other methods Booch method OMT OOSE UML Partners  Rational Software Corporation  Hewlett-Packard  I-Logix  IBM  ICON Computing  Intellicorp  MCI Systemhouse  Microsoft  ObjecTime  Oracle  Platinum Technology  Taskon  Texas Instruments/Sterling Software  Unisys Contributions to the UML Harel Meyer Before and after conditions Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification Overview of the UML  The UML is a language for ­ ­ ­ ­ visualizing specifying constructing documenting the artifacts of a software-intensive system Overview of the UML  Modeling elements  Relationships  Extensibility Mechanisms  Diagrams Modeling Elements  Structural elements ­ class, interface, collaboration, use case, active class, component, node  Behavioral elements ­ interaction, state machine  Grouping elements ­ package, subsystem  Other elements ­ note Relationships  Dependency  Association  Generalization  Realization Extensibility Mechanisms  Stereotype  Tagged value  Constraint Models, Views, and Diagrams model is a complete escription of a system om a particular erspective Use Case Use Case Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Scenario Scenario Diagrams Statechart Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams Models State State Diagrams Object Diagrams Diagrams State State Diagrams Component Diagrams Diagrams Component Component Diagrams Deployment Diagrams Activity Diagrams Diagrams Diagrams  A diagram is a view into a model ­ Presented from the aspect of a particular stakeholder ­ Provides a partial representation of the system ­ Is semantically consistent with other views  In the UML, there are nine standard diagrams ­ Static views: use case, class, object, component, deployment ­ Dynamic views: sequence, collaboration, statechart, activity Use Case Diagram  Captures system functionality as seen by users Use Case Diagram  Captures system functionality as seen by users  Built in early stages of development  Purpose ­ ­ ­ ­ Specify the context of a system Capture the requirements of a system Validate a system’s architecture Drive implementation and generate test cases  Developed by analysts and domain experts Class Diagram  Captures the vocabulary of a system Class Diagram  Captures the vocabulary of a system  Built and refined throughout development  Purpose ­ Name and model concepts in the system ­ Specify collaborations ­ Specify logical database schemas  Developed by analysts, designers, and implementers Object Diagram  Captures instances and links Object Diagram  Shows instances and links  Built during analysis and design  Purpose ­ Illustrate data/object structures ­ Specify snapshots  Developed by analysts, designers, and implementers Component Diagram  Captures the physical structure of the implementation Component Diagram  Captures the physical structure of the implementation  Built as part of architectural specification  Purpose ­ Organize source code ­ Construct an executable release ­ Specify a physical database  Developed by architects and programmers Deployment Diagram  Captures the topology of a system’s hardware Deployment Diagram  Captures the topology of a system’s hardware  Built as part of architectural specification  Purpose ­ Specify the distribution of components ­ Identify performance bottlenecks  Developed by architects, networking engineers, and system engineers Sequence Diagram  Captures dynamic behavior (time-oriented) Sequence Diagram  Captures dynamic behavior (time-oriented)  Purpose ­ Model flow of control ­ Illustrate typical scenarios Collaboration Diagram  Captures dynamic behavior (message-oriented) Collaboration Diagram  Captures dynamic behavior (message-oriented)  Purpose ­ Model flow of control ­ Illustrate coordination of object structure and control Statechart Diagram  Captures dynamic behavior (event-oriented) Statechart Diagram  Captures dynamic behavior (event-oriented)  Purpose ­ Model object lifecycle ­ Model reactive objects (user interfaces, devices, etc.) Activity Diagram  Captures dynamic behavior (activity-oriented) Activity Diagram  Captures dynamic behavior (activity-oriented)  Purpose ­ Model business workflows ­ Model operations Architecture and the UML Design View Classes, interfaces, collaborations Implementation View Use cases Process View Components Use Case View Deployment View Active classes Nodes Organization Dynamics Package, subsystem Interaction State machine Software engineering process A set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one.  Architectural process ­ Sequence of activities that lead to the production of architectural artifacts:  A software architecture description  An architectural prototype Rational Unified Process  Iterative  Architecture-centric  Use-case driven  Risk confronting Focus over time Discovery Focus Invention Implementation Key concepts  Phase, Iterations When does architecture happen?  Process Workflows What does happen? ­ Activity, steps  Artifacts ­ models What is produced? ­ reports, documents  Worker: Architect Who does it? Lifecycle Phases Inception Elaboration Construction Transition time  Inception Define the scope of the project and develop business case  Elaboration Plan project, specify features, and baseline the architecture  Construction  Transition Build the product Transition the product to its users Major Milestones Inception Elaboration Construction Transition time Vision Baseline Architecture Initial Capability Product Release Phases and Iterations Inception Prelim ... Iteration Elaboration Arch Iteration ... Construction Dev Dev Iteration Iteration Transition ... Trans Iteration ... Release Release Release Release Release Release Release Release An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable release Architecture-Centric  Models are vehicles for visualizing, specifying, constructing, and documenting architecture  The Unified Process prescribes the successive refinement of an executable architecture Inception Elaboration Construction time Architecture Transition Unified Process structure Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iterations Iter. #m Iter. #m+1 Architecture and Iterations Use case Model Design Model Implementati Deployment on Model Model Content Test Model Architectural design  Identify, select, and validate “architecturally significant” elements  Not everything is architecture ­ ­ ­ ­ ­ Main “business” classes Important mechanisms Processors and processes Layers and subsystems Interfaces  Produce a Software Architecture Documen Architectural design workflow  Select scenarios: criticality and risk  Identify main classes and their responsibility Use case view  Distribute behavior on classes  Structure in subsystems, layers, define interfaces  Define distribution and concurrency Logical view  Implement architectural prototype  Derive tests from use cases  Evaluate architecture Iterate Implementation view Deployment view Process view Sources of architecture Method Method Theft Intuition Classical system Theft Intuition Unprecedented system Patterns  A pattern is a solution to a problem in a context  A pattern codifies specific knowledge collected from experience in a domain  All well-structured systems are full of patterns ­ Idioms ­ Design patterns ­ Architectural patterns daVinci Mechanisms  ScrewsBrakes  Keys  Rivets Valves  Bearings Springs  Pins, axles, shafts Cranks and rods  Couplings  Ropes, belts, and chains Pulleys  Friction wheels Engaging gears  Toothed wheels  Flywheels  Levers and connecting rods  Click wheels and gears  Ratchets Pipes Cams Design patterns  Creational patterns ­ Abstract factory ­ Prototype  Structural patterns ­ Adapter ­ Bridge ­ Proxy  Behavioral patterns ­ Chain of responsibility ­ Mediator ­ Visitor  Mechanisms are the soul of an architecture Design Patterns Gamma et al Modeling a design pattern Modeling a design pattern (cont.) Modeling a design pattern (cont.) Architectural patterns  Distributed  Layered  Event-driven  MVC  Frame-based  IR-centric  Batch  Subsumption  Pipes and filters  Disposable  Repository-centric  Blackboard  Interpreter  Rule-based Software Architecture Shaw and Garlan Buschmann et al A System of Patterns Buschman et al Booch Real-Life Object-oriented Systems Soren Lauesen Complex business system Cust omer name : St ring Address : St ring Sales product : Product Order dat e : Dat e GUIl ayer save() ServiceAgent Observer purchase(cust omer, product , i t ems) updat e() Middle l ayer Cust omer name : St ring Address : St ring save() get Name() updat eName() Product name : St ring price : Currency Order Line it ems : Product get Name() updat eName() Cust omer get Name() updat eName() Order Line * Product * SQL Dat abase Logical application architecture Graphical User Interface Relational Database Graphical User Interface Business Object Model Relational Database Graphical User Interface Business Object Model Relational Database Physical application architecture Thinner client, thicker server Client B Client A Application Application Client C WWW Browser DCOM CORBA Beans ADO/R Business Object Services Business Object Engine Business COM Beans ETS MTS Object Server Business Object Relational Database Server(s) Web HTML Serve CGI r ASP Java Services Business Object Services Business Object Engine Business Object Engine The Second Wave Paul Dreyfus, Netscape Complex Internet system Dynamic HTML, JavaScript, Java plug-ins, source code enhancements Client Server Java, C, C++, JavaScript, CGI Application Server Fulfillment System Financial System Inventory System Java, C, C++, JavaBeans, CORBA, DCOM RDBMS Server Native languages Who are the architects?  Experience ­ software development ­ domain  Pro-active, goal oriented  Leadership, authority  Architecture team ­ balance Architect  Not just a top level designer  Need to ensure feasibility  Not the project manager  But “joined at the hip”  Not a technology expert  Purpose of the system, “fit”,  Not a lone scientist  Communicator Software architecture team charter  Defining the architecture of the software  Maintaining the architectural integrity of the software  Assessing technical risks related to the software design  Proposing the order and contents of the successive iterations  Consulting services  Assisting marketing for future product definition  Facilitating communications between project teams Architecture is making decisions The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark. Futures  ADL: Architecture Description Languages ­ UML, UniCon, LILEAnna, P++, LEAP, Wright, µRapid  Standardization of concepts ­ IEEE Working Group on Architecture ­ INCOSE Working Group on System Architecture  Systematic capture of architectural patterns References (Architecture)  Len Bass, Paul Clements & Rick Kazman, Software Architecture in Practice, Addison-Wesley, 1998.  Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl, Pattern-Oriented Software Architecture - A System of Patterns , Wiley and Sons, 1996.  Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software Architecture, Addison-Wesley 1999.  Eric Gamma, John Vlissides, Richard Helm, Ralph Johnson, Design Patterns, Addison-Wesley 1995.  Philippe Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, 12 (6), November 1995, IEEE. ­ http://www.rational.com/support/techpapers/ieee/  Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Englewood Cliffs NJ, Prentice-Hall, 1991. References (Architecture)  Eberhardt Rechtin & Mark Maier, The Art of System Architecting, CRC Press, 1997.  Recommended Practice for Architectural Description , Draft 2.0 of IEEE P1471, May 1998 ­ http://www.pithecanthropus.com/~awg/  Mary Shaw, and David Garlan, Software Architecture—Perspectives on an Emerging Discipline, Upper Saddle River, NJ, Prentice-Hall, 1996.  Bernard I. Witt, F. Terry Baker, and Everett W. Merritt, Software Architecture and Design—Principles, Models, and Methods, New York NY, Van Nostrand Reinhold, 1995.  The World-wide Institute of Software Architects ­ http://www.wwisa.org References (UML)  Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. References (Process)  Barry Boehm, “A spiral model of software development and enhancement,” IEEE Computer, May 1998.  Barry Boehm, “Anchoring the software process,” IEEE Software, July 1996.  Grady Booch, Object Solutions, Addison-Wesley, 1995.  Philippe Kruchten, “A Rational Development Process,” CrossTalk, July 1996. ­ http://www.rational.com/support/techpapers/devprcs/  Philippe Kruchten, The Rational Unified Process - An Introduction, AddisonWesley, 1999.  Rational Unified Process 5.0, Rational, Cupertino, CA, 1998  Walker Royce, Software Project Management: a Unified Framework, AddisonWesley, 1998  The Software Program Manager’s Network ­ http://www.spmn.com