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

1آزمايشگاه سيستم های هوشمند

(http://ce.aut.ac.ir/islab)

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

آزمايشگاه سيستمهای هوشمند93پاييز



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

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 Class 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


Component 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


Deployment Deployment Mapping of software to hardware for distributed

systems

Physical data Deployment Physical view of a particular database

Process Deployment 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 Class 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

Documents

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