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

1. معماری سيستمهای با مقياس بزرگ آزمايشگاه سيستمهای هوشمند پاييز 93 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

2. مشخصات سيستمهایLS • کارکرد پيچيده و گسترده. • انتظارات سطح بالا در مورد نيازمنديهای غير کارکردی. • نياز به اطلاعات گسترده. • توزيع شدگی پردازش کارايي و يا اطلاعات. • يکپارچگی سخت افزارها و نرم افزارها و سيستمهای ارتباطی مختلف. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

3. لزوم داشتن يک LS • برای يکپارچه سازی سيستمهای مختلف به منظورنيل به: • اقتصادی ساختن سيستم از نظر توسعه و پشتيبانی از طريق استفاده مجدد.. • فروش يکباره ←رضايت مشتری • برای حل مشکل سيستم های جديد(green field) • برای رسيدن به نيازهای بازار و کسب وکار • برای رسيدن به اهداف استراتژيک سازمانی • محافظت از سرمايه آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

4. نمونه هايي از سيستمهایLS • سيستم رزرواسيون بليط • سيستمهای مالياتی • سيستمهای بانکی • سيستمهای بازار بورس و سهام • سيستمهای انبارداریonline و توزيع شده. • سيستمهای خدماتی online • سيستمهای جامع و يکپارچه سازمانی • سيستمهای کنترل و اندازه گيری از را دور بلادرنگ. • سيستمهای مخابراتی. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

5. متغييرهای موجود در LSS • محتوا← کارايي • کيفيت ← نيازمنديهای غير کارکردی و ديگر محدودژت ها مانند محدوديت های تکنولژيکی • زمانبندی ← زمان مورد نياز برای تکميل LSS • هزينه ← سرمايه، فراساختار و هزينه منابع انسانی. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

6. Quality Cost Content Schedule متغييرهای موجود در LSS آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

7. موارد مورد توجه در LSS • تقسيم وظايف در توسعه LSS(زمينه های مورد توجه) • افراد مختلف • مسوليت های متفاوت • تخصصهای مختلف • هر زمينه دارای مسائل مختلف و روشهايي جهت حل مشکلات می باشد. • هر روش ديدگاههای متفاوتی در مواجهه با مساله دارد. • ديدگاه تيم طراحی • ديدگاه مديريت پروژه • ديدگاه کسب و کار. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

8. Software Development For Large-Scale Systems آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

9. Software Architecture for LSS • Agenda • What • Why an LSS • Views • Architecture description آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

10. What is software architecture • Software architecture is an abstraction (generalized model) of systems • Software Architecture is composed of sub-systems or components (possibly nested) • Components have properties ,e.g attributes and behavior • The sub-Systems or componenets have relationship between them • Non-runtime • E.g located within the same directory, layer or package • Runtime, e.g coupling (10 types) آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

11. Introduction Large-Scale Software Architecture آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

12. What is Software Architecture • There of dozens of books talk about software architecture • The definitions used in this book are closely aligned IEEE 1417 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

13. Key Terms (1) • System • Is a set of components that accomplishes a specific function or set of functions. • Architecture • Is 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. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

17. Other way for thinking • Typical 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? آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

18. What software architecture is 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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

19. Attributes of software architecture(1/2) • Cultural adaptability • Security • Data integrity • Maintainability characteristics • Portability • Changeability • Fragility • Rigidity • Duplication • Understandability • Debugging support • Testability • usability آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

20. Attributes of software architecture(2/2) • Operational system aspects • Availability • Manageability • Upgradeability • Reliability • Recoverability • Performance • Response • Scalability • Capacity/throughput • safety آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

22. Why architect? • Architecting simply recognized the need to focus on the bigger picture of the software design and to provide guidance to the development team designers • 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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

23. 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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

24. Architectural viewpoint summary • Viewpoint are built by applying the various UML diagram types to specific architecture development tasks • Each viewpoint has specific modeling goals and stakeholders آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

25. IEEE 1471 viewpoints • Conceptual and analysis viewpoint • Logical design viewpoint • Environment/physical viewpoint آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

26. UML: Unified Modeling Language آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

27. Conceptual and analysis viewpoint آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

28. Logical design viewpoints آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

29. Environment/physical viewpoint آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

30. Roles of Software Architect آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

31. 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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

32. 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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

33. Activities for defining shared vision • Analysis the problem domain • Risk management • Requirement management • Interface design • Technology roadmap management • Determination of implementation approaches • Definition of an architecture that meets the system requirements, goal of organization, project budget and schedule • Oversight of the mapping from the architecture to the design and implementation • Communication of software architecture to technical and non-technical audience • Maintenance of software architecture during system life cycle آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

34. Other software architecture approaches • 4+1 views • RM-ODP viewpoints • Bass architectural structures • Hofmeister software architecture views آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 transparency آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

36. RM-ODP viewpoints • Enterprise viewpoint • Information viewpoint • Computational viewpoint • Engineering viewpoint آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

37. Bass architectural structures • Does not use UML • Structures • Module structure • Conceptual • Process • Physical • Uses • Calls • Data flows • Control flow • Class structure آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

38. Hofmeister views • Conceptual view • Module view • Execution view • Code view آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

40. Types of design • Data design • Architectural design • External interface design • Algorithmic design آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

41. Design techniques • Require some sort of decomposition • Modular decomposition • Data oriented decomposition • Event oriented decomposition • Outside in design • Object oriented design آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

42. Architectural view -2 • Which structure are used, and why? • Common view include • Module • Process • Uses • Class • Data flow • Class • physical آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

43. 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 • Team lead • Laison to project management آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

44. Relation to other key roles • Project management • Responsibilities • Program planning, subcontract management, supplier management, software estimation, release management, operation management • Relation to software architect • Software architect works with project management in definition of release contents and prioritization of features included or omitted from a release آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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) آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 • Relation to software architect • Interfaces between development teams, external interfaces, requirements related issues • Identify and resolve significant technical issues آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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. آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

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 requirements • Defines constraints implies by network back to software architect آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)

50. Relation to other key roles (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 release آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab)