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

معماری سيستمهای با مقياس بزرگ
آزمايشگاه سيستمهای هوشمند زمستان 1385 آزمايشگاه سيستم های هوشمند (

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

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

نمونه هايي از سيستمهایLS
سيستم رزرواسيون بليط سيستمهای مالياتی سيستمهای بانکی سيستمهای بازار بورس و سهام سيستمهای انبارداریonline و توزيع شده. سيستمهای خدماتی online سيستمهای جامع و يکپارچه سازمانی سيستمهای کنترل و اندازه گيری از را دور بلادرنگ. سيستمهای مخابراتی. آزمايشگاه سيستم های هوشمند (

متغييرهای موجود در LSS محتوا← کارايي کيفيت ← نيازمنديهای غير کارکردی و ديگر محدودژت ها مانند محدوديت های تکنولژيکی زمانبندی ← زمان مورد نياز برای تکميل LSS هزينه ← سرمايه، فراساختار و هزينه منابع انسانی. آزمايشگاه سيستم های هوشمند (

متغييرهای موجود در LSS Content Cost Schedule Quality آزمايشگاه سيستم های هوشمند (

موارد مورد توجه در LSS تقسيم وظايف در توسعه LSS(زمينه های مورد توجه) افراد مختلف مسوليت های متفاوت تخصصهای مختلف هر زمينه دارای مسائل مختلف و روشهايي جهت حل مشکلات می باشد. هر روش ديدگاههای متفاوتی در مواجهه با مساله دارد. ديدگاه تيم طراحی ديدگاه مديريت پروژه ديدگاه کسب و کار. آزمايشگاه سيستم های هوشمند (

Software Development For Large-Scale Systems
آزمايشگاه سيستم های هوشمند (

Software Architecture for LSS
Agenda What Why an LSS Views Architecture description آزمايشگاه سيستم های هوشمند (

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) آزمايشگاه سيستم های هوشمند (

Introduction Large-Scale Software Architecture

What is Software Architecture
There of dozens of books talk about software architecture The definitions used in this book are closely aligned IEEE 1417 آزمايشگاه سيستم های هوشمند (

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. آزمايشگاه سيستم های هوشمند (

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. آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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? آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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

Attributes of software architecture(2/2)
Operational system aspects Availability Manageability Upgradeability Reliability Recoverability Performance Response Scalability Capacity/throughput safety آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

IEEE 1471 viewpoints Conceptual and analysis viewpoint Logical design viewpoint Environment/physical viewpoint آزمايشگاه سيستم های هوشمند (

UML: Unified Modeling Language

Conceptual and analysis viewpoint
UML diagram Description Analysis focused Class Describe system entities in response to a scenario. Often refer to as a view of participating classes or VOPC Analysis interaction interaction Interaction diagram between objects for analysis Analysis overall Combination of all classes from all focused analysis viewpoints Context Use case Show the external system actors and the system under design آزمايشگاه سيستم های هوشمند (

Logical design viewpoints
UML diagram Description Component Component communications Component interaction Interaction Interactions among components Component state State/activity State transition/activity diagram for a component or for a set of components Layered subsystem Packages Layering and subsystem design Logical data Classes Critical data views used for integration Subsystem interface dependency Class Subsystem dependencies and interfaces آزمايشگاه سيستم های هوشمند (

Environment/physical viewpoint
UML diagram Description Deployment Mapping of software to hardware for distributed systems Physical data Physical view of a particular database Process Show the processes of a particular system instance Process state State Show the dynamic states of a process آزمايشگاه سيستم های هوشمند (

Roles of Software Architect

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

Other software architecture approaches
4+1 views RM-ODP viewpoints Bass architectural structures Hofmeister software architecture views آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

RM-ODP viewpoints Enterprise viewpoint Information viewpoint Computational viewpoint Engineering viewpoint آزمايشگاه سيستم های هوشمند (

Bass architectural structures
Does not use UML Structures Module structure Conceptual Process Physical Uses Calls Data flows Control flow Class structure آزمايشگاه سيستم های هوشمند (

Hofmeister views Conceptual view Module view Execution view Code view آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

Types of design Data design Architectural design External interface design Algorithmic design آزمايشگاه سيستم های هوشمند (

Design techniques Require some sort of decomposition Modular decomposition Data oriented decomposition Event oriented decomposition Outside in design Object oriented design آزمايشگاه سيستم های هوشمند (

Architectural view -2 Which structure are used, and why? Common view include Module Process Uses Class Data flow physical آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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) آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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. آزمايشگاه سيستم های هوشمند (

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. آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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. آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

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 آزمايشگاه سيستم های هوشمند (

Frameworks And Patterns

بالا بردن قابليت استفاده مجدد (Reuse)
هدف اصلي مهندسي نرم افزار استفاده مجدد از طراحي و محصولات مرتبط است: چارچوب ها (Frameworks) الگوها (Patterns) آزمايشگاه سيستم های هوشمند (

Framework چيست؟ يک Domain specific skeleton شامل: Plug-ins points or hooks: براي افزودن و يا اتصال برنامه و اجزاي مختلف توسط طراح. آزمايشگاه سيستم های هوشمند (

تعريف framework از ديدگاه OO
براساس Gang-of-Four يک framework عبارت است از مجموعه اي از class هايي که با ترکيب و کار در کنار هم، يک طراحي با قابليت استفاده مجدد براي يک کلاس خاص از نرم افزار ايجاد مي کنند. (set of cooperating classes that make up a reusable design for a specific class of software.) مثال: طراحي يک کامپايلر آزمايشگاه سيستم های هوشمند (

مزاياي استفاده از frameworkها
استفاده از application framework هزينه تشخيص و تعيين ساختار و روابط متقابل (interrelationship) ميان اجزاي آن را کاهش مي دهد. Framework ها براي طراحي هاي موجود امکان گسترش پذيري (Extensibility) را مهيا مي کنند. آزمايشگاه سيستم های هوشمند (

دسته بندي (Classification) framework ها
زيرساختي (Infrastructure frameworks) با هدف ساده سازي فرايند توليد نرم افزار ميان افزاري (Middleware framework) با هدف يکپارچه سازي برنامه هاي کاربردي موجود. Enterprise application frameworks با هدف استفاده در کاربردهاي کسب و کار آزمايشگاه سيستم های هوشمند (

يک الگو (pattern) چيست؟
يک abstraction قابل تشخيص است که در موقعيت ها و برنامه هاي کاربردي مختلف تکرار شده و متناوبا استفاده مي شود. اين موقعيت مي تواند مربوط به ساختار (Structure) و يا رفتار (behavior) نرم افزار باشد. برنامه هاي کاربردي که از الگو هاي استفاده مي کنند: Architecture of building, towns, road works, dams etc Manufacturing: metal and plastic die casting and moulding Drawings Textiles آزمايشگاه سيستم های هوشمند (

تعريف الگوها يک طرح کلي (outline) از يک راه حل با قابليت استفاده مجدد براي يک مسئله کلي است. الگوي طراحي (design patterns): ايجاد templateهايي براي تسهيل و تسريع فرايند طراحي نرم افزار. OO: يک الگوي طراحي مجموعه اي از کلاس هايي است که با يکديگر تعامل (Interacting) دارند و با customize کردن آن مي توان يک طراحي مخصوص را ايجاد نمود. آزمايشگاه سيستم های هوشمند (

الگوهاي طراحي در مقايسه با Framework ها
هر دو ابزاري براي استفاده مجدد (reuse) در فرايند هاي توليد نرم افزار RAD هستند. الگوهاي طراحي در مقايسه با frameworkها کلي تر و انتزاعي تر (abstract) هستند. يک framework داراي معماري بزرگتري است و ممکن است در معماري خود از چندين الگوي طراحي استفاده کند. Framework يک پياده سازي واقعي (virtual realization) از يک يا گروهي از الگوهاي طراحي است. در واقع framework داراي ويژگي هاي مخصوص بيشتري نسبت به الگوهاي طراحي است. (it is more specific than a pattern) Framework امکان استفاده مجدد از طراحي هاي مشخص (Concrete)، الگوريتم ها و پياده سازي ها در يک زبان برنامه نويسي معين يا محيط OS را فراهم مي آورد. الگوها روي طراحي هاي abstract و ترکيب پيشنهادي از کلاس ها تمرکز مي کند که مي تواند توسط تيم طراحي پياده شود. يک framework از الگوهاي طراحي براي کامل کردن طراحي و پياده سازي تکه هاي پياده سازي نشده خود استفاده مي کند. آزمايشگاه سيستم های هوشمند (

رابطه الگوهاي طراحي با framework

چرا الگوهاي طراحي مفيد هستند؟ راه حلي براي مسايلي که در گذشته به بهترين راه حل شده اند، ارائه مي دهد. الگوها ساختارها و روش (methodology) هاي کلي ايجاد مي کنند. با استفاده مجدد از طراحي ها، امکان طراحي نکردن يک راه حل را از ابتدا مهيا مي سازد. به راحتي امکان سازگاري (adaptable) با نيازمندي هاي مخصوص نرم افزار هاي مختلف را دارد. الگوها خلاصه اي از راه حل هايي که در گذشته به خوبي کار کرده اند، ارائه مي دهد. آزمايشگاه سيستم های هوشمند (

الگوهاي طراحي Design Patterns

چگونه از الگوهاي طراحي استفاده کنيم؟
تعريف مسئله شناسايي و بررسي زمينه، سابقه (context) و راه حل هاي مسئله. تعيين بهترين راه حل از بين راه حل هاي موجود. آزمايشگاه سيستم های هوشمند (

سطوح الگوها الگوهاي معماري (Architectural patterns) الگوهاي طراحي (Design patterns) الگوهاي زبان (Language related idioms) آزمايشگاه سيستم های هوشمند (

الگوهاي معماري (Architectural patterns)
يک ترکيب ساختاري (Structural Arrangement) براي سيستم نرم افزاري شامل: زيرسيستم ها و مشخصات هر يک. قوانين ارتباطي بين زير سيستم ها آزمايشگاه سيستم های هوشمند (

الگوهاي طراحي (Design Patterns)
ارائه شده پس از سطح معماري استفاده در طراحي زيرسيستم ها، بسته ها (packages) و اجزا (components). ارائه راه حل هايي براي مشکلات معمول و تکراري. مديريت حافظه مديرت اشاره گرها. synchronization and mutual exclusion جلوگيري از بن بست (deadlock avoidance) نمايش با استفاده از UML Objects، Classes Inheritance، Aggregation Uses، extends، relationship آزمايشگاه سيستم های هوشمند (

Idioms پايين ترين سطح الگوها که مربوط به يک زبان برنامه نويسي خاص مي شود. يک Idiom چگونگي پياده سازي بخش خاصي را با استفاده از يک زبان توصيف مي کند. تخصيص حافظه (Memory allocation) De-allocation ناحيه هاي بحراني (Critical regions) ... آزمايشگاه سيستم های هوشمند (

انواع الگوها و مثال هايي از هريک
Behavioral Observer Player-role Immutable Read-Only Architectural Multi-Layer Client-Server Broker Pipe-and-Filter Model-View-Controller Creational Abstract-factory Singleton Abstraction-occurrence Structural General hierarchy Adaptor Façade Proxy Delegation آزمايشگاه سيستم های هوشمند (

Creational: Abstract-Factory
زمينه: واسطي (Interface) براي عملياتي که يک abstract product object ايجاد مي کند، مهيا مي سازد. راه حل: Concrete Factory subclass creates concrete objects آزمايشگاه سيستم های هوشمند (

Creational: Singleton
زمينه: اطمينان مي دهد که تنها يک موجوديت (Instance) از يک کلاس وجود دارد. راه حل: يک سازنده خصوصي (Private Constructor) وجود دارد که اطمينان مي دهد هيچ کلاس ديگري قادر به ايجاد مجدد (Recreate) يک موجوديت ديگر نيست. آزمايشگاه سيستم های هوشمند (

Creational: Abstraction-Occurrence
زمينه: پروازهاي هوايي با يک شماره ولي در روزهاي متفاوت و با خدمه و مسافران متفاوت. راه حل: ايجاد يک کلاس abstract شامل اطلاعات مشترک. ايجاد يک کلاس occurrence. (ايجاد رابطه 1:n) آزمايشگاه سيستم های هوشمند (

Structural: General-Hierarchy
زمينه: ارتباط بين کارمندان و مديران راه حل: ايجاد يک abstract node class که نشان دهنده ويژگي هاي مشترک است. ايجاد حداقل دو subclass، SuperiorNode و Non-SuperiorNode. آزمايشگاه سيستم های هوشمند (

Singleton Pattern وقتي مي خواهيد که از يک کلاس تنها يک instance در کل برنامه وجود داشته باشد. مثال: Print Spooler Accounting System براي يک شرکت. Library Loan policy Taxation Grades مزاياي استفاده از اين الگو: نيازي به استفاده از متغير هاي سراسري نيست. Single Access Point (Functional Cohesion) کنترل تعداد موجوديت هاي از يک کلاس. مجاز بودن ايجاد Sub-Class آزمايشگاه سيستم های هوشمند (

Proxy pattern کاربردهاي الگوي Proxy: Remote proxy: يک نماينده محلي (Local Representative) براي remote Object ها تهيه مي کند. Virtual proxy: creates expensive objects whenever needed Document Editor downloading text and image from a disk Protection proxy: براي object هاي مهم (precious) حفاظت (protection) و کنترل دسترسي (access control) ايجاد مي کند. Database Tables Implementing smart pointer: جايگزيني براي conventional pointer است که عمليات اضافي را مي تواند انجام دهد مانند: شمارش تعداد reference ها به يک object واقعي. اين object مادامي که تعداد reference ها برابر صفر نشده باشد نمي تواند delete شود. کنترل lock شدن object براي update شدن.(Checking that the object is locked prior to update) آزمايشگاه سيستم های هوشمند (

Proxy Pattern Diagram آزمايشگاه سيستم های هوشمند (

پنج لايه الگوهاي معماري (Architectural Pattern)...
1. Application Layer Package: مديريت کاربران و profile آنها. ايجاد فضاي کاري (Work Space) براي کاربران. کنترل شبکه OS Functions HW Functions توابع مديريتي (Administrative Functions) هشدارها و پيام ها. 2. User Interface Package: Workspace elements: Scroll bar، windows، progress bar و … نمايش فضاي کاري (Workspace Presentation) نمايش و پنجره ها. Logon/Logoff تعامل با کاربر آزمايشگاه سيستم های هوشمند (

...پنج لايه الگوهاي معماري (Architectural Pattern)
3. Communication Package: مديريت data link (مدارها و پروتکل ها) Name Server Access انتقال داده (Data Transport) Data Conversation 4. Abstract OS Package: Information Hiding Virtual API Manage Memory Manage Tasks and threads 5. Abstract HW Package: API for virtual devices (sensors, actuators) Device Deriver Bus Interface Virtual Processors آزمايشگاه سيستم های هوشمند (

Architectural Styles & Patterns

Architectural Styles نحوه انتخاب و نمايش واحدهاي سازنده معماري (Architectural building blocks) را تعريف مي کند. راهنماي طراحي و تصميم گيري براي طراحي اجزاي سيستم و ارائه قوانين مرتبط مي باشد. وابسته به نيازمندي هاي سيستم است. آزمايشگاه سيستم های هوشمند (

Architectural Design Patterns
طراحي هاي سطح بالاي (High-level Designs) تست شده و بکارگرفته شده براي واحدهاي سازنده معماري سيستم. آزمايشگاه سيستم های هوشمند (

نتايج استفاده از Architectural Styles
کاهش و ساده سازي حجم و پيچيدگي ساخت سيستم. کاهش هزينه طراحي و ساخت با استفاده از اجزاي reusable. افزايش هماهنگي بين اجزاي سيستم با استفاده از style-specific and check. آزمايشگاه سيستم های هوشمند (

چهار مشخصه ارائه شده توسط styleها...
Vocabulary of Design Elements ارائه ترمولوژي و واژه هاي اجزاي طراحي از قبيل: Componentها Connectionها ... برخي مفاهيمي که در ارائه Style مشخص مي شوند: Pipes، Filters، Clients، Servers، papers، Databases و ... آزمايشگاه سيستم های هوشمند (

چهار مشخصه ارائه شده توسط styleها...
2. قوانين طراحي يا محدوديت ها (Design Rules or Constraints ): ارائه همه قوانين و محدوديت هايي که در ارائه سيستم بايد مورد توجه قرار گيرد. مانند: عدم استفاده ازحلقه در روش Pipe-filter (Style) Client-server بايد به صورت n-to-one باشد. آزمايشگاه سيستم های هوشمند (

چهار مشخصه ارائه شده توسط styleها
3. Semantic interpretation: اجزاي يک طراحي بايد با دقت و توجه به محدوديت ها تعريف شوند. 4. تحليل (Analysis): تجزيه و تحليل سيستم با استفاده از Style انجام مي شود. آزمايشگاه سيستم های هوشمند (

انواع Architectural Styles

انواع Styleهاي معماري... Data-Centered Repository Blackboard Independent Components (Loosely Coupled) Communicating Processes Event-based: Implicit Invocation، Explicit Invocation Data Sharing Style با استفاده از داده هاي مشترک توسط componentها Hierarchied Style کاهش وابستگي اجزا و انتقال نتايج به زيرسيستم ها در يک سلسله مراتب Interactive Process Style ارتباط بين pattern ها. Call/Return وابسته به ترتيب انجام محاسبات و همراه به يک کنترل Main Program/Subroutine Remote Procedure Call Layered (API) Object Oriented Virtual Machine Interpreter Rule-based e.g. Prolog System Data-Flow Batch Sequential Pipe and Filter آزمايشگاه سيستم های هوشمند (

Data-Flow Style موارد استفاده: اگر سيستم طوري به نظر آيد که در آن يک خروجي خوش-تعريف (well-defined) و easily-identified تهيه مي شود که نتيجه مستقيم ترتيبي از انتقال هاي ورودي با همان ويژگي ها در يک روش مستقل از زمان (Time-independent) است. Integrability : ارتباط بين چندين واسط (Interface) ساده بين componentها. آزمايشگاه سيستم های هوشمند (

Data-Flow Substyles Pipe and filter: محاسبات شامل انتقال هايي روي جريان پيوسته اي از داده مي شود. Closed loop control: سيستم شامل کنترل کردن اعمال مداوم (Continuing Action) که در يک سيستم فيزيکي embed شده است، مي باشد. (and is subject to unpredictable external perturbation so that preset algorithms go awry) !! آزمايشگاه سيستم های هوشمند (

معماري هايCall and Return
دست يافتن به تغييرپذيري (modifiability) و مقياس پذيري (scalability). Sub-style ها: Main program and subroutine: تقسيم (decompose) سلسله مراتبي يک برنامه. هر جزو از برنامه، کنترل برنامه و داده را از پدر (parent) خود گرفته آن را به فرزندانش مي دهد. Remote Procedure Call: داراي main program و روتين ها ولي به صورت توزيع شده روي يک شبکه. افزايش کارايي (performance) به دليل استفاده از چندين پردازنده. Layered: به وسيله API ها. Object Oriented. آزمايشگاه سيستم های هوشمند (

Main program/Subroutine style
اهداف اوليه: استفاده مجدد، توسعه و ساخت مستقل اجزا (Independent development) مثال: style سلسله مراتبي call/return آزمايشگاه سيستم های هوشمند (

Remote Procedure به جاي ساختار سلسله مراتبي در شبکه توزيع مي شود. هر جز به صورت مستقل و بر اساس نياز فراخواني مي شود. افزايش کارايي ( performance) امکان انجام multi-process هدف اصلي: کارايي و استقلال اجزا. آزمايشگاه سيستم های هوشمند (

Layered hierarchies اهداف: چسبندگي بالا، قابليت حمل (portability)، بسته بندي (Packaging)، استانداردسازي مثال: ISO Open Systems، 7 layer Model، TCP/IP، Motif. اجزا: سازمان سلسله مراتبي در لايه ها: هر لايه سرويس هايي را براي لايه خارج از خود مهيا مي کند. هر لايه به عنوان يک client براي لايه درون خود عمل مي کند. در مواردي همه لايه ها به هم دسترسي دارند و يا تنها به برخي لايه هاي دسترسي وجود دارد. سيستم هاي ديگر تنها به close layer مي توانند دسترسي داشته باشند. با استفاده از API ها و پروتکل ها به هم مرتبط مي شوند. مزايا: پشتيباني از طراحي به وسيله Abstraction levels. قابليت توسعه با تسهيل اضافه کردن و يا تغيير يک لايه موجود. معايب: کارايي سيتسم مي تواند به دليل سربار ناشي از لايه بندي هاي غيرضروري (فراخواني توابع) پايين آيدو ساختاربندي در يک حالت clean layers هميشه به آساني ممکن نيست. Requirements don’t make it evidently clear. توسعه آن با مشکل روبروست. آزمايشگاه سيستم های هوشمند (

Object-Oriented/Abstract Data Style
اهداف: مدلسازي طبيعي جهان واقعي (natural modeling) استفاده مجدد با refinement Encapsulation: پنهان سازي اطلاعات (information hiding) Objects: حفظ يکپارچگي و درستي (integrity) داده ها. پنهان کردن بازنمايي داده ها از کاربر. ايجاد ارتباط با استفاده از پيام ها (messages) هماهنگي داده به صورت اتوماتيک صورت مي گيرد. مزايا: سيستم مجموعه اي از agent هاي مستقل است. نگهداري (maintenance) و توسعه (evolution) را بالا مي برد. قابليت استفاده مجدد. معايب: براي تعامل، يک object بايد شناسه (identity) شيئ هدف را بداند. افزايش مقياس (scale up) مي تواند کند و غيرکارا باشد. آزمايشگاه سيستم های هوشمند (

Data-centered Style اهداف: Integrability، مقياس پذيري (scalability) (client/data جديد) اجزا: ذخيره مرکزي داده – وضعيت کنوني. اجزاي مستقل که عمليات خود را روي داده مرکزي انجام مي دهند. Data Centered Repository: پايگاه داده هاي قديمي نوع تراکنش فرايندي را براي اجرا انتخاب و آغاز (trigger) مي کند. Blackboard: حالت داده مرکزي (data store’s State.) فرايند را براي اجرا انتخاب و آغاز مي کند. آزمايشگاه سيستم های هوشمند (

معماري Blackboard کاربردها: Complex data interpretation پردازش سيگنال، speech/pattern recognition. استفاده از داده ها مشترک با استفاده از عامل هاي مستقل. اجزا: Blackboard: مديريت داده ها مرکزي منابع دانش: Evaluate their applicability، محاسبه يک نتيجه، بهنگام سازي blackboard. کنترل: نظارت (monitor) blackboard. زمانبندي فعاليت هاي منابع دانش. آزمايشگاه سيستم های هوشمند (

الگوريتم معماري blackboard
Start control::loop Conrol::nextSource Determine potential knowledge sources by calling Blackboard::inspect Invoke knowledgeSource::execCandidate of each candidate knowledge source Each candidate knowledge source invokes Blackboard::inspect to determine if/how it can contribute to current state of solution Control chooses a knowledge source to invoke by calling KnowledgeSource::execAction Executes knowledgeSource::updateBlackboard Calls Blackboard::inspect Calls Blackboard::update آزمايشگاه سيستم های هوشمند (

Data-Centered Style هنگامي مورد استفاده قرار مي گيرد که هدف محل ذخيره سازي (Storage)، نمايش، مديريت و بازيابي حجم بالايي از داده هاي long-lived مرتبط مي باشد. پايگاه داده ها و repository هاي تراکنشي (transactional) ترتيب اجراي component ها براساس جريان ورودي درخواست ها براي دسترسي/بهنگام سازي داده بوده و داده ها در ساختار هاي سطح بالايي قرار دارند. (Data is highly structured). Blackboard: مقياس پذيري (scalability) براي اضافه نمودن مصرف کننده ها(consumers) داده ها بدون تغيير محصول؛ و يا تغيير پذيري براي تغيير اينکه چه کسي داده را تهيه مي کند و چه کسي آن را مصرف مي کند. آزمايشگاه سيستم های هوشمند (

Virtual Machine Style هنگامي مورد استفاده قرار مي گيرد که براي يک component طراحي شده، ماشين مشخصي که روي آن اجرا شود وجود نداشته باشد. هدف: شبيه سازي عمليات مبتني بر دانش، ارائه يک محيط مجازي بين ماشين و OS، شبيه سازي non-native functionality براي portability و يا prototyping. مثال: Interpreters، مثل Perl Rule-based Systems، مثل Prolog Command Language processors JVM (intermediate language) آزمايشگاه سيستم های هوشمند (

Call-and-return Styles
هنگامي مورد استفاده قرار مي گيرد که: ترتيب محاسبات ثابت است. Component ها پردازش مفيدي را به هنگام انتظار براي نتايج درخواست ها از component هاي ديگر، ندارند. آزمايشگاه سيستم های هوشمند (

Call-and-Return Substyles -1
Object-Oriented: تغييرپذيري (modifiability) و يکپارچگي (integrability) (با توجه به واسط (Interface)ها) موجب ايجاد کيفيت نيازمندي مي شود. (overall modifiability and integrability via careful attention to interface are driving quality requirements). انواع داده abstract: بسياري از انواع داده سيستم که نمايش آنها معمولا تغيير مي کند. Objects: many like modules, commonalties could be exploited through inheritance Call-and-return-based client-server: Modifiability with respect to the production of data and how it is consumed is important آزمايشگاه سيستم های هوشمند (

Call-and-return Subatyles -2
Layered: If the tasks in your system can be divided between those specific to the application and those generic to many application but specific to the underlying computing platform اگر portability بين platform هاي محاسباتي مهم باشد. اگر بتوان از يک لايه زيرساختي که پياده سازي شده است (مانند OS، بسته هاي مديريت شبکه و...) استفاده نمود. آزمايشگاه سيستم های هوشمند (

Independent Component Style
موارد استفاده: سيستم روي يک platform چندپردازنده (multi-processor) اجرا مي شود و يا قرار است در آينده اجرا شود. سيستم مي تواند به صورت مجموعه اي از اجزا با وابستگي کم (loosely coupled) ساختاردهي شود. يعني يک component مستقل از حالت اجزاي ديگر، مي تواند فرايندي را انجام دهد. ميزان سازي کارايي (performance tuning) مهم است. By re-allocating work among processes آزمايشگاه سيستم های هوشمند (

Independent Components
شامل فرايندها و يا Object هاي مستقل که از طريق پيام هاي با هم ارتباط دارند. هيچ کنترلي بين component ها وجود ندارد. تغييرپذيري (بخش هاي مختلف محاسبات از هم جدا هستند). شامل: فرايندهاي ارتباطي: توپولژي هاي ممکن Peer to Peer Client/Server Event System Implicit invocation: براساس تغيير notification. Explicit Invocation: Tight coupling آزمايشگاه سيستم های هوشمند (

Independent Component Substyles
فرايندهاي ارتباطاتي: Message-passing يک مکانيسم خوب براي اين کار است. فرايندهاي سبک (lightweight): دسترسي به داده ها براي اهداف کارايي مهم است. Object هاي توزيع شده: با استفاده از تمامي کارکردهاي object-oriented style و interacting process style. آزمايشگاه سيستم های هوشمند (

Independent Component Substyles
Broadcast: تمامي اجزا نيازمند همزمان شدن (Synchronized) از زماني به زمان ديگر دارند. قابليت دسترسي (availability) يکي از نيازمندي هاي مهم است. Event System: جدا کردن مصرف کننده هاي event هاي از علامت دهنده (signalers) آنها. مقياس پذيري (Scalability) به صورت اضافه کردن فرايندهايي که با event ها trigger شده اند و تا به حال در سيستم شناسايي و يا علامت داده (signaled) شده اند. آزمايشگاه سيستم های هوشمند (

Event-Based (Implicit Invocation)
دو دسته component کلي وجود دارد: دسته اي events را اعلام مي کنند. دسته اي به عنوان interest in events ثبت نام مي کنند. براي هر event يک روتين مشترک وجود دارد که به هنگام آن event رخ مي دهد به صورت خودکار اجرا مي شود. قسمتي از سيستم درصدد انتقال Event ها بين توليدکننده و مصرف کننده آنهاست. محدوديت هاي محتوايي (Semantic): اعلام کننده هاي event ها نمي دانند که کدام component ها تحت تاثير قرار گرفته اند. هيچ فرضي در مورد ترتيب پردازش وجود ندارد. موارد مورد استفاده: ابزارهاي Integrate. Ensure database consistency آزمايشگاه سيستم های هوشمند (

Event-Based (implicit Invocation)
مزايا: پتانسيل استفاده مجدد بالا. توسعه آسان. معايب: Component ها و procedure ها بايد در يک event ثبت نام کنند. ضمانتي براي مورد عمل قرار گرفتن يک event وجود ندارد. تبادل داده: معمولا يک repository مشترک نياز است. تشخيص درست کار کردن سيستم معمولا سخت است. Compiler can no longer do early detection پيگير کد (trace) بدون ابزار debugging سخت است. امکان استفاده از انواع مختلف داده (data typing) بسيار ضعيف است. آزمايشگاه سيستم های هوشمند (

معماري Client/Server مزايا: کاربران تنها اطلاعات را به در صورت نياز دريافت مي کنند. طراحي جزئيات نمايش را بيان مي کند. يک داده را به روش هاي مختلفي مي توان نمايش داد. معايب: نيازمند مکانيزم هاي پيچيده تري براي امنيت و مديريت سيستم دارد. ساخت Application ها نيازمند منابع بيشتري براي پياده سازي هستند. مشکلات توزيعي بودن. (distribution problems). انواع: Tier 1: سيستم واسط کاربر. Tier 2: لايه مياني (middle-tier) مديريت فرايند (منطق تجاري و اجراي قوانين) Functionها (مانند صفبندي queuing، اجراي application و database staging). آزمايشگاه سيستم های هوشمند (

معماري يک و دو لايه client/Server
مديريت پردازش (processing Management) به دو بخش زير تقسيم مي شود: سيستم واسط کاربر (user System interface) سرور مديريت پايگاه داده. (database management server) Tier 1: سيستم واسط کاربر روي محيط desktop کاربر. Tier 2:سرويس مديريت پايگاه داده در يک سرور. محدوديت ها: وقتي تعداد client ها زياد مي شود (بالاي 100 کاربر) کارايي پايين مي آيد. انعطاف پذيري و قدرت انتخاب DBMS براي برنامه ها کم مي شود. (به دليل مديريت فرايند در سطح سرور- stored procedures) انعطاف پذيري محدود در انتقاي functionality برنامه بين سرورها. آزمايشگاه سيستم های هوشمند (

معماري سه لايه client/Server
منطق فرايند را متمرکز مي کند. افزايش کارايي، انعطاف پذيري، قابليت نگهداري (maintainability)، استفاده مجدد و مقياس پذيري. تغييرات تنها بايد يک بار در سرور لايه مياني نوشته شوند تا در سيستم اعمال شوند. يکپارچگي پايگاه داده هاي توزيع شده راحت تر ايجاد مي شود. دسترسي به منابع با براساس نام است. آزمايشگاه سيستم های هوشمند (

زيرساخت لايه مياني (Middle-Ware)
نرم افزار اتصال (connectivity software) مجموعه اي سرويس هايي که موجب انجام عمليات مي شوند. امکان اجراي چندين فرايند روي يک يا چند ماشين براي تعامل از طريق شبکه را مهيا مي سازند. مثال ها: Object Management Group’s Common Object Request Broker Architecture (CORBA) Microsoft’s Component Object Model (COM), DCOM. آزمايشگاه سيستم های هوشمند (

Common Object request Broker Architecture (CORBA)
يک معماري استاندارد براي Object Request Broker (ORBs) . هدف: امکان گسترش محصولات ORB را به وجود مي آورد که از موارد زير پشتيباني مي کنند: Application Portability and inter-operability. ارتباط بين زبان هاي برنامه نويسي مختلف، platform هاي سخت افزاري مختلف، سيستم عامل هاي مختلف و پياده سازي هاي موجود ORB. آزمايشگاه سيستم های هوشمند (

زيرساخت لايه مياني (Middle-Ware)
Application Programming Interface (API): براي برنامه ها امکانات زير را ايجاد مي کند: Location Transparently در شبکه و امکان تعامل با برنامه ها و سرويس هاي ديگر. استقلال از سرويس هاي شبکه. Reliable و در دسترس بودن. افزايش ظرفيت بدون از دست دادن functionality. آزمايشگاه سيستم های هوشمند (

تمامي object هاي تعريف شده در CORBA از يک Interface Definition Language (IDL) استفاده مي کنند. Language mappings are defined from IDL-> c,C++,Ada95, and Smalltack80 امکان عدم تجانس (Heterogeneity) زبان ها C++ Class MineToCee Public virtual CORBA::Object {virtual void myOper(CORBA::long ArgA); } IDL Interface MineToCee {void myOper (long ArgA) } آزمايشگاه سيستم های هوشمند (

ORB Core – CORBA runtime infrastructure ORB Interface – Standard interface (defined in IDL) to function provided by all CORBA- compliant ORBs. IDL Stubs ايجاد شده به وسيله پردازنده هاي IDL براي هر واسط تعريف شده در IDL. پنهان کردن جزئيات سطح پايين ارتباطات Object ها در شبکه از Client ارائه يک API سطح بالا و Object type-specific. آزمايشگاه سيستم های هوشمند (

Object Request Broker (ORB): استقلال client ها از سرويس ها Locational and functional Transparency درخواست هاي client از نظر خودش فراخواني يک تابع محلي است. هنگامي که يک client يک operation را فراخواني مي کند، ORB مسئول يافتن پياده سازي Object مربوطه، در صورت نياز فعال کردن آن، تحويل درخواست به Object و برگرداندن هرگونه پاسخ به در خواست کننده، مي باشد. واسط ORB مجموعه اي از وظايف (tasks) و library هايي که امکان تبديل object reference را به رشته (String) و برعکس به وجود مي آورند. ايجاد ليست آرگومان ها براي در خواست هايي که در dynamic Invocation Interface (Dll) به وجود مي آيند. آزمايشگاه سيستم های هوشمند (

Common Object request Broker Architecture (CORBA): Details
CORBA IDL Stubs and Skeletons: Client Side is called IDL Stub Server Side is called IDL Skeleton تهيه شده توسط کامپايلر IDL در زبان برنامه نويسي هدف. Stubها و Skeleton بين برنامه هاي client و سرور و ORB يک “glue” هستند. تنها امکان فراخواني از راه دور توسط RPC وجود دارد. RPC مي تواند با ارائه Address Pointer مربوط به client به تابعي که در سرور نيازمند فراخواني آن است، انجام گيرد. آزمايشگاه سيستم های هوشمند (

Common Object request Broker Architecture (CORBA): Details 4
Dynamic Invocation Interface (Dll) client side اين واسط اجازه مي دهد يک client به صورت مستقيم به سرويسي که توسط يک ORB ارئه مي شود، دسترسي داشته باشد. برنامه ها از Dll ها براي صادر کردن dynamic درخواست ها به object ها بدون نياز به لينک شدن به IDL interface-specific stub ها. Unlike IDL stubs (which only allow RPC-style requests), the Dll also allows clients to make. Non-blocking requests One-way (send-only) calls. آزمايشگاه سيستم های هوشمند (

Common Object request Broker Architecture (CORBA): Details 4
Dynamic Skeleton Interface (DSI)- server side براي يک ORB امکان Deliver کردن request ها را به يک object پياده سازي شده که هيچ اطلاعاتي در مورد اطلاعات compile-time مربوط به نوع object پياده سازي شده ندارد، مهيا مي کند. The client making the request has no idea whether the implementation is using the type-specific IDL Skeletons or is using the dynamic skeletons. Object Adaptor در تحويل دادن درخواست ها به Object و فعال کردن آن به ORB کمک مي کند. Adaptor جزئيات object را پنهان مي کند. مانند اينکه آيا آن يک object پايگاه داده است يا يک library object. آزمايشگاه سيستم های هوشمند (

Other Brokers: Microsoft’s Component Object Model (COM, DCOM)
چارچوبي (framework) براي يکپارچه سازي component ها. امکان Assemble کردن چندين component مختلف که توسط vendor هاي مختلفي ارائه شده است را براي ساخت يک سيستم ايجاد مي کند. Distributed COM (DCOM) براي تعاملات توزيع شده تحت شبکه. OLE (Object Linking & Embedding)، ActiveX، MTS سرويس هاي سطح بالايي که روي COM ساخته شده اند. آزمايشگاه سيستم های هوشمند (

MS, Component Object Model (COM, DCAM)
OLE سرويس هايي (مانند object linking and embedding) ارائه مي دهد که در ايجاد مستندات ترکيبي (مستنداتي که به وسيله چندين منبع ابزاري (tool source) تهيه مي شوند) مورد استفاده قرار مي گيرد. ActiveX گسترشي براي استفاده از component ها در وب سايت ها. MTS گسترشي با سرويس هاي Enterprise (تراکنش، امنيت) براي ايجاد امکان ساخت سيستم هاي اطلاعاتي سازماني با استفاده از COM. COM+ سرويس هاي MTS و message queing را در COM ترکيب کرده تا برنامه نويسي COM را ساده تر کند. يکپارچه شده با visual Basic، visual C++ و J++ آزمايشگاه سيستم های هوشمند (

MS, Component Object Model (COM, DCAM)
سرويس هاي پياده سازي شده توسط COM Objects تحت يک مجموعه از واسط ها انتشار مي يابد. COM يک ساختار binary براي واسط بين client و Object تعريف مي کند. COM Object ها و واسط ها با استفاده از Microsoft Interface Definition Language (IDL) تخصيص داده مي شوند. آزمايشگاه سيستم های هوشمند (

Component Object Model (COM, DCOM)
هر COM Object در داخل يک سرور اجرا مي شود: In-process server: client و سرور در يک فرايند (process) مشترک اجرا مي شوند. Local Object proxy: سرور در يک فرايند جدا ولي در يک ماشين مشترک اجرا مي شود. ارتباطات به وسيله ارتباطات inter-process انجام مي شود. Remote Object proxy: يک remote server روي يک ماشين ديگر. ارتباطات به وسيله DCE RPC (پشتيباني توسط COM) انجام مي گيرد. تمامي COM Object ها با يک component پايگاه داده ثبت نام شده اند. آزمايشگاه سيستم های هوشمند (

انتخاب يک Style معماري آزمايشگاه سيستم های هوشمند (

قوانين Thumb براي انتخاب Style ها
هدف کاتالوگ style ارائه يک راهنماي طراحي (design handbook) است: اگر مشکل شما شبيه الف است، از style ب استفاده کنيد. The practice is not that advanced yet. The best that we can do is offer rules of thumb. استفاده از انواع معماري با قانون خاصي همراه نيست. بلکه نتيجه گيري مقطعي (Rules of thumb) مد نظر است. آزمايشگاه سيستم های هوشمند (

عمليات واحد (unit operations)
تدوين قوانين مربوط به عمليات طراحي در يک معماري به کار گرفته شده است. شامل: Abstraction Compression Part-whole decomposition Replication Resource sharing آزمايشگاه سيستم های هوشمند (

Abstraction يک component مجازي (Virtual) ايجاد مي کند. موارد استفاده: Simulated target platform سيستم هاي لايه بندي شده (layered systems). واسطي مشترک براي مجموعه اي از اجزاي پياده سازي شده در محيط هاي نامتجانس (Heterogeneous). آزمايشگاه سيستم های هوشمند (

Compression دو component را با هم ترکيب کرده و يک component ايجاد مي کند. موارد استفاده: بهبود کارايي. تسريع توسعه سيستم. آزمايشگاه سيستم های هوشمند (

Decomposition يک component بزرگ را به چندين اجزاي کوچکتر تقسيم مي کند. Part-whole decomposition: Component ها از يک سري subcomponent کوچک و ثابت ساخته مي شود. (مانند model-view-controller). براي integrability، گسترش پذيري (extensibility) و قابل فهم بودن (Understandability). آزمايشگاه سيستم های هوشمند (

Decomposition يک decomposition است. (Is-a) يک subcomponent يک خصوصي سازي (specialization) از functionality پدر خود را نمايش مي دهد. (مانند ارثبري کلاس). Used for reuse by increments. آزمايشگاه سيستم های هوشمند (

Replication تکثير مشابه (exact duplication) از يک component. موارد استفاده براي بهينه سازي: Reliability (redundant operation). بهبود کارآيي (data caching). آزمايشگاه سيستم های هوشمند (

Typical Design Trade-Offs

اشتراک منابع داده و يا سرويس ها را encapsulate مي کند و آن را بين چندين مصرف کننده مستقل به اشتراک مي گذارد. (مثال: پايگاه داده هاي اشتراکي، سرورها در client/server). موارد استفاده: Integrability Portability Modifiability آزمايشگاه سيستم های هوشمند (

عمليات واحد و کيفيت Scalability System Modification Integrability Portability Sequential Performance Concurrent Performance Fault tolerance Ease of system creation Component modifiability Ease of component creation reusability Abstraction + - Compression Part-whole decomposition Is-a decomposition Replication Resource sharing آزمايشگاه سيستم های هوشمند (

Domain-specific Architecture

معماريDomain-specific
کتابخانه اي از style هاي مختلف. ارئه اطلاعاتي در مورد سيستم جديد در يک حوزه. عدم انجام کار مجدد براي مفروضات و روابط شناخته شده قبلي. سيستم هاي نامتجانس: محلي (locational). Simultaneous سلسله مراتبي (Hierarchical). آزمايشگاه سيستم های هوشمند (

مثال: locational Heterogeneity
A-7E از يک style پردازش همکارانه (cooperating process) در function driver و style call/return در جاهاي ديگر استفاده مي کند. آزمايشگاه سيستم های هوشمند (

سيستم event يک blackboard است، ولي بعد از decompose شدن، component يک layered style را نشان مي دهد. آزمايشگاه سيستم های هوشمند (

A-7z به طور همزمان از لايه يندي، پردازش همکارانه و object oriented style استفاده مي کند. آزمايشگاه سيستم های هوشمند (

معماري peer-to-peer تمايزي بين فرايندها (nodes) وجود ندارد. هيچ يک از نودها به عنوان process داراي تقدم و اولويت نيست. هر کدام از نودها شامل موارد زير هستند: مشخصات در Data-store خود. يک جدول مسيردهي پويا (dynamic routing table) از آدرس نودهاي ديگر. مثال: gnutella، freenet. آزمايشگاه سيستم های هوشمند (

کنترل فرايندها – پيامدها(issues)
عناصر محاسباتي (computational) تعريف فرايند (شامل مکانيزم هايي براي تغيير متغيرهاي فرايندها). الگوريتم کنترل (چگونگي تصميم اينکه کي و چگونه تغييرات انجام مي شود.) عناصر داده اي (data elements): متغير فرايندها، set point. Control loop scheme Open-loop، closed-feedback، closed-feed forward Drawback – توجه به مسايل زير الزامي است: چه متغيرهايي بايد نظارت شوند. چه حسگرهايي بايد به کار گيرد. How to calibrate them چگونه با زمانبندي sensing و نظارت آنها، رفتار شود. آزمايشگاه سيستم های هوشمند (

سيستم هاي کنترل فرايندها
Continually running system used for maintaining correct values. The errors are compensated for through feedback. مثال: سيستم کنترل دما. سيستم کنترل power plant. متغيرها: متغيرهاي فرايند: ويژگي هايي از فرايند که مي توان اندازه گيري نمود. مقادير به دست آمده از حسگرها. متغيرهاي کنترل شده: متغيرهاي فرايند که سيستم علاقه مند به کنترل مقدار آن هاست. مقادير مرجع (reference variables): set point مقدار مطلوب براي يک متغير کنترل شده. آزمايشگاه سيستم های هوشمند (

معماري هاي کنترل فرايند (process control)
سيستم open-loop: عدم استفاده از متغيرهاي پردازش براي تطبيق دادن سيستم. عملا براي پردازش هاي فيزيکي در دنياي واقعي ارائه شده است. عملا اجراي اين معماري سيستم، امکان پذير نيست و مي توان به عنوان جزيي از يک معماري مورد استفاده قرار گيرد. سيستم closed-loop: استفاده از اطلاعاتي در مورد متغيرهاي پردازش براي اداره متغيرهاي پردازش جهت جبران تغييرات در متغيرهاي پردازش و شرايط عمليات. آزمايشگاه سيستم های هوشمند (

کنترل فرايند (closed loop)
سيستم کنترل بازخورد (feedback). اندازه گيري متغيرهاي کنترل شده. تنظيم متغير با set-point ها. آزمايشگاه سيستم های هوشمند (

کنترل فرايند (closed loop) - 2
سيستم کنترل بازخورد (feedback) پيش بيني تغييرات براي متغيرهاي کنترل شده با نظارت بر ساير متغيرهاي پردازش. آزمايشگاه سيستم های هوشمند (

ارزيابي معماري نرم افزار

کي و چرا بايد معماري را تحليل کرد؟ -1
هنگام ساخت يک سيستم. Architecture is the earliest artifact where tradeoffs are visible. آناليز بايد هنگام تصميم گيري براي معماري انجام شود. The reality is that analysis is ofen done during damage control, later in the project. متداول ترين دلايل شکست نرم افزار: عدم تحليل نيازمندي ها. عدم تحليل معماري و طراحي. آزمايشگاه سيستم های هوشمند (

کي و چرا بايد معماري را تحليل کرد؟ -2
پيدا کردن (acquiring) يک سيستم جديد. تحليل معماري هنگامي که قرار است سيستم مدت طولاني در سازمان کار کند، بسيار مفيد است. تحليل معماري مکانيزمي براي فهميدن روش بازکردن (evolve) سيستم ايجاد مي کند. Analysis can also provide insight into other visual qualities. تحليل بايد به صورتي انجام گيرد که تکامل سيستم در معماري سيستم قابل trace باشد. آزمايشگاه سيستم های هوشمند (

بررسي معماري (Architectural reviews)
تکنيک هاي پرسشي (questioning techniques): براي سنجيدن جنبه هاي يک معماري براي يک reason داده شده. تکنيک هاي مبتني بر سناريو (مانند SAAM). تکنيک هاي مبتني بر پرسشنامه (Questionnaire). تکنيک هاي اندازه گيري (measuring): براي پاسخ به يک معيار کيفيتي مشخص. Metrics: تبديل کننده هاي کمي مشاهدات اندازه گيري شده. (quantitative interpretation of observable measures ) مانند: complexity metrics، performance metrics. شبيه سازي، prototype،آزمايش ها (experiments): مدل هاي domain-specific يک معماري و با مدل کارآيي. آزمايشگاه سيستم های هوشمند (

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

Similar presentations

Presentation on theme: "معماری سيستمهای با مقياس بزرگ"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "معماری سيستمهای با مقياس بزرگ"— Presentation transcript:

Similar presentations

About project

Feedback