Recall The Team Skills Analyzing the Problem (with 5 steps)

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,
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Outline About author. The problem that discussed in the article.
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
UML Static diagrams. Static View: UML Component Diagram Component diagrams show the organization and dependencies among software components. Component:
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
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.
Unified Modeling (Part I) Overview of UML & Modeling
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Process Activities. Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities.
Object Oriented Analysis and Design Using the UML
The Design Discipline.
UML - Development Process 1 Software Development Process Using UML (2)
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)
Systems Analysis and Design in a Changing World, 3rd Edition
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
1 Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder Needs (8-13) Team Skill 3.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
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.
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
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
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.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
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.
Software Architecture
UML Diagrams By Daniel Damaris Novarianto S..
Systems Analysis and Design With UML 2
Unified Modeling Language
Software Architecture
OO Methodology OO Architecture.
UML Diagrams Jung Woo.
Object-Orientated Analysis, Design and Programming
Software Design AITI GP John Paul Vergara.
UML dynamic Modeling (Behavior Diagram)
Software Architecture Lecture 2
Rational Unified Process
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Object oriented analysis and design
IMPORTANT NOTICE TO STUDENTS:
Analysis models and design models
Software Design Lecture : 14.
An Introduction to Software Architecture
Chapter 7 –Implementation Issues
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)
Software Architecture
Design Yaodong Bi.
Software Development Process Using UML Recap
From Use Cases to Implementation
Software Architecture
Presentation transcript:

Recall The Team Skills Analyzing the Problem (with 5 steps) Understanding User and Stakeholder Needs Defining the System Managing Scope Refining the System Definition Building the Right System

Building the Right System Ch 25. From Use Cases to Implementation Ch 26. From Use Cases to Test Cases Ch 27. Tracing Requirements Ch 28. Managing Change Ch 29. Assessing Requirements Quality in Iterative Development

Chapter 25 From Use Cases to Implementation The Orthogonality Problem Use Cases realization in the Design Model Collaboration From Design to Implementation

Mapping Requirements Directly to Design and Code

The Orthogonality Problem It's probably fairly straightforward to find, inspect, and validate the code that fulfills requirements such as "Support up to an eight-digit floating-point input parameter" However, things get a little trickier for requirements such as "The system shall handle up to 100,000 trades an hour"

The Orthogonality Problem There is little correlation between the requirement and the design and implementation; they are orthogonal, or nearly so. In other words, the form of our requirements and the form of our design and implementation are different. There is no one-to-one mapping to make implementation and validation easier.

Reasons of orthogonality problem Requirements speak of real-world item, while code speaks about stacks, queues, and algorithms. Some requirements (like non-functional req.s) have little to do with logical structure of code. Some functional req.s require other parts of the system to interact with. Good system design is more related to resources management, reusing code, and applying purchased components.

Avoiding Orthogonality problem By using object-orientation ..why? Reuse No changes in real world items implies no changes in code Abstraction and moving from classes to objects Classes collaboration

Architecture of Software Systems Software Architecture involves Description of elements from which the systems are built, interactions amongst those elements, patterns that guide their composition, and constraints on those patterns. (Shaw and Garlan, 1996) Why architecture? understand what the system does Understand how it works Think and work on pieces of the system Extend the system Reuse parts of the system to build another one

The “4+1” views of Architecture Different groups of stakeholders need to see the architecture from different views Kruchten (1995) “4+1” views: Logical view: the functionality of the system Implementation view: source codes, libraries, object classes, .. etc Process view: operations of the system and interfaces with others Deployment view: operating systems and platforms Use case view: ties all views together

The “4+1” views of Archtiecture End User Functionality Logical view Implementation view Programmer Software Management Use case view Designer/Tester Behavior Process view Deployment view System Engineering System topology Delivery, installation communication System Integrators Performance Scalability Throughput

HOLIS Case Study Logical view: describes the various classes and subsystems that implemented behavior Implementation view: describes the various code artifacts for HOLIS Process view: demonstrate how multitasking is done Deployment view: how HOLIS is distributed across CCU, Control switch, homeowner’s PCs.

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. A common UML stereotype, the use-case realization, is used for this purpose: A special form of collaboration, one that shows how the functionality of a specific use case is achieved in the design model. Symbolic representation of a collaboration Example

A Use-Case Realization in the Design Model

Structural and Behavioural Aspects of Collaborations Collaborations have two aspects: A structural part that specifies the static structure of the system (the classes, elements, interfaces, and subsystems on which the implementation is structured). A behavioral part that specifies the dynamics of how the elements interact to accomplish the result.

Structural and Behavioural Aspects of Collaborations A class diagram represents the structural aspects, whereas an interaction diagram (sequence or collaboration) represents the behavioural aspects.

Class Diagram for the HOLIS Emergency Message Sequence Collaboration

Behavioral Aspects of the HOLIS Emergency Message Sequence Collaboration

Using Collaborations to Realize Sets of Individual Requirements

From Design to Implementation By modeling the system this way, we can ensure that the significant use cases and requirements of the system are properly realized in the design model. In turn, this helps ensure that the software design conforms to the requirements. The next step follows quite logically, although admittedly not easily. The classes and the objects defined in the design model are further refined in the iterative design process and eventually implemented in terms of the physical software components—source files, binaries, executables, and others—that will be used to create the executable software.

Key Points Some requirements map well from design to implementation in code. Other requirements have little correlation to design and implementation; the form of the requirement differs from the form of the design and implementation (the problem of orthogonality). Object orientation and use cases can help alleviate the problem of orthogonality. Use cases drive design by allowing all stakeholders to examine the proposed system implementation against a backdrop of system uses and requirements. Good system design is not necessarily optimized to make it easy to see how and where the requirements are implemented.