Moving Architectural Description from Under the Technology Lamppost Nenad Medvidovic Center for Systems & Software Engineering Viterbi School of Engineering.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Dif8901 April Modeling Software Architecture in the Unified Modeling Language (Medvidovic, et al. 2002)
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Domain-Specific Software Architecture and Product Lines Software.
Software Architectures and Embedded Systems Nenad Medvidovic with Sam Malek and Marija Mikic-Rakic Computer Science Department University of Southern California.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors.
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
Architecture Description Languages (ADLs). A Brief History of ADLs  Software architecture emerged as a research discipline in the early 1990s  Soon.
Moving Architectural Description from Under the Technology Lamppost Nenad Medvidovic University of Southern California Los Angeles, USA
Domain-Specific Software Engineering (DSSE). Software Engineering Concerns  There are many of them  “Classical” software architecture research has focused.
Domain-Specific Software Architecture and Product Lines
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7.
A Model-Driven Framework for Architectural Evaluation of Mobile Software Systems George Edwards Dr. Nenad Medvidovic Center.
1 Software Architecture: a Roadmap David Garlen Roshanak Roshandel Yulong Liu.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Iterative development and The Unified process
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Domain-Specific Software Architecture
Course Instructor: Aisha Azeem
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Domain-Specific Software Engineering Alex Adamec.
1 Ivano Malavolta, University of L’aquila, Computer Science Department Ivano Malavolta DUALLy: an Eclipse platform for architectural languages interoperability.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7.
Computer Systems & Architecture Lesson Software Product Lines.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Software Engineering Muhammad Fahad Khan
UML Unified Markup Language Ziya Karakaya Atılım University, Computer Engineering
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
An Introduction to Software Architecture
Designing a DSL for Information Systems Architecture
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
Chapter 6 - Modeling Eduardo Felipe Zecca da Cruz.
Henry Muccini - Computer Science Department, Universita' dell'Aquila, Italy Paola Inverardi - Computer Science Department, Universita'
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
DSL Classification October 21-22, 2007 Benoît Langlois / Thales-EPM Consuela-Elena Jitia / Eric Jouenne, Thales Research & Technology The 7th OOPSLA Workshop.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Christoph F. Eick University of Houston Organization 1. What are Ontologies? 2. What are they good for? 3. Ontologies and.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
CSCI 578 Software Architectures Exam #1 Review. Materials you are responsible for Chapters 1-8 in the text book All lecture material up to but not including.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Software Connectors Acknowledgement: slides mostly from Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic,
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors in Practice Software Architecture.
Session 1 What Is the UML? Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 5, 2011 Presented by Kang-Pyo Lee.
Architecture Description Languages (ADLs) Cf. Architecture Analysis and Design Languages.
George Edwards Computer Science Department Center for Systems and Software Engineering University of Southern California
CSCI 578 Software Architectures Exam #1 Review. Materials you are responsible for Chapters 1-7 in the text book All lecture material through intro to.
Software Architecture Lecture 3
CSCI 578 Software Architectures
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Software Architecture Lecture 3
Model-Driven Analysis Frameworks for Embedded Systems
Software Architecture Lecture 3
CSCI 578 Software Architectures
Architecture Description Languages
Software Architecture Lecture 3
Software Connectors.
An Introduction to Software Architecture
Software Architecture Lecture 3
Automated Analysis and Code Generation for Domain-Specific Models
Chapter 5 Architectural Design.
Software Architecture Lecture 3
UML Design for an Automated Registration System
CSCI 578 Software Architectures
Presentation transcript:

Moving Architectural Description from Under the Technology Lamppost Nenad Medvidovic Center for Systems & Software Engineering Viterbi School of Engineering University of Southern California October 24, 2006

2 A Brief History of ADLs  Software architecture emerged as a research discipline in the early 1990s  Soon thereafter, many notations were either invented, recast, and/or argued for as architecture description languages –Wright, UniCon, Aesop, Acme, Rapide, Darwin, SADL, C2, Weaves, CHAM, LILEAnna, MetaH, Demeter, UML 1.x, … –It seemed very important to have, or at least know, one  Each provided modeling capabilities geared at software design –Though not necessarily architecture!  They saw varying degrees of adoption and use

3 Enter the “Funny” Questions  Is UML really an ADL?  Is Statecharts an ADL?  What makes LILEAnna an ADL?  Is Demeter a software design philosophy or a language? And why is it an ADL?  Is Aesop an environment or an ADL?  Why is Rapide an ADL but its close cousin VHDL is not?  Aren’t C2 and Weaves architectural styles?  Why isn’t Java an ADL?

