lecture 13 (architecture)
TRANSCRIPT
![Page 1: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/1.jpg)
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
Lecture 13 Introduction to Software
Architecture
![Page 2: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/2.jpg)
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
![Page 3: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/3.jpg)
3
“The most common miracle of software engineering is the transition from analysis to design and design to code.” --- Richard Due
![Page 4: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/4.jpg)
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
![Page 5: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/5.jpg)
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
![Page 6: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/6.jpg)
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
http://www.sei.edu/architecture/definitions.html
![Page 7: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/7.jpg)
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
![Page 8: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/8.jpg)
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…
![Page 9: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/9.jpg)
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
![Page 10: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/10.jpg)
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)
![Page 11: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/11.jpg)
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
![Page 12: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/12.jpg)
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
![Page 13: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/13.jpg)
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
![Page 14: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/14.jpg)
14
Conceptual Model of Documenting Architecture
IEEE 1471-2000
![Page 15: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/15.jpg)
15
Stakeholders & Concerns
![Page 16: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/16.jpg)
16
Conceptual Model of Documenting Architecture
IEEE 1471-2000
![Page 17: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/17.jpg)
17
Representing Software Architecture: The 4+1 View Approach
Logical View
End-user Functionality
Implementation View
Programmers Configuration management
Process View
Performance Scalability Throughput
System integrators
Deployment View
System topology Communication
Provisioning
System engineering
Use Case View
![Page 18: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/18.jpg)
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
![Page 19: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/19.jpg)
19
Conceptual Model of Documenting Architecture
IEEE 1471-2000
![Page 20: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/20.jpg)
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)
![Page 21: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/21.jpg)
21
Architecture Metamodel
![Page 22: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/22.jpg)
22
Architecture metamodel
![Page 23: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/23.jpg)
23
Architecture Metamodel
![Page 24: Lecture 13 (Architecture)](https://reader031.vdocuments.us/reader031/viewer/2022012020/61688c65d394e9041f707966/html5/thumbnails/24.jpg)
24