Lecture 13 Introduction to Software Architecture

Transcription

1 Lecture 13 Introduction to Software Architecture Software Systems Design and Implementation ITCS/ITIS 6112/8112 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct. 7, 2008

2 Announcements Deliverable 1 still grading Deliverable 2 (Use Cases) Due Oct. 14 at 5:00 pm Homework 2 Expect an assignment this week Midterm exam Thursday, Oct. 16 2

3 The most common miracle of software engineering is the transition from analysis to design and design to code. --- Richard Due 3

4 Engineering Design Resolution Iteratively developing a design solution Use input from SRS and analysis model Comprised of two main activities: 1. Architectural design High-level outline of the software parts and behavior 2. Detailed design A detailed view of the software design 4

5 Architectural Design In architectural design, we specify: Structure -- the software program s major parts Responsibilities Properties Interfaces Relationships Behavior -- interactions among software program s major parts High-level description of structure and behavior is called a software architecture 5

6 Defining Software Architecture Perry and Wolf, 1992 A set of architectural (or design) elements that have a particular form Boehm et al., 1995 A software system architecture comprises: A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements Clements et al., 1997 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them 6

7 Commonality Among Definitions Architecture defines major components component relationships (structures) component interactions Behavior of components is a part of architecture when it can be discerned from the point of view of another component Architecture defines the rationale behind the components and the structure G. Booch talk on software architecture.html 7

8 Software Architecture Definition, Distilled Software architecture encompasses the set of significant decisions about the organization of a software system Selection of the structural elements and their interfaces by which a system is composed Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization Reuse of design knowledge that captures architectural solution We ll discuss this more later 8

9 Advantages of Explicit Architecture Stakeholder communication Used as a focus of discussion by stakeholders System analysis Supports analysis of whether the proposed system design can meet requirements Functional Non-functional Supports early evaluation of alternative approaches to design Large-scale reuse Architecture may be reusable across a range of systems Architectural styles 9

10 Terminology Software component Cohesive piece of software functionality that can be deployed independently and can be composed with other components (many arguments about the definition) Different levels of abstraction for components Program module or object-oriented class (simple) Subsystems (more complex) Databases and middleware systems (more complex) 10

11 Terminology Module A general term for a unit of software A program unit with constituent parts Hierarchy of software units 1. Program 2. Sub-programs or sub-systems 3. Packages, compilation units 4. Classes, functions 5. Attributes, operations, blocks 6. Lines of code Any of the above are modules, except for lines of code 11

12 Describing Software Architectures IEEE 1471 Recommended Practice for Architectural Description of Architectural Description of Software-Intensive Systems Define the relations between Stakeholders Concerns Views Viewpoint Models Architectural Description 12

13 Elements of Software Architecture Documentation Model a semantically closed (i.e., well-defined) abstraction of a system simplification used to understand system being created View representation of entire system from perspective of a related set of concerns Concern interests which pertain to the system's development its operation any other aspects that are important to one or more stakeholders Stakeholder individual, team, or organization with interests in a system 13

14 Conceptual Model of Documenting Architecture IEEE

15 Stakeholders & Concerns Maintainer End User Customer Sales Dev Manager Developer Functionality Price Dev Costs On Time Delivery Stability & Maintainability Performance Ease of Use Ease of Debugging Modifiability Sys Admin Testability & Traceability Structure & dependency between component Ease of Integration Ease of Installation 15

16 Conceptual Model of Documenting Architecture IEEE

17 Representing Software Architecture: The 4+1 View Approach Logical View Implementation View End-user Functionality Use Case View Programmers Configuration management System integrators Performance Scalability Throughput Process View Deployment View System engineering System topology Communication Provisioning 17

18 Adapting Views Not all systems require all views Single process (ignore process view) Small program (ignore implementation view) Single processor (ignore deployment view) Some systems require additional views Data view Security view Other aspects 18

19 Conceptual Model of Documenting Architecture IEEE

20 Models Non-standard models Expressed without universally defined semantics Example: box and line diagrams, block diagrams Models Data flow, control flow Use cases Interaction models (e.g., sequence diagrams) Data models (e.g., ERA diagrams) Object models (e.g., class diagrams) Many more Modeling notations Architecture Description Language (ADL) Unified Modeling Language (UML) 20

21 Architecture Metamodel QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. 21

22 Architecture metamodel QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. 22

23 Architecture Metamodel QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. 23

24 24