4 And the Most Important Question WWhat is an ADL?

5 Trying to Answer the Question  Conducted a study of ADLs in the late-1990s  Defined what an ADL is –Eliminated several candidate notations in the process  Suggested multiple dimensions for ADL understanding and classification  Provided a detailed comparison of ADLs  Expanded and updated the study several times

6 So, What Was the Answer?  An ADL is a language that provides features for modeling a software system’s conceptual architecture, distinguished from the system’s implementation.  An ADL must support the building blocks of an architectural description –Components  Interfaces –Connectors –Configurations

7 The Study in Retrospect – Benefits  Improved the understanding of ADLs  The two papers became a commonly accepted references in the SA community –After some grumbling, even the ADLs’ authors accepted that the study was ultimately unbiased  The definition became a “litmus test” for determining whether a particular notation is an ADL

8 The Study in Retrospect – Shortcomings  The “litmus test” was not always effective –It took a 3-year study and a 60-page paper to “prove” that UML 1.x is not an ADL –It took another 2-year study to demonstrate that, e.g., Darwin does, in fact, support (limited) connector modeling  Still did not answer the question of what “conceptual architecture” means  Did not provide any help with understanding deeper questions –What is a model? –What is architecture? –What are differences among styles, domain-specific architectures, application families, product lines, product populations… ?

9 Wanted answers Once and for all No Monetary Reward

10 Why Bother?  These questions have been personally “bugging” me  The discipline has matured enough to require them –Research –Practice –Pedagogy  One added, specific impetus

11 Why Bother?  These questions have been personally “bugging” me  The discipline has matured enough to require them –Research –Practice –Pedagogy  One added, specific impetus Software Architecture: Foundations, Theory, and Practice Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy (To appear, 2007)

12 What Happened to the ADLs?  The 1 st generation (“1G”) did not catch on –Although there are some 2G ADLs in use  Almost no broader adoption –(slight) Exceptions are MetaH, Weaves, and Rapide  What are some of the obvious reasons? –Often targeted at research environments –Awkward syntax and/or semantics –Modeling rigidity –Limited and idiosyncratic analysis support –Inadequate tool support –UML  Video killed the radio star…

13 A Deeper Reason  1G ADLs focused exclusively on technology –So did our study  The broader context was completely missing –Relation to system requirements –Constraints imposed by implementation platforms –Characteristics of application domains –Organizational structure and politics –Business model –Position in the marketplace –…

14 What’s Out There? Software Architecture

15 What’s Out There? Technology Software Architecture

16 What’s Out There? Technology Software Architecture Domain

17 What’s Out There? Technology Software Architecture Domain Business

18 Technology DomainBusiness The Three Lampposts (“3L”)  Excessive or exclusive focus on technology is a critical failing of early ADLs  3L provides the needed answer –Illuminates the space of ADLs appropriately –Provides the necessary broad perspective on ADLs and their role in product development –Helps to classify and evaluate ADLs –Explains ADLs’ successes and failures –Provides guidance for ADL developers  Different lamps can still “shine” at different intensities

19 Technology  Concerned with –Recurring technical challenges of engineering systems –Means for representing and reasoning about architectures –Critical abstractions and conceptual foundations of SA  Results in –Most all 1G ADLs –Focus on analysis  Often using pre-existing analytical formalisms –Esoteric discussions  Relative merits of declarative vs. imperative ADLs  ADL interoperability –And some important ones  How do we transform architectures into implementations Technology DomainBusiness

20 A Technology-Driven ADL Technology DomainBusiness

21 Domain  Concerned with –Exploiting domain characteristics to aid system development –Means for representing and reasoning about problems in a given domain  Results in –Successful 1G ADLs  MetaH, Weaves, GenVoca –Specialized, deeper solutions –Reusable assets  Including the architecture! –Engineers speaking the language of the users Technology DomainBusiness

22 Business  Concerned with –Capturing and exploiting knowledge of the business context –Core competencies –Processes –Costs  Includes valuation of assets  Results in –No 1G ADLs –Product strategy –Means for capturing multiple stakeholder perspectives –Characterization of desired product qualities  Tied to marketplace performance –What specifically, in an ADL?  Product relationships within a product line  Cost data per component Technology DomainBusiness

23 Technology + Domain  Concerned with –Technological concerns specific to a domain –System generation from models  Results in –Application-family architectures –Domain-specific languages Technology DomainBusiness Technology Domain

