software architecture completeness analysis l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Architecture Completeness Analysis PowerPoint Presentation
Download Presentation
Software Architecture Completeness Analysis

Loading in 2 Seconds...

play fullscreen
1 / 26

Software Architecture Completeness Analysis - PowerPoint PPT Presentation


  • 429 Views
  • Uploaded on

TU / e Software Architecture Completeness Analysis Interim Presentation Christian Lange Overview TU / e Introduction Software Architecture Analysis Survey Completeness Rules & Metrics Outlook Questions Introduction TU / e “Technische Informatica” TUE since 1998

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Architecture Completeness Analysis' - Mercy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software architecture completeness analysis

TU/e

Software Architecture Completeness Analysis

Interim Presentation

Christian Lange

overview
Overview

TU/e

  • Introduction
  • Software Architecture Analysis
  • Survey
  • Completeness
  • Rules & Metrics
  • Outlook
  • Questions
introduction
Introduction

TU/e

  • “Technische Informatica” TUE since 1998
  • Since December 2002 final year project at Océ Technologies (Venlo)
    • Supervisor Michel Chaudron
    • Advisor Eric Dortmans (Océ)
    • Lou Somers
introduction4
Introduction

TU/e

  • Extension of SAAT
    • Software Architecture Analysis Tool (Johan Muskens)
  • Completeness of Architecture
    • Introduced by Océ architecture specialists
question goal
Question / Goal

TU/e

  • What is

Software Architecture Completeness ?

  • Development of techniques
    • to assess a model’s completeness
    • to identify “incomplete spots”
    • (tool supported)
  • Validation of techniques in practice
sw architecture
SW Architecture

TU/e

  • 4+1 Views of Philippe Kruchten
sw architecture analysis
SW Architecture Analysis

TU/e

  • Maintainability, Extensibility, Testability,…
    • SAAM, ATAM
      • Specialist work, qualitative
    • Metrics, SAAT, other tools
      • Cohesion, coupling
      • Automated support
      • Quantitative
  • Completeness, Consistency
    • This project
      • Automated support
      • Quantitative

Existing

New

survey
Survey

TU/e

  • Web-based survey
    • To get insight in the way practitioners are using the UML for architecture
    • To investigate practitioners

needs

    • To get feedback on the

ideas so far

  • Published
    • In newsgroups
    • Within Océ
    • Sent to known experts
  • 20 questions (multiple choice, comments possible)
  • 2 month, 80 responses (20 Océ, 30 CGEY, 30 other)
  • Aimed audience
survey conclusions
Survey conclusions

TU/e

  • To what degree do you follow the UML standard?
survey conclusions10
Survey conclusions

TU/e

  • What criteria do you use to stop modelling?

Project size

other survey conclusions
Other survey conclusions

TU/e

  • Logical and Scenario view mostly used
  • Most practitioners encountered incompleteness problems
  • Consistency is important
  • Metrics usage in early stage expected to be useful
  • Use of dedicated case tools (XMI export)
completeness
Completeness

TU/e

  • Intuition:
    • Has the maturity of the architecture model reached a level, such that we are ready to start implementing?
  • Definition:
    • An architecture model is complete if and only if it entirelydescribes and specifies the system that exactly fulfills all requirements and the model contains all necessary information that is needed to implement that desired model
completeness13
Completeness

TU/e

  • Decomposition

A model must necessarily reflect all functional requirements of the desired system

Tracing

Completeness

Syntax

Semantics

A model must reach a good "score" for the non-functional quality attributes

A model must be syntactically correct, i.e. it must be consistent with respect to different views and different levels of abstraction.

consistency
Consistency

TU/e

  • Dimensions of consistency
    • Differs from “completeness”

Views

Time

Abstraction level

meta model
Meta Model

TU/e

  • Logical View
    • Class diagram
      • Class interfaces
      • associations, dependencies, inheritance
    • State diagram
  • Scenario View
    • Message sequence charts
      • Objects, messages
    • Use Case diagrams
      • Use cases, Actors
      • associations, dependencies, inheritance, instantiations
meta model17
Meta Model

TU/e

Subset of Logical and Scenario View

rules metrics
Rules & Metrics

TU/e

  • Size of Use Case
rules metrics19
Rules & Metrics

TU/e

  • Dynamicity
rules metrics20
Rules & Metrics

TU/e

  • Examples (Rules, 18 so far)
    • Objects must have a name
    • Abstract classes should have abstract superclasses
    • Classes have at most one state diagram
    • Classes with a high dynamicity have a state diagram
  • Examples (Metrics, 20 so far)
    • (shown before)
the tool
The tool

TU/e

XMI representationof model

UML representationof model

Queries (rules & metrics)

HTML output

Database

outlook
Outlook

TU/e

  • Rules and metrics set
    • Dependencies
      •  Rule A   Rule B
      • #Scenarios = 0  NOT objects need name/type, dynamicity,…
    • Classification
      • abstraction level, phase
outlook23
Outlook

TU/e

  • Case studies for validation
    • Tool vendor examples, literature examples
      • Assumed to be complete
      • Fault injection
      • Small
    • Case studies evaluated by Johan
      • Various domains
      • Compare results
    • Real-world projects (Océ, …)
      • Large projects
      • Architects available for evaluation, discussion
      • Subsequent versions
      • Problem tracking data available
      • Implemented code available (e.g. compare design with reverse-engineered model)
ongoing case study
Ongoing case study

TU/e

  • Context
    • Controller, embedded system,
    • Printer / scanner
  • Size:
    • 103 Use cases
    • 135 classes
    • 109 scenarios
ongoing case study25
Ongoing case study

TU/e

  • Identified:
    • oversized use case
      • 14 scenarios vs. 1 - 5
      • 533 messages vs. 3 – 90
    • High level scenarios vs. low level logical view
      • Only actors in MSCs, messages without method relation
    • (wrong) interpretation of “Actor”
    • 1 god class vs. 97 empty classes
    • God class is abstract but subclass of non-abstract class