67
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/ soen6011-f2007.html

SOEN 6011 Software Engineering Processes

  • Upload
    arnav

  • View
    66

  • Download
    3

Embed Size (px)

DESCRIPTION

SOEN 6011 Software Engineering Processes. Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html. Week 11. Software Architecture 4+1 Views Siemen’s Approach. Software Architecture: Definitions. - PowerPoint PPT Presentation

Citation preview

Page 1: SOEN 6011 Software Engineering Processes

SOEN 6011Software Engineering Processes

Section SS Fall 2007Dr Greg Butler

http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

Page 2: SOEN 6011 Software Engineering Processes

Week 11• Software Architecture

• 4+1 Views

• Siemen’s Approach

Page 3: SOEN 6011 Software Engineering Processes

Software Architecture: Definitions

• … for a system is the structure … which consist of elements, their externally visible properties, and the relationships among them.

• The fundamental organization of a system [as] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471-2000).

Page 4: SOEN 6011 Software Engineering Processes

Architecture: Benefits?

• Contributes to elicitation of requirements.• First design: can already assess / determine

– satisfaction of requirements.– Work allocation / distribution (schedule).

• Instructional: useful to learn about system.– Initial development & maintenance.

• Reuse of the architectural style / framework.• Also …

Page 5: SOEN 6011 Software Engineering Processes

Conceptual Integrity …

• … is central to achieving product quality.• Also called Architectural Integrity.• Coherent conceptual (design) model

makes product easier to understand, hence easier to …– Develop (e.g. Design, test),– Learn to use: customer, I&C, sales & marketing– Maintain.

• How to achieve conceptual integrity? …

Page 6: SOEN 6011 Software Engineering Processes

System Architect

• Custodian of product ensures– Design coherence.– Also, to some extent, Interface coherence (esp.

UI).

Page 7: SOEN 6011 Software Engineering Processes

System Architect

• Full-time job!– Separation of architecture from

implementation.• Project size hierarchy of architects.• “Single mind”• Having a system architect is an effective

means of achieving conceptual integrity.

Page 8: SOEN 6011 Software Engineering Processes

Components

• S/W entities …– Systems (e.g. COTS), subsystems, frameworks,

packages, layers, libraries, modules, classes, objects, executables, DLLs, plug-ins, …

– Processes, tasks.• Physical

– Network elements.– Processing elements.– Databases.

Page 9: SOEN 6011 Software Engineering Processes

Interrelationships

• Static:– Interface dependencies: e.g. uses/import.– Containment, inheritance, subtype, …– Data dependencies (database applications).– …

• Dynamic:– Thread of control.– Dataflow.– …

Page 10: SOEN 6011 Software Engineering Processes

Documentation: Putting it all together

• How best to capture all of these different kinds of components and their interrelationships?

• Consider …

Page 11: SOEN 6011 Software Engineering Processes

View Based Documentation of Architectures

• Architecture Document =View A +View B +View C + …View X +“Beyond Views”

Page 12: SOEN 6011 Software Engineering Processes

“4+1” View Model of Architecture

• By Philippe Kruchten [Kruchten95](URL to paper given on web site.)

• Rational Unified Process.

Page 13: SOEN 6011 Software Engineering Processes

“4+1” View Model

Deployment/

Implementation/

Page 14: SOEN 6011 Software Engineering Processes

References• Kruchten95, becoming a bit dated.• RUP documentation

– Available in lab.– Also includes samples.

• To access RUP from lab machines– Launch the Rational Unified Process.

• From the Overview page …• Select Analysis and Design• At the top of this page select “Artifacts”• Select “Software Architecture Documents”• You will see links to the examples … . Note that I do not

consider the examples complete.

Page 15: SOEN 6011 Software Engineering Processes

“4+1” VM (Alternate names)

Page 16: SOEN 6011 Software Engineering Processes

“5+1” View Model

• = 4 + 1 + data view.• Other combinations of views are possible.

Page 17: SOEN 6011 Software Engineering Processes

“4+1”: Let us look at each view

Deployment/

Implementation/

Page 18: SOEN 6011 Software Engineering Processes

• Main goal: present architecturally significant use cases either:– Duplicated from req. doc. – Named and reference given to req. doc.

• These use cases are to help highlight main– Architectural decisions / choices

Use Case View

Page 19: SOEN 6011 Software Engineering Processes

Logical View: Main Goals

• Convey …– Overall structure and – Interfaces to the environment, in a manner

that is– conceptually as simple as possible

• Challenge: find right level of detail.

Page 20: SOEN 6011 Software Engineering Processes

Logical View & Requirements

