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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. 27 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Conceptual and analysis viewpoint ViewpointUML diagramDescription Analysis focusedClass Describe system entities in response to a scenario. Often refer to as a view of participating classes or VOPC Analysis interactioninteraction Interaction diagram between objects for analysis Analysis overallClass Combination of all classes from all focused analysis viewpoints ContextUse case Show the external system actors and the system under design

28. 28 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Logical design viewpoints ViewpointUML diagramDescription Component Component communications Component interactionInteraction Interactions among components Component stateState/activity State transition/activity diagram for a component or for a set of components Layered subsystemPackages Layering and subsystem design Logical dataClassesCritical data views used for integration Subsystem interface dependency Class Subsystem dependencies and interfaces

29. 29 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Environment/physical viewpoint ViewpointUML diagramDescription Deployment Mapping of software to hardware for distributed systems Physical dataDeployment Physical view of a particular database ProcessDeployment Show the processes of a particular system instance Process stateState Show the dynamic states of a process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

52. 52 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Relation to other key roles (con)  System engineering leads Responsibilities  Responsible for delivering the system requirements 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

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

54. 54 آزمايشگاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Skills and background for the architect  Extensive software design and development  Technical leadership  Team facilitation skills  Communication skills  Technical skills  Knowledge of component communication mechanisms  Knowledge of domain  Abstraction skills

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