Software Architecture and Software Estimation | CSCI 597, Study notes of Computer Science

Download Software Architecture and Software Estimation | CSCI 597 and more Study notes Computer Science in PDF only on Docsity!

Center for Systems and Software Engineering^ Overview of SoftwareArchitecture andSoftware Estimation

Raffi Tikidjian Thomas Tan Joshua Garcia Vu Nguyen Daniel Popescu

Center for Systems and Software Engineering Outline

Overview of Software Engineering

Software Architecture

Software Estimation

Center for Systems and Software Engineering Why Software Engineering

Software is everywhere nowadays

Software production is difficult

Software construction is human-intensive - Software is malleable - Software is intangible - Software size and complexity are increasing, for example, Windows Vista: - has over 50 mil lines of code - 2000 software developers - 5 years of development

Center for Systems and Software Engineering Software Architecture

Architecture is a set of principal design decisions about a softwaresystem

Three fundamental understandings of software architecture

Every application has an architecture

Every application has at least one architect

Architecture is not a phase of development

Center for Systems and Software Engineering Architecture Compliance Checking ‰

Architecture compliance is the degree to which the implementedarchitecture conforms to the planned architecture

Late architecture evaluation (i.e., after the implementation)

Dynamic compliance checking

With run-time traces - Addressing behavioral architectural views

Static compliance checking

Without executing the source code - Addressing structural architectural views

Center for Systems and Software Engineering Static Architecture Compliance Checking Approaches(1)

Extraction of relevant facts from source code

Structural elements (e.g., in Java: packages, classes,methods)

Dependencies among the structural elements(e.g., in C: includes, function calls, variable accesses)

Aggregation of facts about a system in arepository/fact base and abstraction tocomponents

Center for Systems and Software Engineering Architecture Compliance Checking Approaches ‰ Three static architecture compliance checking approaches have been identified

Reflexion models

Relation conformance rules

Component access rules ‰ These approaches are a sound quality assurance instrument in architecturedevelopment

Benefits of each approach have been shown in several case studies

But

What are the commonalities, differences, advantages and drawbacks of eachapproach?

When choose approach A instead of approach

Center for Systems and Software Engineering Case Study - TSAFE ‰ TSAFE is a prototype of the Tactical Separation AssistedFlight Environment as specified by NASA Ames ResearchCenter

•^

TSAFE checks aircraft flights, predicts future trajectories, anddisplays results on a map

-^ TSAFE was turned into a testbed by Fraunhofer CenterMaryland (FC-MD) to be used for software technologyexperimentation ‰ We statically evaluated two variants (original prototype anda redesigned version) of TSAFE to illustrate the threeapproaches

•^

Architectural models, architectural rules, source code anddocumentation were available

-^ Architects and developers could be interviewed to obtain furtherinformation (if necessary)

Center for Systems and Software Engineering Principle of Reflexion Models

Center for Systems and Software Engineering Reflexion Model Example

TSAFE I – compliance checkingresults ‰ TSAFE I – intended subsystemdependencies

Center for Systems and Software Engineering Relation Conformance Rules ‰ A relation conformance rule defines an allowed or a forbidden relation betweentwo components ‰ A relation conformance rule contains a source component and a targetcomponent defined by regular expressions

The relation rule "A* must exist B*" defines that a relation must exist from components,which name starts with an A, to components having a name starting with B ‰ Relation conformance rules allow that leaf level components can be checked(ignoring their super components) ‰ One relation conformance rule can cover multiple relations of different, multiplecomponents

Center for Systems and Software Engineering Relation Conformance Rules – Compliance CheckingResults TSAFE II

TSAFE II – Conformance Rules

No classes but the ServerInterface class shall access classes in the client subsystem

No classes other than the ClientInterface class shall access classes form the server subsystem

Center for Systems and Software Engineering Component Access Rules – Compliance CheckingResults TSAFE II

TSAFE II – Access Rule

Only the ParserInterface class shall be accessedfrom any other component

Center for Systems and Software Engineering Static Architecture Compliance Checking ‰ Static architecture compliance checking are a sound instrument in architecturaldevelopment ‰ Demonstration of three approaches derived from practical experiences inindustrial and academic case studies

Reflexion models

Relation conformance rules

Component access rules