• Main focus: functional.• It should be possible to assess (up to a

certain level of detail) whether requirements will be satisfied by the proposed architectural design.

Page 21: SOEN 6011 Software Engineering Processes

Logical View: Components & …

• Components:– active classes, classes, – modules, – packages, – subsystems, …

• Connectors (interrelationships):– Usage.– Containment, aggregation.– Inheritance, instantiation.

Page 22: SOEN 6011 Software Engineering Processes

Logical View: How Presented?

• Mainly UML “class” diagrams, including– Package diagrams.– Component structure (UML2)

• Explanatory text, including design rational

Page 23: SOEN 6011 Software Engineering Processes

Logical View, Example

• You have seen many examples of class and package diagrams.

• UML 2 component diagrams you have seen as well …

Page 24: SOEN 6011 Software Engineering Processes

Logical View (e.g. Kruchten)

Page 25: SOEN 6011 Software Engineering Processes

Process View

• Components: processes, tasks, …– group of tasks : single exec. unit.– Control: start, shutdown, recover, restore– Primary / secondary (redundancy)

• Interrelationships:– Communication

• Allocation of – Logical view components to processes/tasks.

• Synchronization mechanisms

Page 26: SOEN 6011 Software Engineering Processes

Process View – e.g. (Kruchten)

Page 27: SOEN 6011 Software Engineering Processes

Process View – ex.Logical View

Components

Page 28: SOEN 6011 Software Engineering Processes

Implementation (Development)View

• Actual S/W organization.• Components:

– Libraries, subsystems, exec., object files, …– Most common top-level arch. style: layers

• Connectors: containment, dependencies, …• Allocate logical components to impl. comp.• Reuse:

– Off-the-shelf.– “To-the-shelf”: sharing with other projects.

Page 29: SOEN 6011 Software Engineering Processes

Implementation View – illustration

Page 30: SOEN 6011 Software Engineering Processes

Deployment (Physical) View

• Components: processors, processing nodes, …• Network topology.

– Usually several topo’s are supported.– S/W should be relatively independent of topo.

• Allocation of process view elements to H/W (processing nodes).

• Examples:– Network elt: Process mapping into application cards.– Network Mgmt: one or more NOCs.

Page 31: SOEN 6011 Software Engineering Processes

Deployment View - illustration

Page 32: SOEN 6011 Software Engineering Processes

Deployment View - illustration

Page 33: SOEN 6011 Software Engineering Processes

Siemens Four View Model

• Reference:Applied Software Architecture by C. Hofmeister, R. Nord and D. Soni.

Page 34: SOEN 6011 Software Engineering Processes

Conceptual View

Module View

Code View

Execu-tion

View

Source Code

H/WArch.

Siemens Four View Model: Overview

S/W Architecture

Page 35: SOEN 6011 Software Engineering Processes

Comparing the View Models

4+1• Logical• Implementation

(Development)

• Process• Deployment (Physical)

• (Use Case)

S4VM• Conceptual• Module• Execution• Code

Page 36: SOEN 6011 Software Engineering Processes

S4VM OverviewS4VM: in more detail. Notice activity

groups in each view are the same …

Page 37: SOEN 6011 Software Engineering Processes

S4VM Activities Groups in each view

• For each view perform– Global analysis

(Mostly the same for each view.)– Central design tasks.

(Specific to each view.)– Final design tasks.

(Specific to each view.)

Page 38: SOEN 6011 Software Engineering Processes

Overview

Page 39: SOEN 6011 Software Engineering Processes

Global Analysis: Purpose

• To identify issues (early) so that strategies can be proposed to resolve them.

• (Architectural) Factors can be seen merely as a means of organizing (group) issues.

Page 40: SOEN 6011 Software Engineering Processes

Global Analysis

Activities:1. Analyze Factors.2. Identify Issues.3. Develop Strategies.

Page 41: SOEN 6011 Software Engineering Processes

1. Analyze Factors - purpose

• Identify and describe factors that can influence the system architecture.

• Document the factors.

Page 42: SOEN 6011 Software Engineering Processes

1. Analyze Factors

• Use given factor categorization / list to kickoff.

• For each factor consider:– How it relates to the project.– Flexibility and changeability.– Impact.

Page 43: SOEN 6011 Software Engineering Processes

Factor Categorization (e.g. SFVM)

• Organizational• Technological• Product

Page 44: SOEN 6011 Software Engineering Processes

Organizational Factors

Top-level grouping of factors:• O1: Management• O2: Staff skills, interests, strengths,

weaknesses.• O3: Process and development

environment.• O4: Development schedule.• O5: Development budget.

