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