Lecture 11 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

Software Architecture

You employ stone, wood and concrete, and with these materials you build houses and palaces. That is construction. Ingenuity at work. But suddenly you touch my heart, you do me good, I am happy and I say “ That is beautiful.” That is Architecture. -Le Corbusier 1923

4 Antecedents of Software Architecture

5

6

7

8

Software Architecture in Context

10 A computer system

11 A computer system in isolation… In space, no-one can hear you ?

12 Stakeholders… Architect Operator Supplier CEO Technician Developer Sysadmin Consumer QA BillGates Customer CEO

13 Other systems… Enrolments Student Labs Networking infrastructure Accounting Management reporting Payroll

14 Opportunities and risks… Sell a lot of systems Go to IPO Late to market Sell a few systems Deliver a poor performer Build a reputation Tax issues Misjudge the market BillGates

15 Constraints and enablers… Operating system Standards Policies Regulations Faster processor Legacy systems Lots of Java developers Not many database developers Ethics and environment

16 It’s complicated.

17 What is the role of architecture? Leaning tower image from Gary Feuerstein. Other images from The Big Ball of Mud, by Yoder and Foote.

18 Development lifecycle Architecture plays a vital role in establishing the structure of the system, early in the development lifecycle The evolutionary delivery lifecycle model (Rapid Development, Steve McConnell) Architecture sets system structure First iteration implements system core

19 System lifetime Architecture is about decisions that affect the whole lifetime of the system

20 The Architecture Business Cycle

21 Architectural Influences Stakeholders –each stakeholder has different concerns & goals, some contradictory Development Organization –immediate business, long-term business, and organizational (staff skills, schedule, & budget) Background & Experience of the Architects –repeat good results, avoid duplicating disasters The Technical Environment –standard industry practices or common SE techniques

22 Stakeholders Management Stakeholder Marketing Maintenance Organization End Users Customers Architect Lower Cost! New Features! Faster! Compete! Performance! Reliability! Security! Behavior! Extensibility! Maintainability! Deliver on Time! Don’t Keep Changing!

23 Trade-offs Architect PerformanceSecurity MaintainabilityReliability Current CostFuture Cost

What is a good definition of Software Architecture?

25 Software Architecture Definition The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them

26 Software Architecture Defines The Software Elements –Abstraction of the system Omits some information And relationships between elements –Relationships typically are interfaces –Architecture talks about the public interfaces

27 Other Definitions of Software Architecture Perry and Wolf –Software Architecture = { Elements, Form, Rationale } – what how why Shaw and Garlan –Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten –Software architecture deals with the design and implementation of the high-level structure of software. –Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

28 Other Definitions of Software Architecture Organizational structure of a system or component (IEEE Standard Glossary of Software Engineering Terminology 1990) IEEE – Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution

29

30

31 What type of requirements drive architectural design? Answer: Quality attribute requirements are the primary drivers for architecture design.

32

33

34 Architecture and Functionality Functionality is largely orthogonal to quality attribute requirements. Functionality is the ability of a system to do the work it was intended to do. Systems are decomposed into elements to achieve a variety of purposes other than function. –Architectural choices promote certain qualities as well as implement the desired functionality.

35 Effects of Architectural Decisions on Quality Attributes The degree to which a system meets it’s quality attribute requirements is dependent on architectural decisions. A change in structure improving one quality often affects the other qualities. Architecture is critical to the realization of quality attributes. These product qualities should be designed into the architecture. Architecture can only permit, not guarantee, any quality attribute.

36 Role of the Software Architect Architect Balance Stakeholder Concerns Manage Complexity Functional Requirements Communicate! Balance Quality Attributes Bring Technology Report Results

37 Systems Structure(s) Systems have more than one structure –Module structure –Interaction structure –Deployment structure Every system has an architecture Behavior is part of the architecture –Behavior allows component interaction to be specified

38 Structures and Views From:

39 Structures and Views Modules –Functional decomposition & uses information –Class structure (generalization) & Layers Component-and-Connector –Runtime components –Concurrency and shared data models Allocation –Deployment, Implementation, work assignments

40 Types of Views Architect Module Runtime Allocation How to express each view. What is each view useful for?

41 Integrating the Views From:

42 Behavioral Modeling

43 Views Systems are composed of many structures –Code units, their decompositions and dependencies –Processes and how they interact –How software is deployed on hardware –And others A view is a representation of a structure, that is, a representation of a set of system elements and the relations associated with them.

44 SEI Architectural Viewtypes Module Viewtypes describe how the system is to be structured as a set of units of implementation. Component and Connector (C&C) Viewtypes describe how the system is to be structured as a set of interacting runtime elements. Allocation Viewtypes describe how the system relates to non-software structures in its enviroment. A viewtype defines the element types and relationship types used to describe the software architecture from a particular perspective.

45 Reference Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Second Edition (2006), Addison- Wesley. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, j., Little, R., Nord, R. and Stafford, J., Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley. Documenting Software Architectures