1 / 15

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

elden
Download Presentation

Software Architecting Using Goals, Scenarios, Patterns and Objects

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. Presence & Instant Messaging System (PIMS)

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

  8. 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

  9. Non-Functional Requirements for PIMS • NFRs as softgoals (clouds) – priority type [topic] (or type [topic1, topic2, …]) • AND/OR decompositions • Softgoal Interdependency graph (SIG)

  10. Integrating FRs and NFRs • Use topic as the “anchor”: type [topic] (or type [topic1, topic2, …]) • Indirect linking thru scenario graph • Refine as needed

  11. 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

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

  13. Architectural Composition • Identify overlapping objects • establish relationships among non-overlapping objects

  14. PresenceService EntityFactory PresentityProxy Entity(Presentity) SubscriberProxy UAInterface Entity(Subscriber) Watch... Presence... 1: changeStatus 1.1: changeStatus 1.1.1: findPresentity 1.1.1.1: <create> 1.1.2: changeStatus 1.1.2.1: changeStatus 1.1.2.2: update 1.1.2.2.1: update 1.1.2.2.1.1: getState 1.1.2.2.1.2: notifyStateChange 1.2: notifyStatusChange Sequence Diagram • Identify interactions among objects (& software agents)

  15. 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

More Related