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
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
3
“The most common miracle of software engineering is the transition from analysis to design and design to code.” --- Richard Due
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
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
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
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
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…
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
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)
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
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
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
14
Conceptual Model of Documenting Architecture
IEEE 1471-2000
15
Stakeholders & Concerns
16
Conceptual Model of Documenting Architecture
IEEE 1471-2000
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
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
19
Conceptual Model of Documenting Architecture
IEEE 1471-2000
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)
21
Architecture Metamodel
22
Architecture metamodel
23
Architecture Metamodel
24