Ch 1: The Architecture Business Cycle

Size: px

Start display at page:

Download "Ch 1: The Architecture Business Cycle"

Beverly Flowers
6 years ago
Views:

2 Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures of large software systems: abstract view eliminates details of implementation, algorithm, & data representation concentrates on the behavior & interaction of black box elements

3 Definition The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

4 Architecture Business Cycle (ABC) Quick Exercise : What is the relationship of a system s software architecture to the environment in which the system will be constructed and exist?

5 Architecture Business Cycle (ABC) Answer: Software architecture is a result of technical, business, and social influences. In turn, it affects each of these environments.

6 Figure 1.2 Influence of stakeholders on the architect

7 Architectural Activities Creating the Business Case for the System Understanding the Requirements Creating or Selecting the Architecture Communicating the Architecture Analyzing or Evaluating the Architecture Implementing Based on the Architecture Ensuring Conformance to an Architecture

8 What makes a Good Architecture? No such thing as an inherently good or bad architecture. Architectures are more or less fit for some stated purpose. Architectures can be evaluated -one of the great benefits of paying attention to them - but only in the context of specific goals. Rules of Thumb: process & product (structural) recommendations

9 Rules of Thumb (pp 15 & 16) Process Recommendations: include functional requirements and a prioritized list of quality attributes the system must satisfy analyze & formally evaluate before it is too late to change Product Recommendations: well-defined modules using principles of information hiding & separation of concerns separate modules that produce data from those that consume data to increase modifiability & staged upgrades write tasks or processes to allow easy reallocation, perhaps at runtime

10 Ch 2: What is Software Architecture? Quite often shown as box-and-arrow diagrams. Control Process (CP) Prop Loss Model (MODP) Reverb Model (MODR) Noise Model (MODN) Figure 2.1

12 What s Missing? What is the nature of the elements? What are the responsibilities of the elements? What is the significance of the connections? What is the significance of the layout? Unless we know precisely what the elements are & how they cooperate to accomplish the purpose of the system, this diagram is unhelpful!

13 Definition Again The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, an the relationships between them. We see the elements, but what properties do they or their relationships have?

14 Externally Visible Properties The assumptions that other elements can make of an element, such as: its provided services, performance characteristics, fault handling, shared resource usage, etc.

15 Definition Implications 1 - architecture defines software elements. 2 - systems can and do comprise more than one structure, all are part of the architecture. 3 - every computing system with software has an architecture. 4 - the behavior of each element is part of the architecture as far as its behavior can be observed or discerned from the point of view of another element. 5 - the definition doesn t judge goodness or badness.

16 Another Definition for SA (Garlan and Shaw) Components Connectors Constraints

17 Useful Concepts Three stages that capture characteristics of an architecture, on the way from box-and-arrow to full software architectures: Architectural Patterns Reference Models Reference Architectures Figure 2.2 Reference Model Architectural Pattern Reference Architecture Software Architecture

18 Architectural Patterns A description of element & relation types together with a set of constraints on how they may be used. These constraints on an architecture define a set or family of architectures. For example, the client-server pattern has 2 element types (?); their relationship is a protocol that the server uses to communicate with each of its clients, the clients don t communicate directly. Functionality is excluded.

19 الگوی معماری

20 Value of Patterns They exhibit known quality attributes, and are a reuse of experience. Some patterns solve performance problems, others apply to high-security systems, or high-availability goals. Often the architect s first major design decision. Also referred to as architectural styles.

21 Reference Models A division of functionality together with data flow between the pieces. A standard decomposition of a known problem into parts that cooperatively solve the problem. They arise from experience, and are thus a characteristic of mature domains. For example, the standard parts of a compiler or database management system & how they work together.

22 مدل مرجع

23 Reference Architectures A reference model mapped onto software elements and the data flows between them. The elements must cooperatively implement the functionality defined in the reference model. The mapping may be 1-1, but an element may implement a part of a function or several functions.

24 معماری مرجع

26 Why is Architecture Important? Three fundamental reasons from a technical perspective: Communication among stakeholders a basis for mutual understanding, negotiation, & consensus Early design decisions earliest point at which decisions can be analyzed Transferable abstraction of a system can promote large-scale reuse

27 دلايل اهميت ويژه معماری نرم افزار

28 Early design decisions The architecture: defines constraints on implementation dictates organizational structure inhibits or enables a system s quality attributes studying it can predict system qualities easier to reason about and manage change helps in evolutionary prototyping enables more accurate cost & schedule estimates

29 تصميم های اوليه طراحی

33 Quality Attributes High performance Scalability Deliver incremental subsets Re-usable elements Manage the time-based behavior of elements; the frequency & volume of inter-element communication Carefully localize the use of resources to facilitate the introduction of high-capacity replacements Carefully manage intercomponent usage Restrict inter-element couplings so an extraction doesn t have too many environment attachments to be useful

34 Architecture: a Transferable, Reusable Model The earlier in the lifecycle re-use is applied, the greater the benefit. Software Product Lines share a common architecture. Composing with large, externally developed elements. Restrict the vocabulary of design alternatives: patterns. Architecture permits template-based development. Used as the basis for training.

36 Software Architecture vs. System Architecture

37 Structures and Views A view is a representation of a coherent set of architectural elements, consisting of: a set of elements the relationships among them A structure is the set of elements itself, as they exist in software or hardware. Often used interchangeably, text will distinguish.

39 Groups of Architectural Structures Module structures units of implementation with assigned areas of functionality - usually static Component-and-connector structures runtime components (principal units of computation) and connectors (communication vehicles) Allocation structures show relationships between software elements & external environments (creation or execution)

40 Three Types of Structures Correspond to the three broad types of decisions that architectural design involves: How is the system to be structured as a set of code units (modules?) How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)? How is the system to relate to non-software structures in its environment (i.e., CPUs, file systems, networks, development teams, etc. - allocation)?

41 General SA Structure

42 Module structures

43 Component-and-connector structures

44 Allocation structures

45 Module: Decomposition

46 Module: Uses

47 Module: Class

48 Component and Connector (C&C): Client Server

49 Component and Connector (C&C): Concurrency

50 Component and Connector (C&C): Process

51 Component and Connector (C&C): Shared Data

52 Allocation: Deployment

53 Allocation: Implementation

54 Allocation: Work Assignment

55 خلاصه و جمع بندی ساختار های معماری

56 Choosing Structures Kruchten s Four + One Views: Logical - elements are key abstractions that are objects or classes in OO. This is a module view. Process - addresses concurrency & distribution of functionality. This is a C&C view. Development - shows organization of software modules, libraries, subsystems, and units of development. This is an allocation view. Physical - maps other elements onto processing & communication nodes, also an allocation view, but usually referred to specifically as the deployment view.

57 4+1 View

58 4+1 View

60 Non-functional Properties Each structure provides a method for reasoning about some of the relevant quality attributes, for example: the uses structure, must be engineered to build a system that can be easily extended or contracted the process structure is engineered to eliminate deadlock and reduce bottlenecks the module decomposition structure is engineered to produce modifiable systems, etc.

61 Relating Structures to Each Other Although the structures give different system perspectives, they are not independent. Elements of one structure are related to elements in another, and we need to reason about these relationships. For example, a module in a decomposition structure may map to one, part of one, or several, components in a component-and-connector structure at runtime. In general, mappings are many-many.

Ch 1: The Architecture Business Cycle

Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures