SEng 5861 Introduction to Software Architecture

1
SEng 5861Introduction to Software Architecture

• Week 1September 6, 2008

2
Agenda

• Introductions
• Course Logistics and Syllabus
• Learning Objectives
• Group Project
• Individual Assignments
• What is software architecture? What is a
  software architect?
• A7E Example
• 50,000 View of the rest of the semester

3
Instructor

• Jeffrey M. Thompson, PhD
• Received Doctorate in 2002
• Principal Software Engineer Group Lead
• Worked at Boston Scientific for six years
• PMP Certified
• Major projects include introduction of product
  line engineering, replacement issue tracking and
  version management systems

4
Learning Objectives

• By the end of the course, students will
• Understand what software architecture is (and is
  not) and its relationship to other development
  artifacts
• Understand common tools and terminology related
  to software architecture
• Understand the role of the Software Architect
  with a development project

5
Additional Objectives??
6
Grading Overview
7
Group Project

• Re-Engineer the architecture of a medium sized,
  open source system
• Phase 1 Proposal Business Drivers
• Phase 2 Views Overview
• Phase 3 Architecture Analysis
• Phase 4 Architecture Evolution
• Each phase includes a report in-class
  presentation worth 15 of the course grade

8
Individual Assignments

• Two individual assignments
• Each worth 15 of the course grade

9
Participation

• Two components of participation
• Attendance
• Engagement
• Measured on a per-class basis
• Expect to do reasonably well on this part, unless
  you miss many classes and/or are silent the vast
  majority of the time

10
Grading

• Grading Rubrics
• Used on the group project phases
• Meant as a guide to what constitutes each level
• Not a set-in-stone list of requirements (items
  may be important that are not on the rubric)
• Executive Summaries
• Concise statement of the entire content of the
  document
• NOT an introduction or conclusion

11
Textbooks

• Software Architecture in Practice
• Good discussion of how architecture fits into
  everything else
• Without the stuff in here, youre not going to be
  successful
• Documenting Software Architectures
• Nice cookbook of notations and patterns
• Get the lingo down

12
Readings

• Youre heard it before, but
• Class generally builds on the readings, so please
  try to get to them before class
• Textbooks supplemented with research papers most
  weeks (try to read these as well)

13
But first

• A video

14
The Architecture Business Cycle
15
Stakeholders
Performance! Reliability!
Security! Behavior!
Extensibility! Maintainability!
New Features!
Faster! Compete!
End Users
Maintenance Organization
Marketing
Lower Cost!
Dont Keep Changing!
Deliver on Time!
Architect
Management Stakeholder
Customers
16
Trade-offs
Architect
Performance
Security
Maintainability
Reliability
Current Cost
Future Cost
17
Brainstorm

• What is a good definition ofSoftware
  Architecture?

18
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

19
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

20
Defines the Software Elements

• Abstraction of the system
• Omits some information
• Defines elements and relationships
• Relationships typically are interfaces
• Architecture talks about the public interfaces

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
Ramifications of Influences

• Almost never are the properties required by the
  business organizational goals consciously
  understood, let alone fully articulated.
• Architects need to know understand the nature,
  source, and priority of constraints on the
  project as early as possible.
• Architects must identify actively engage the
  stakeholders to solicit their needs
  expectations.
• Use architecture reviews iterative prototyping.

23
Why is Architecture Important?

• Communication among stakeholders
• Captures early design decisions
• Transferable abstraction of the system

24
Architecture Design Decisions

• Defines constraints on implementation
• Related to organizational structure
• Enables Quality attributes (e.g., performance,
  safety, security)
• Allows systems properties to be predicted
• Helps evolutionary prototyping
• Helps reason about change
• Cost and scheduling estimates

25
A Transferable, Reusable Model

• Software product lines
• Build using large, externally developed pieces
• Restrict vocabulary of design choices
• Permits template-based development

26
What makes a Good Architecture?

• No such thing as an inherently good or bad
  architecture.
• Architectures are more or less fit for some
  stated purpose.
• Architectures can be evaluated - one of the great
  benefits of paying attention to them - but only
  in the context of specific goals.
• Rules of Thumb process product (structural)
  recommendations

27
Structures and Views
From http//www.wordinfo.info/words/index/info/vi
ew_unit/1/?letterBspage3
28
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

29
Useful Concepts

• Three stages that capture characteristics of an
  architecture, on the way from box-and-arrow to
  full software architectures
• Architectural Patterns
• Reference Models
• Reference Architectures

Reference Model
ReferenceArchitecture
Software Architecture
ArchitecturalPattern
Figure 2.2
30
Architectural Patterns

• A description of element relation types
  together with a set of constraints on how they
  may be used.
• These constraints on an architecture define a set
  or family of architectures.
• For example, the client-server pattern has 2
  element types their relationship is a protocol
  that the server uses to communicate with each of
  its clients, the clients dont communicate
  directly.

31
Value of Patterns

• They exhibit known quality attributes, and are a
  reuse of experience.
• Some patterns solve performance problems, others
  apply to high-security systems, or
  high-availability goals.
• Often the architects first major design
  decision.
• Also referred to as architectural styles.

32
Reference Models

• A division of functionality together with data
  flow between the pieces.
• A standard decomposition of a known problem into
  parts that cooperatively solve the problem.
• They arise from experience, and are thus a
  characteristic of mature domains.
• For example, the standard parts of a compiler or
  database management system how they work
  together.

33
Reference Architectures

• A reference model mapped onto software elements
  and the data flows between them. The elements
  must cooperatively implement the functionality
  defined in the reference model.
• The mapping may be 1-1, but an element may
  implement a part of a function or several
  functions.

34
A7E Example
35
A7E Views

• Module
• Uses
• Process

36
50,000 ft Course Overview
37
Role of the Software Architect
Communicate!
Functional Requirements
Balance Quality Attributes
Bring Technology
Manage Complexity
Report Results
Balance Stakeholder Concerns
Architect
38
Quality Attributes
How are tradeoffs made? What patterns enable
certain properties?
Architect
What quality attributes are we interested in?
How are those attributes related?
39
Types of Views
Module
How to express each view. What is each view
useful for?
Runtime
Allocation
Architect
40
Integrating the Views
From http//www.wordinfo.info/words/index/info/vi
ew_unit/1/?letterBspage3
41
Analysis Methods
End Users
Maintenance Organization
Architect
Customers
Marketing
Management Stakeholder
42
Behavioral Modeling
43
Reuse
44
Group Project
45
Group Composition

• Using the same groups as for the Project
  Management class
• Groups of 4
• Please do not separate into a project
  management group of 2 and an architecture
  group of 2

46
Qualities of Systems

• Medium Sized (not large)
• Well documented expected to analyze the
  architecture, not just recover it
• Interesting!

47
Potential Examples

• dotProject
• OpenProj
• Mambo/Joomla CMS
• GIMP (image editor)
• Jira Selenium (OpenQA)

• Pidgin
• Druple
• Squid
• Audacity
• Mozilla applications framework

48
Ideas?