معماری سيستم های با مقياس بزرگ

صفحه 1:
معمارى سيستمهاى با مقياس بزرك آزمايشكاه سيستمهاى هوشمند 0 52 000 esters} a 

صفحه 2:
مشخصات سر رسای ۱۳۵ ° كاركرد بيجيده و كسترده. ‎J‏ انتظارات سطح بالا در مورد نیازمندیهای غیر کارکردی. 2 نیاز به اطلاعات گسترده. ‏الت لكك ‎201 Cem Sc ele koe wae ea KCRG ۳۳ ‎ ‏أزمايشكاء سيستم هاى هو ‎ne eet trey‏ ‎5 

صفحه 3:
لزوم داشتن يك 1.5 ° براى يكيارجه سازى سيستمهاى مختلف به منظورنيل به: ‎oe hod‏ ا ‎FES pea eee ea a Coca nae [eae‏ ae ‏فروش یکباره ->رضایت مشتری‎ ٩ green field)yo> cle pines [See > «lp © ‎٩‏ برای رسیدن به نیازهای بازار و کسب وکار ‏© براى رسيدن به اهداف استراتؤيك سازمانى ‏© محافظت از سرمايه ‏أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 4:
نمونه هايي از سیستمهای 1.5 0 ‎٩‏ سیستمهای بازار بورس و سهام ‎٩‏ سیستمهای انبارداری 01011116 و توزیع شده. © سيستمهاى خدماتى 01211126 الت ‎ee er ‎Pee) scone) ‏أزمايشكاء سيستم هاى هو ‎ne eet trey‏ ‎5 

صفحه 5:
LSS 00 eons ‎٩‏ کیفیت > نیازمندیهای غیر کارکردی و دیگر محدودژت ها مانند محدوديت هاى تكنولزيكى ‎1.55 ‏زمانبنسی > زمان مورد نیاز برای تکمیل‎ ٩ 0 ‏هزينه > سرمايه؛ فراساختار و هزينه منابع انسانى. ‏أزمايشكاء سيستم هاى هو ‎ne eet trey‏ ‎5 

صفحه 6:
متغییرهای موجود در ‎LSS‏ 9 اط 5 

صفحه 7:
LSS ۳ ‏ا‎ © تقسيم وظايف در توسعه 55.](زمينه هاى مورد توجه) 0 افراد مختلف ‎٩‏ مسولیت های متفاوت 0 تخصصهای مختلف ا ا 15 ۳ 0 هر روش دید گاههای متفاوتی در مواجهه با مساله دارد. ‎cnt ne.‏ م 0 دیدگاه مدیریت پروژه 0 دیدگاه کسب و کار. أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 8:
Software Development For Large-Scale Systems 52 000 esters} 3 

صفحه 9:
al Software Architecture for LSS © Agenda 9 ‏هط‎ ‎© Why an LSS © Views © Architecture description أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 10:
al What is software architecture ۱ (generalized model) of systems © Software Architecture is composed of sub-systems or components (possibly nested) © Components have properties ,e.g attributes and ‏واف انا‎ © The sub-Systems or componenets have ‏حصمطا صهعسماعط متطعصم‌ناهلط‎ ‏ا‎ ‎* E.g located within the same directory, layer or package * Runtime, e.g coupling (10 types) أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 11:
2 Introduction Large-Scale Software Architecture 

صفحه 12:
What is Software oy Architecture ae © There of dozens of books talk about software architecture © The definitions used in this book are closely aligned IEEE 1417 

صفحه 13:
Key Terms (1) ° System * Is a set of components that accomplishes a specific function or set of functions. © Architecture » 15 the fundamental organization of a system embodied in its components, their relationships to each, and to the environment, and the principles guiding its design and evolution. أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 14:
Key Terms (2) © Architectural Description » A set of products that document the architecture © Architectural View ° A representation of a particular system or part of a system from a particular perspective © Architectural Viewpoint ° A template that describes how to creat and use an architectural view © Includes a name, stakeholders, concerns addressed by the viewpoint and the modeling and analytic conventions. أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 15:
Software © Architecture ° Refers to analysis, design, documentation, review, approval, and other related activities concerned with the definition and management of the software architecture © Architectural views © Provide representations of the architecture ° Used to guide construction, manage, explore, train personnel, test and perform other engineering tasks related to creation and maintenance of software system أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 16:
Uses of views Capturing the design decisions both early on and as enhancements are made Capturing information about the runtime enviroment for software Providing constrains on the lower-level design and implementation Providing input to the structure of the development organization Designing the system to meet the software reliability, availability, maintainability, and performance requirements Facilitating communication among the project teams Communicating software capabilities and constraints to varios developers, testers, and others أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 17:
Other way for thinking 3 ‏هر‎ questions answered by views of the architecture © What are subsystems or components of the software? What are responsibilities of the components? ° What are the interfaces provided, consumed by these components? * What subsystems or components are impact by a change to the software? ° How much retesting is required if we change this component? * When components are involved in installing this change? ° How are part of system to be physically distributed? © How will a change impact the performance of the system © What development teams are impacted by a change to this interface? © How much effort is involves in the development of this functionality? أزمايشكاء سيستم هاى هون ‎ne eet trey‏ 

