1آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
معماری سيستمهای با مقياس بزرگ
آزمايشگاه سيستمهای هوشمند93پاييز
2آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSمشخصات سيستمهای
.کارکرد پيچيده و گسترده انتظارات سطح باال در مورد نيازمنديهای غير
کارکردی..نياز به اطالعات گسترده.توزيع شدگی پردازش کارايي و يا اطالعات يکپارچگی سخت افزارها و نرم افزارها و
سيستمهای ارتباطی مختلف.
3آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSلزوم داشتن يک
برای يکپارچه سازی سيستمهای مختلف بهمنظورنيل به:
اقتصادی ساختن سيستم از نظر توسعه و پشتيبانی ازطريق استفاده مجدد..
رضايت مشتری←فروش يکباره
(برای حل مشکل سيستم های جديدgreen field)برای رسيدن به نيازهای بازار و کسب وکاربرای رسيدن به اهداف استراتژيک سازمانیمحافظت از سرمايه
4آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSنمونه هايي از سيستمهای
سيستم رزرواسيون بليطسيستمهای مالياتیسيستمهای بانکیسيستمهای بازار بورس و سهامسيستمهای انبارداریonline.و توزيع شده سيستمهای خدماتیonlineسيستمهای جامع و يکپارچه سازمانی.سيستمهای کنترل و اندازه گيری از را دور بالدرنگ.سيستمهای مخابراتی
5آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSSمتغييرهای موجود در
کارايي←محتوا
نيازمنديهای غير کارکردی و ديگر ←کيفيت محدودژت ها مانند محدوديت های تکنولژيکی
زمان مورد نياز برای تکميل ←زمانبندی LSS
سرمايه، فراساختار و هزينه منابع ←هزينه انسانی.
6آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSSمتغييرهای موجود در
Content
Cost
Schedule
Quality
7آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
LSSموارد مورد توجه در
تقسيم وظايف در توسعهLSS زمينه های مورد(توجه(
افراد مختلفمسوليت های متفاوتتخصصهای مختلف
هر زمينه دارای مسائل مختلف و روشهايي جهتحل مشکالت می باشد.
هر روش ديدگاههای متفاوتی در مواجهه با مسالهدارد.ديدگاه تيم طراحیديدگاه مديريت پروژه.ديدگاه کسب و کار
8آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Software Development For Large-Scale Systems
9آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Software Architecture for LSS
Agenda What Why an LSS Views Architecture description
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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Introduction
Large-Scale Software Architecture
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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
IEEE 1471 viewpoints
Conceptual and analysis viewpoint Logical design viewpoint Environment/physical viewpoint
26آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
UML: Unified Modeling Language
27آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
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
28آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Logical design viewpoints
Viewpoint UML diagram Description
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
29آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Environment/physical viewpoint
Viewpoint UML diagram Description
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
30آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Roles of Software Architect
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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Other software architecture approaches
4+1 views RM-ODP viewpoints Bass architectural structures Hofmeister software architecture views
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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
RM-ODP viewpoints
Enterprise viewpoint Information viewpoint Computational viewpoint Engineering viewpoint
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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Hofmeister views
Conceptual view Module view Execution view Code view
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آزمايشگاه سيستم های هوشمند
(http://ce.aut.ac.ir/islab)
Types of design
Data design Architectural design External interface design Algorithmic design
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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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آزمايشگاه سيستم های هوشمند
(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
Recommended