lect-12-architecture

lect-12-architecture - 5/6/2011 Software architecture 2...

Info iconThis preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
5/6/2011 1 CSE503: SOFTWARE ENGINEERING SOFTWARE ARCHITECTURE David Notkin Spring 2011 Software architecture Software architecture: design-based Formal reasoning about properties Static vs. dynamic architectures Software architecture: property-based Autonomic systems Relationship to model-based design 503 11sp © UW CSE • D. Notkin 2 Two categories: very soft distinction Software architecture: design-oriented Based in software design, in defining taxonomies based on experience, etc. Software architecture: property-oriented Based on a desire to design software systems with a particular property – such as autonomic systems, fault- tolerance, privacy, etc. 503 11sp © UW CSE • D. Notkin 3 Design-based software architecture Two primary goals Capturing, cataloguing and exploiting experience in software designs Allowing reasoning about classes of designs Composition of components and connectors Components are the core computational entities Connectors are the core ways in which components communicate and interact Under constraints – only some combinations are permitted, which is intended to allow demonstration of the presence or absence of key properties 503 11sp © UW CSE • D. Notkin 4
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
5/6/2011 2 Describing architectures There are, roughly, two approaches to describing software architectures The first – and the most heavily explored – is to define an ADL – architecture description language The second is to extend a programming language with architectural constructs 503 11sp © UW CSE • D. Notkin 5 Partial Comparison ADL Can focus on architectural issues Can allow architecture-related analysis Separates architectural activities from lower-level activities X Separates architecture from software, allowing drift X Requires additional learning and experience by developers, testers, etc. Extend PL Provides transition to adopt architecture for existing systems Connects architecture with program, reducing drift Incremental cost to train developers, testers, etc. X Fuzzier distinction between architecture and program X May constrain possible analyses First generation ADLs ACME (CMU/USC) Rapide (Stanford) Wright (CMU) Unicon (CMU) Aesop (CMU) MetaH (Honeywell) C2 SADL (UCI) SADL (SRI) Lileanna UML Modechart From 1999 MCC report Much of the following material is adapted from that report Second generation ADLs Changes from MCC list with respect to Wikipedia‘s list (1/9/2010) Added LePUS3 and Class-Z (University of Essex) ABACUS (UTS) AADL (SAE) - Architecture Analysis & Design Language Removed: UML Modechart 503 11sp © UW CSE • D. Notkin 8
Background image of page 2
5/6/2011 3 ADL +/-‘s Positives Formal representation of architecture Higher level system description than previously possible Permit analysis of architectures – completeness, consistency, ambiguity, and performance Can support automatic generation of software systems Negatives
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 20

lect-12-architecture - 5/6/2011 Software architecture 2...

This preview shows document pages 1 - 4. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online