صفحه 18:
al What software architecture is 3 not ۲ © Hardware, network, physical plant architecture © Hardware model number, hardware configuration, routers, LAN © Should not duplicate information on other sources © Appropriate level of detail © Low level implementation details should not included in the software architecture أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 19:
al Attributes of software architecture(1/2) Cultural adaptability Security Data integrity Maintainability characteristics ۶ ‏اناد ةا‎ © Changeability © Fragility © Rigidity عمنامم‌ناودط ه ‎Understandability‏ © ‎Debugging support‏ * ۱ نامع ۰ 0 ه 6 @ أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 20:
al Attributes of software architecture(2/2) © Operational system aspects © Availability © Manageability ° Upgradeability © Reliability © Recoverability foe ‏ادف‎ ‏ةا ا‎ © Scalability © Capacity/throughput © safety أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 21:
Points © Members of the architecture team need to constantly evaluate the software architecture to determine if it meets the desire goal with respect to these characteristics © Architects must constantly prioritize and manage the trade-off between these attributes for a given projects أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 22:
Architecting simply recognized the need to focus on the bigger picture of the software design and to provide guidance to the development team designers Why architect 0 © It is a place to capture early design decitions © Provide constraints on the lower level design and implementation Provide the organizational structure for the development team This goal is that a well defined architecture will produce a system that will be easier to design, develop and maintain أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 23:
al Uses of software architecture © Training for the new team members © Making modification © Testers need to understand the system © Ensuring architectural attributes © Verification of requirements © Project management © Operating systems أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 24:
الك © Viewpoint are built by applying the various UML diagram types to specific architecture development tasks © Each viewpoint has specific modeling goals and stakeholders أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ al Architectural viewpoint 

صفحه 25:
A Ea ۱1 stot ad © Conceptual and analysis viewpoint © Logical design viewpoint © Environment/physical viewpoint 

صفحه 26:
۱2۱ Modeling Language 