Page 45: SOEN 6011 Software Engineering Processes

O1: Management, further refined …

• Build vs. buy.• Schedule vs. functionality.• Environment.• Business goals.

Page 46: SOEN 6011 Software Engineering Processes

Ex. Project Factor Analysis Output

O1: Management• O1.1: Build vs. buy

There is a mild preference to build.– Flexibility & changeability: organization will consider

buy if justified.– Impact: moderate impact on meeting schedule.

• O1.2: Schedule vs. functionalityPreference for meeting schedule over some features…– Flex.&chng: negotiable for some features …– …

Page 47: SOEN 6011 Software Engineering Processes

Technological Factors

• T1: General-purpose hardware– E.g. processors, memory, network, disk, …

• T2: Domain-specific hardware• T3: Software technology

– E.g. OS, UI, prog. lang., design patterns, …• T4: Architecture technology

– E.g. arch. Styles, patterns, frameworks.• T5: Standards

Page 48: SOEN 6011 Software Engineering Processes

Product Factors

• P1: Functional features• P2: User interface• P3: Performance• P4: Dependability• P5: Failure detection, reporting, recover• P6: Service• P7: Product Cost

Page 49: SOEN 6011 Software Engineering Processes

What is an Issue?

• A (potential) problem.

Page 50: SOEN 6011 Software Engineering Processes

2. Identify Issues

• Key issues influencing architectural design which are to be resolved.

• Consider influencing factors.

Page 51: SOEN 6011 Software Engineering Processes

Issue: Skill Deficiencies

• Influencing factors:O2: Staff skills– O2.3 (Experience with multithreading): only

one developer has multithreading experience.– O2.4 (Experience with multiprocessor

systems): only two developers …

Page 52: SOEN 6011 Software Engineering Processes

3. Develop Strategies

What is a strategy?

Page 53: SOEN 6011 Software Engineering Processes

What is a Strategy?

• A means by which one or more issues are to be resolved, partially or totally.

Page 54: SOEN 6011 Software Engineering Processes

3. Develop Strategies

• For each issue:– Develop strategies to address issue.– Identify related strategies.

Page 55: SOEN 6011 Software Engineering Processes

Ex. Issue: Changes in Hardware

• Changes in both general-purpose and domain-specific hardware are anticipated on a regular basis. The challenge is to reduce the effort and time involved in adapting the product to the new hardware.

• Influencing factors: T1 (General-purpose H/W), T2 (Domain-specific H/W).

• Solutions: … ?

Page 56: SOEN 6011 Software Engineering Processes

Ex. Strategies

• Encapsulate hardware

Page 57: SOEN 6011 Software Engineering Processes

S4VM: Conceptual View

Page 58: SOEN 6011 Software Engineering Processes

Conceptual View – Documentation

• Structure– Configurations of:

components, connectors, ports, roles, protocols.

• Behavior– State diagrams.– Sequence diagrams.– Natural language.

Page 59: SOEN 6011 Software Engineering Processes

Conceptual View – Activities

• Global analysis.• Central design tasks.• Final design task.

Page 60: SOEN 6011 Software Engineering Processes

Conceptual V.: Central Design Tasks

• Create conceptual– Components, – Connectors (and ports, roles, protocols)– Configuration.

• Global evaluation

Page 61: SOEN 6011 Software Engineering Processes

Conceptual V.: Final Design Tasks

• Resource budgeting– Resources used by the software, but – Resources themselves can be H/W or S/W.

• Examples of resources include:– Memory, – CPU time,– Bandwidth,– … .

Page 62: SOEN 6011 Software Engineering Processes

Global Evaluation

• Evaluate design decisions– Continually, relative to results of global

analysis.– Periodically, w.r.t. interactions among

themselves.• During central design tasks.

Page 63: SOEN 6011 Software Engineering Processes

Module View – Activities

• What is the top level grouping of activities?

Page 64: SOEN 6011 Software Engineering Processes

Module View – Activities

• Global analysis.• Central design tasks.• Final design task.

Page 65: SOEN 6011 Software Engineering Processes

Module View, Central Design Tasks

• Definition of– Subsystems.– Layers– Modules

• Allocation of conceptual elements to the above.

• Global evaluation.

Page 66: SOEN 6011 Software Engineering Processes

Module View, Final Design Tasks

• Design of (key) module interfaces– Operations:

• name, signature (return type, parameter type).– Behavior (via specification).

Page 67: SOEN 6011 Software Engineering Processes

What is a “Module”?

• You can think of this as a UML package.• Does not imply that code will be non OO.• In execution view, will eventually “hold”

either OO (classes,…) or non OO code.