1 Introduction. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2006

Transkriptio

1 1 Introduction 1.1 What is software architecture? 1.2 Why is software architecture important? 1.3 Architecting process 1.4 Architecture-oriented programming 1.5 Conclusions 1

2 1.1 What is software architecture? Software architecture: The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. (IEEE Standard ) Software architecture covers: Major parts and their relationships Structure and behavior Static and dynamic structure Different viewpoints and levels Solutions and their rationale Rules and principles on system development 2

3 An alternative definition (Boehm 1995) A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system requirements A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system requirements 3

4 Architectural rules Some architectural decisions imply global design or implementation rules About usage of technology, algorithms, data structures, design and implementation patterns "Architecture is the set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity." (D'Souza & Wills) Architecture = The constitution of a system 4

5 Architecture is the soul of a software system Changing parts: may be changed by lower level design & implementation decisions Unchanged core: architecture 5

6 Architecture must be concrete and documented If a project has not achieved a system architecture, including its rationale, the project should not proceed adgsfgsgf wfrwffffdsff to full-scale system development. Specifying the RwrWRwrW architecture as a deliverable enables its use throughout the development and maintenance process. - Barry Boehm, 1995 adgsfgsgf wfrwffffdsff RwrWRwrW e.g. UML 6

7 Architectural issues Division into subsystems Communication between subsystems Communication between processes Accessing data, persistency, security Assignment of functionality to components Physical distribution Scaling and performance Preparing for future needs Reusability... 7

8 View Architectural views View Static reverse engineering Dynamic reverse engineering Modelling View Code Code generation Functioning system Compilation 8

9 1.2 Why is software architecture important? Systems becoming more and more complex Need to reuse subsystems, product families New technologies emphasize architecture Facilitates developing, testing and maintenance Need to communicate about a system (stakeholders) Architectural description can be used to assess a system General guideline for software development process 9

10 Taloussanomat

11 Implications of bad architecture a system cannot be implemented a system cannot be delivered in time a system does not scale up a system is inefficient a system is difficult to test and maintain a system cannot be reused as planned a system is difficult to port to another environment system development is difficult to manage 11

12 Reasons for a bad architecture: - bad communication - architecturally significant requirements not identified - inexperienced architect - pressure from management - weak-minded architect - bad development process 12

13 Trend: Model-driven driven software engineering Human effort Traditional: Implementation Executable Design Architecture = fully automated = unnecessary work Requirements Added value 13

14 Trend: Model-driven driven software engineering Human effort Model-driven: Requirements model Architecture model Design model Implementation Executable partially automated - modeling languages - model transformations - code generation Added value 14

15 1.3 Architecting process Starting points Empty table: new system is developed from scratch Reference architecture: assumed architectural model Service platform: assumed set of available services Architectural platform: assumed architectural infrastructure Product platform: assumed domain-oriented platform Product: architectural evolution in existing system 15

16 Architecture-centric centric development process Quality requirements Architecturally significant requirements Requirements analysis Core functional requirements Initial architectural design Initial architecture Estimate quality attributes New or changed requirements Secondary functional requirements Architectural transformation not OK OK Deployment Testing Implementation Detailed design Base architecture 16

17 Architecturally ly significant requirements Core functional requirements - Often the starting point for architectural design Quality (non-functional) requirements typically imply architectural decisions - Security, performance, scalability, price, flexibility, maintainability, understandability, portability, reusability etc. Architecturally significant requirements have priorities - Typically one or few requirements dominate the architecture - Other architectural decisions have to comply with existing solutions Requirements should be linked to solutions - How is the system able to satisfy architecturally significant requirements 17

18 Software decomposition Basis for decomposition: Functionality Generality Distribution Flexibility Concern (aspect)... Concern 18

19 Stakeholders: PressureP on architect Lots of features, soon, compatible, competetive Behavior, performance, security, reliability Modifiable, testable END USER Low cost, our people MARKETING MAINTENANCE Low cost, timely delivery, not changed often MANAGEMENT ARCHITECT CUSTOMER 19

20 Architecture and organization BU system team subsystem person person comp comp component person => architectural structure = organization structure 20

21 1.4 Architecture-oriented programming Architecture-oriented programming means a software construction paradigm that is based on an existing architecture. An application is built using the structures and mechanisms given by the architecture. The essential design problem is how to map the requirements to the architecture rather than to the programming language. Examples: How to map application requirements to EJB? How to map application requirements to Symbian OS? How to map application requirements to Swing? 21

22 Trend: higher-level solution worlds Implementation paradigm Variables Subroutines Structured data types Abstract data types language support Classes, interfaces Design patterns Components Frameworks 22

23 Implications When used as part of solution world, architecture should be: generic: suitable for a variety of applications understood by an average application programmer described precisely and completely documented and trained in a usage-oriented manner 23

24 Platform architecture vs. programming language Platform architecture may imply static correctness rules Platform architecture may imply dynamic correctness rules Platform architecture may need a supporting tool set (architecture-oriented programming environment) 24

25 1.5 Conclusions Software architecture is design above the level of components Software architecture = structure + behavior + rationale + rules Software architecture = constitution of software system Software development is becoming more and more architecture-centric 25