صفحه 27:
ص«منا رنه عع 1۱ 19 oles Wstetssstets ) sae mo” 0 102 Peter metres ‏ماع وزطه صعع تفط‎ 10: ‏نومه‎ 1ل 6ه صمتامصتطصرو© ‎classes from all‏ ‎Renta‏ 90عن06] كأسلهم مزا [0 system actors and the system under design UML diagram (OCT interaction عععت Use case أزمايشكاء سيستم هاى هو ‎D‏ 00000 Conceptual and analysis viewpoint Viewpoint Analysis focused Analysis interaction Analysis overall 9/8 

صفحه 28:
Description اصع هه متم ‎communications‏ 17 components State transition/activity Cite Rom sett Conta 9 ‏كاطع ص یات یل‎ 1 design eect mC ‏دوهع وهام 10 لمكن‎ [0 oer crtets Paves Cast UML diagram ‏مع صم ممه‎ ناعم م1 ‎State/activity‏ ‎reer‏ ‎Classes‏ 0155 Ree eer a ne eet trey 5 Logical design viewpoints Viewpoint ‏تاصعصهورهو6‎ ‎9 9 een eon ۱ [۱ dependency 

صفحه 29:
دسمتامترهءوع1 Veranda) reese 0۲ Glee need cence at ‏عكقطهغه0 عه انتمهم‎ 000 sees 0000 system instance Stanek itt ‏ععمءمتم و که عماهاه‎ Environment/physical UML diagram Deployment اتا دنال كلها ذال كاه State أزمايشكاء سيستم viewpoint Viewpoint ‏مع حزم 1رع1‎ Physical data Process Process state 0 

صفحه 30:
® Roles of Software Architect 

صفحه 31:
ial Outline © Roles of software architect and relation with other roles © Skills required for software architect © Key approaches to lead software architecture team © Traps and pitfalls associate with software architect أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 32:
al Importance of software architect © Lack of goof software architect is a part of the lack of good leadership in projects © Software architect defines a large part of shared vision of software © The idea of the development team about what the final product will be, the effect the software will have and the goals of organization ° The final architecture will balance the conflicting interest of the various stakeholders peer eer chttp://ce.aut.ac.ir/islab) si 

صفحه 33:
al Activities for defining shared FAY vision CPLR coy eMet ott © Risk management Cp cmicenttantntt arta © Interface design © Technology roadmap management عمطعهمتحردرح حمتاهتامهه امس که ممتامتصما0ط 9 © Definition of an architecture that meets the system Fete iinet MCC VRO Ma NeE TACs TeCo Wa eel man Ce(eaenl Rotel دوتدعل معطا ا ومباءو6تطعصة عط سوع؟ وصنم‌چرهه فضا و ‎CMonst‏ ‎aston‏ سعصو امس قصة © Communication of software architecture to technical and 00 تا ۷6 أزمايشكاء سيستم هاى هون ‎ne eet trey‏ 

صفحه 34:
al Other software architecture oy approaches oo 0 4+1 5 © RM-ODP viewpoints © Bass architectural structures © Hofmeister software architecture ‏يتان‎ أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 35:
RM-ODP viewpoints © Referenced Model for Open Distributed Processing (RM-ODP) © An ISO standard © Provides a framework for the development of standards related distributed processing © Defines the important properties of distributed systems; openness, integration, flexibility, modularity, federation, manageability, provisioning of quality services, security, and ۱99:3۱۳( ‏تاره‎ أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 36:
RM-ODP viewpoints Enterprise viewpoint Information viewpoint Computational viewpoint Engineering viewpoint أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 5 

صفحه 37:
al Bass architectural structures © Does not use UML © Structures ° Module structure © Conceptual © Process © Physical تا ب عللون * bee Bers C0) Uy * Control flow وتامدتاه عععان ۶ أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 38:
Hofmeister views Conceptual view Module view Execution view 626 ۸ و هو هو هو أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 39:
Stages of design © High level design ‏ا‎ High level data structure ° Architecture © Low level design-code design ° Algorithms © Low level data structures © Executable design ® Very lower level of detail rae ne eet trey 

صفحه 40:
Types of design © Data design © Architectural design © External interface design © Algorithmic design 

صفحه 41:
Design techniques © Require some sort of decomposition ® Modular decomposition ® Data oriented decomposition ° Event oriented decomposition ® Outside in design ® Object oriented design أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 42:
Architectural view -2 © Which structure are used, and why? © Common view include ° Module © Process ° Uses ® Class ® Data flow ® Class ® physical أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 43:
al Typical roles and responsibilities Requirements Technical risk Analysis of problem domain Design of overall software Reviewer and approver of deliverables Mentoring of design and developers Integration and test support Implementation support اننا تتا Laison to project management e©o000000000 أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 44:
Relation to other key roles © Project management © Responsibilities © Program planning, subcontract management, ‏6عحعلم ,حمتاهستاده مسعسگمی رتصمصه‌وحصهه منامرونه‎ management, operation management ° Relation to software architect ‎yeelCod‏ ل ا ا وحصههه ‎٩ acct braee‏ 20 2 ‏5 أزمايشكاء سيستم هاى هو ‎ne eet trey 2‏ 

صفحه 45:
Relation to other key roles (con) © Development team managers * Responsibilities © Managing individual development teams © Relation to software architect © These managers should clearly understand the interface they provide and consume to other development teams and external entities © High level aspects (COTS tools for interfaces, complexity of development, modification of each interface) أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 46:
Relation to other key roles % (con) © System architect/ chief engineer © Responsibilities © Overall system design and delivery © Technical leadership pf the systems engineering, software development, hardware design, network design, even test organizations امماتطمته عتمسمو متا حمتاحامظ ۶ © Interfaces between development teams, external interfaces, requirements related issues © Identify and resolve significant technical issues أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 47:
Relation to other key roles (con) © Chief software engineering ° Responsibilities © Ensures the process is followed thoroughout the development life cycle. © Relation to software architect ° To make sure the delivered software meets the requirements and the interface and port definitions match by those defined by software architect team. أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 48:
Relation to other key roles (con) © Hardware architect ° Responsibilities © Selecting and configuring of hardware © Relation to software architect © Software architect provides low level requirements for selecting hardware © Hardware architect informs hardware restriction to provide requirements ° Software architect makes sure the software architecture id defined within the constraints of the hardware. أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey 9‏ 

صفحه 49:
Relation to other key roles (con) © Network architect ° Responsibilities © Defining the LAN and WAN design and configuration © Relation to software architect © Communicate for defining network ‏عاصمصهن۲ و۳‎ ° Defines constraints implies by network back to software architect أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 50:
Relation to other key roles 2 (con) © Technical leads of each release ° Responsibilities © Deliver each major release © Relation to software architect ° Communicate for technical issues ° Software architect deliver a set of architecture views to the technical lead © Communication and interfaces with previous 26 أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 51:
Relation to other key roles (con) © Data architect ° Responsibilities ° Definition, development and documentation of the data architect. © Relation to software architect ° A member of architecture team. © Software architect have final approval of the data architecture. أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 52:
Relation to other key roles (con) © System engineering leads ° Responsibilities © Responsible for delivering the system ‏ا ةا‎ © Relation to software architect © Software architect review these requirements to make sure they can be delivered © Given the project constraints ° Provide feedback to the system engineer أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 53:
Relation to other key roles 2 (con) © Software system engineering lead ° Responsibilities © Translates and maps the requirements from higher level system group into lower level requirements ° Relation to software architect © Software architecture will often be provided th the organization ° SSE team will evolve the software architecture in translating requirements أزمايشكاء سيستم هاى هو ‎ne eet trey‏ 

صفحه 54:
al Skills and background for the 32 architect 1 © Extensive software design and 0 ‏تأجع حدم م1ع617‎ © Technical leadership © Team facilitation skills © Communication skills © Technical skills © Knowledge of component communication mechanisms © Knowledge of domain © Abstraction skills أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏ 

صفحه 55:
Traps and pitfalls © Clear definition of leadership © Reporting structure for the software architect © Geographical location of software architect and technical leads © Architecture team size and composition © Software architect lifecycle participation أزمايشكاء سيستم هاى هوشمند. ‎ne eet trey‏