From Use Cases to Implementation

Slides:



Advertisements
Similar presentations
Object-Oriented Software Engineering Visual OO Analysis and Design
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
By Philippe Kruchten Rational Software
Outline About author. The problem that discussed in the article.
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
Introduction To System Analysis and Design
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
© Copyright Eliyahu Brutman Programming Techniques Course.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
What is Software Architecture?
Introduction To System Analysis and design
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
Rational Unified Process Fundamentals Module 4: Disciplines II.
An Introduction to Software Architecture
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
Architecting Web Services Unit – II – PART - III.
Introduction To System Analysis and Design
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
1 Introduction to Software Engineering Lecture 1.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Introduction to OOAD & Rational Rose cyt. 2 Outline RUP OOAD Rational Rose.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
310414IMPLEMENTATION1 IMPLEMENTATIONIMPLEMENTATION SOFTWARE ENGINEERING SOFTWARE ENGINEERING.
4+1 View Model of Software Architecture
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
Fall 2007 Week 9: UML Overview MSIS 670: Object-Oriented Software Engineering.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Introduction to OOAD and UML
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Design Concepts ch-8
Design Patterns: MORE Examples
Software Architecture
Classifications of Software Requirements
Chapter 1: Introduction to Systems Analysis and Design
Course Outcomes of Object Oriented Modeling Design (17630,C604)
John D. McGregor Session 9 Testing Vocabulary
Architecting Web Services
Department of Computer Science
Systems Analysis and Design With UML 2
Introduction to Design Patterns
Unified Modeling Language
Software Architecture
Architecting Web Services
OO Methodology OO Architecture.
Recall The Team Skills Analyzing the Problem (with 5 steps)
Rational Unified Process
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Unified Modeling Language
University of Houston-Clear Lake
Object oriented analysis and design
Chapter 0 : Introduction to Object Oriented Design
Analysis models and design models
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
4+1 View Model of Software Architecture
4+1 View Model of Software Architecture
Applying Use Cases (Chapters 25,26)
Team Skill 6 - Building The Right System Part 1: Applying Use Cases
Applying Use Cases (Chapters 25,26)
Design Yaodong Bi.
Chapter 1: Introduction to Systems Analysis and Design
Segments Introduction: slides minutes
UML Design for an Automated Registration System
Software Architecture
Presentation transcript:

From Use Cases to Implementation

Mapping Requirements Directly to Design and Code For many, if not most, of our requirements it is relatively easy to follow them into design and then into code. E.g., “Only users with a valid password can access the system.” For these requirements it is also easy to use the statement of the requirement as a basis for testing. For some requirements, however, this is not quite so easy. E.g., “The system shall provide ½ second response time for all trivial user requests.”

Orthogonality between Requirements and Design The form of the requirements and the form of the design and implementation are different. There is no one-to-one mapping that makes implementation and validation easier.

The Orthogonality Problem Requirements speak about real-world items, but code speaks about stacks, queues, and algorithms. These are different languages. Certain requirements, e.g., performance, have little to do with the logical structure of the code but lots to do with the process structure, or how the various pieces of the code interact, how fast a particular piece of code runs, how often we get interrupted in a given module, etc.

The Orthogonality Problem (Cont’d) Other functional requirements require that a number of system elements interact to achieve the functionality. The implementation might be distributed throughout the code. Good system design is not driven by the ease of mapping requirements into design but by other factors, such as, optimizing the use of scarce resources, reusing architectural patterns, designs or code, or utilizing purchased components.

Object Orientation Object oriented technology has helped to reduce the magnitude of the orthogonality problem through the use of abstraction, information hiding, inheritance, etc. OO technology encourages designs which match the real world descriptions of the problem. However, if carried too far a functionally oriented design might result rather than one that is object oriented.

The Use Case as a Requirement If the granularity of requirements is too small it may be difficult to look at system behavior as a whole to see that it does all the right things in the right order. Properly written use cases which provide sequences of actions between the system and the user help with this problem. In this way use cases help with the design process.

Modeling Software Systems Today’s nontrivial software systems are extraordinarily complex undertakings. To deal with the complexity, a useful technique is to abstract the system into a simple model to allow us to think about the system without having to deal with the details. Many different aspects of a system can be modeled. Each contributes to our understanding of one aspect and taken together they allow us to consider the system architecture as a whole.

The Architecture of Software Systems According to Shaw and Garlan [1996], software architecture involves the Description of elements from which systems are built, interactions amongst those elements, patterns that guide their composition, and constraints on those patterns. We use architecture to help us: Understand what the system does Understand how the system works Think and work on pieces of the system Extend the system Reuse part(s) of the system to build another one

The Architecture of Software Systems (Cont’d) Architecture is the tool by which decisions are made about what and how the system will be built. Dominant architectures, used for previous similar problems, can help kick start the process. Different groups of stakeholders may require different views of the architectural model showing their different perspectives.

The “4+1” View of Architecture Programmer Software management End User Functionality Logical View Implementation View Use-case View Designers/Testers Behavior Process View Deployment View System Integrators Performance Scalability Throughput System Engineering System topology Delivery, installation Communication

The “4+1” View of Architecture (Cont’d) The logical view addresses the functionality of the system. It represents the logical structure of the system in terms of subsystems and classes. The implementation view describes a static view of the bits and pieces that are relevant to the implementation of the system: source code, libraries, object classes, etc.

The “4+1” View of Architecture (Cont’d) The process view(s) describe operations of the system and are particularly useful for systems which have parallel tasks, interfaces with other systems, etc. The deployment view allocates the implementation elements to the supporting infrastructure, such as operating systems and computing platforms

The “4+1” View of Architecture (Cont’d) The use-case view presents key use cases of the use-case model, drives the design, and ties all the various views of the architecture together

Realizing Use Cases in the Design Model Use cases are realized via collaborations, which are societies of classes, interfaces, subsystems, or other elements that cooperate to achieve some behavior. It is within the collaborations that you see the systematic and aggregate behavioral aspects of the system.

Realizing Use Cases in the Design Model Use-case Model Design Model <<trace>> Use case Collaboration Participating classes

Structural and Behavioral Aspects of Collaborations The two aspects of collaborations are: Structural – which defines the static structure of the system (the classes, elements, interfaces, and subsystems) Behavioral – which specifies the dynamics of how the elements interact to accomplish the result. Class diagrams can be used to model the structural aspects and sequence diagrams can model the behavior.

Using Collaborations to Realize Sets of Individual Requirements Even when requirements are not expressed as use cases, this approach can be used to model the mapping between requirements and the design. Nonfunctional requirements such as safety or performance can be modeled this way as well.

Model of Requirements Implementation as a Collaboration - The clocks shall . . . Every 24 hours . . . - Synchronization occurs . . . Design Model Sync Clock <<trace>> Collaboration Participating classes

From Design to Implementation By modeling the system this way we can assure that the significant use cases and requirements are realized in the design model. This helps to ensure that the software design conforms to the requirements (i.e., a major step toward design verification). The next step is to refine the design in an iterative process that eventually leads to the implementation of the software. (NOT EASY!)