24 Technology + Business  Concerned with –Linking business issues with system construction –Investment in infrastructure  Winning “technology wars”  Results in –Relationship of process steps to software elements –CM systems –Architecture-centric cost estimation tools  COCOMO, COSYSMO, COCOTS Technology DomainBusiness Technology Business

25 Domain + Business  Concerned with –Core competencies  What you know how to do well and profitably  Results in –Domain models –Business models –Processes –Customer profiles and requirements –No technology! Technology DomainBusiness Domain Business

26 Technology + Domain + Business  Concerned with –Being a successful software development outfit  Results in –Software product lines Technology DomainBusiness Domain Business Technology

27 Putting It All Together Domain underlying knowledge, human needs, domain characteristics Business Finance, accounting, marketing, sales Technology Generic Tools, OTS apps, computing/communications infrastructure Core Competencies Application- Family Architecture Domain- Independent Infrastructure Idealized/context- non-specific knowledge and architecture, not shaped/driven/informed by business insights An organization’s domain-independent technical assets Domain expertise and knowledge that is not captured or implemented Domain-Specific Engineering Product-Line Architectures

28 2G ADLs  Only a handful of 1G ADLs have “stuck around”… –…but, boy, have they changed  They evolved into 2G ADLs –UML 2.0  UML 1.x –AADL  MetaH –Koala  Darwin  Conic –xADL 2.0  xADL 1.0  C2  All have strong technological foci –Yet they are very different from each other Technology DomainBusiness

29 UML 2.0  De facto standard software design language –Developed by OMG  A “Swiss Army Knife” of notations  Has a number of architectural constructs  Ubiquitous  Primary focus – to conquer the world

30 UML 2.0 in Action

31 UML 2.0 in Action

32 UML 2.0 in Action

33 UML 2.0 Under the Lampposts Software Architecture

34 UML 2.0 Under the Lampposts Software Architecture Domain Technology

35 UML 2.0 Under the Lampposts Software Architecture Technology Business

36 UML 2.0 Under the Lampposts Software Architecture Technology Business Domain Business

37 AADL  Architecture Analysis and Design Language –Initially stood for “Avionics ADL”  Primarily textual  Very detailed –An AADL component runs on a processor, which runs one or more processes, each of which contains one or more threads of control, all of which can receive instructions through in ports and send data through out ports over a bus…  Primary focus – embedded, real-time, hybrid systems

38 AADL in Action system implementation sensor_type.temperature subcomponents the_sensor_processor : processor sensor_processor_type; the_sensor_process : process sensor_process_type.one_thread; connections bus access network -> the_sensor_processor.network; event data port sensed -> the_sensor_process.sensed; event data port control -> the_sensor_process.control; properties Actual_Processor_Binding => reference the_sensor_processor applies to the_sensor_process; end sensor_type.temperature;

39 AADL Under the Lampposts Software Architecture

40 AADL Under the Lampposts Software Architecture Domain Technology

41 AADL Under the Lampposts Software Architecture Domain Technology

42 AADL Under the Lampposts Software Architecture Domain Technology Business

43 Koala  Developed at Philips –In collaboration with Imperial College London  Used in the consumer electronics domain  Both graphical and textual  Primary focus – management of product populations –Modeling –Analysis –Implementation generation –Deployment

44 Koala in Action

45 Koala in Action

46 Koala Under the Lampposts Software Architecture

47 Koala Under the Lampposts Software Architecture Domain Technology

48 Koala Under the Lampposts Software Architecture Technology Business

49 Koala Under the Lampposts Software Architecture Domain Technology Business

50 xADL 2.0  Developed at UC Irvine –In use at Boeing  XML substrate  Both graphical and textual  Primary focus – extensibility

51 xADL 2.0 in Action

52 xADL 2.0 in Action Database SQL in Oracle Corp. db.example.com:1234/db1 webUser secret

53 xADL 2.0 Under the Lampposts Software Architecture

54 xADL 2.0 Under the Lampposts Software Architecture Domain Technology

55 xADL 2.0 Under the Lampposts Software Architecture Technology Business

56 xADL 2.0 Under the Lampposts Software Architecture Technology Domain Business

57 2G ADLs Side-by-Side UML 2.0 AADL xADL 2.0 Koala

58 Some Observations  Architecture embraces many concerns  More mature and successful ADLs incorporate concerns from 3L  Multiple views are a must  No single set of modeling features is sufficient for every project  Extensibility is a key property of ADLs  Tools are often as important as notations

59 Questions