Software Architecting Using Goals Scenarios Patterns and Objects

Software Architecting Using Goals, Scenarios, Patterns and Objects Lawrence Chung The University of Texas at Dallas

Software Architecture: Why? • Historical Perspective – 1994 – A Panel Session on Software Architecture at ICSE – 1995 – 1 st Int. Workshop on Software Architecture – 1999 – 1 st IFIP Working Conf. on Software Architecture – … – And, Bill Gates = a chief software architect – And, a software architect = a high-paying position –…

Software Architecture: What? • • The underlying structure of things Project blue print High level abstraction of software system solution Architectural Constituents § Components – Process, Data, Control, Resource, etc. – what, how many § Connections – explicit, implicit, #param, …, RPC, Messages, MOMs, etc. – what, how many § Constraints – dependencies among components, (de-)activation conditions, etc. , § Patterns – structural, behavioral, etc. § Styles – OO, Imp. Invocation, Pipe&Filter, … § Rational § Infrastructure

Software Architecture: How? • Current Practice: – Model Functional Requirements – Develop Architecture to meet Functional Reqs Dominant technique = UML-Rational Rose (In research: ADLs – Rapide, SCR, SPIN, …) • Needed Practice: – Model Functional Requirements – Model Non-Functional Requirements – Systematically Develop Architecture – Reuse (Design) Patterns

The GSPO Framework • Develop scenarios • Model Functional Requirements: UML • Model Non-Functional Requirements as Softgoals: The NFR Framework • Develop Macro-architecture • Develop Micro-architecture using design patterns

Presence & Instant Messaging System (PIMS)

Scenarios for PIMS • Interactions between system and user • Help elicitation, validatation, and veriffication • Use cases, episodes, and scripts Activate Deactivate Messaging Service Message Transmission Send message Receive message PIMS Presence Service Change Presence Info Transmission Enable Disable Fetch Autonomous notification Subscribe Unsubscribe Status Change Detection Presence Notification

Functional Requirement for PIMS § Use case diagram as part of the FRs § Important use cases from the scenario graph Send Message Change Presence User Fetch Subscribe Unsubscribe

Non-Functional Requirements for PIMS § NFRs as softgoals (clouds) – priority type [topic] (or type [topic 1, topic 2, …]) § AND/OR decompositions § Softgoal Interdependency graph (SIG)

Integrating FRs and NFRs § Use topic as the “anchor”: type [topic] (or type [topic 1, topic 2, …]) § Indirect linking thru scenario graph § Refine as needed

Operationalization Using Macro-Architectures § Identify tasks to realize use cases § Identify architectural alternatives (operationalizing softgoals) to realize the tasks § Choose ones that best satisfice the (refined) softgoals

Operationalization Using Micro-Architectures of Design Patterns § Identify design patterns (operationalizing softgoals) to safisfice architectural constituents § establish relationships among design patterns

Architectural Composition § Identify overlapping objects § establish relationships among non-overlapping objects

Sequence Diagram § Identify interactions among objects (& software agents) UAInterface Watch. . . Presence. Service Entity. Factory Presentity. Proxy Entity(Presentity)Subscriber. Proxy Entity(Subscriber) Presence. . . 1: change. Status 1. 1. 1: find. Presentity 1. 1: <create> 1. 1. 2: change. Status 1. 1. 2. 1: change. Status 1. 1. 2. 2: update 1. 1. 2. 2. 1. 1: get. State 1. 1. 2. 2. 1. 2: notify. State. Change 1. 2: notify. Status. Change

Conclusions • Contributions – Methodology for architecting “good-enough” software architecture • From OO to GO • From Use case to Scenaria • Both Macro- and Micro-architecture • Future Work – Knowledge base of patterns & CASE tool – More empirical/case studies