Modeling system requirements. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information.

Slides:



Advertisements
Similar presentations
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Advertisements

Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Objectives Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain how.
1 SWE Introduction to Software Engineering Lecture 13 – System Modeling.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Chapter 14 (Web): Object-Oriented Data Modeling
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Overview Objective: refine information gathered
2Object-Oriented Analysis and Design with the Unified Process Events and Use Cases  Use case  Activity the system carries out  Entry point into the.
6. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how events can be used to identify use cases that define requirements.
2-1 © Prentice Hall, 2004 Chapter 2: Introduction to Object Orientation (Adapted) Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra,
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 14: Object-Oriented Data Modeling
Chapter 5: Modeling Systems Requirements: Events and Things
Modeling System Requirements:Events and Things
Systems Analysis and Design in a Changing World, Tuesday, Feb 27
Modeling System Requirements:
Systems Analysis and Design in a Changing World, Fifth Edition
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
5 Systems Analysis and Design in a Changing World, Fourth Edition.
Systems Analysis and Design in a Changing World, Fifth Edition
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Association Class Generalization/Specialization Whole-Part Page More Associations 1.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
Chapter 7 System models.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 Domain Classes.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 15: Object-Oriented Data Modeling Modern Database Management 9 h Edition Jeffrey A.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
Domain Modeling Part2: Domain Class Diagram Chapter 4 pp part 2 1.
CHAPTER 13: OBJECT-ORIENTED DATA MODELING (OVERVIEW) © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Objectives Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain.
An Introduction to the Unified Modeling Language
5 Systems Analysis and Design in a Changing World, Fifth Edition.
Modeling System Requirements: Events and Things. Objectives Explain the many reasons for creating information system models Describe three types of models.
What is a Structural Model?
Design? !… When it needs? To understand, to communicate with customers Complex problem What is good design? Separate What to do?(Policy) and How to do(mechanism)
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Management Information Systems
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
Chapter 4 Basic Object-Oriented Concepts. Chapter 4 Objectives Class vs. Object Attributes of a class Object relationships Class Methods (Operations)
© Shamkant B. Navathe CC Enhanced Entity-Relationship Copyright © 2004 Ramez Elmasri and Shamkant Navathe.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Class Diagram Lecture # 1. Class diagram A Class Diagram is a diagram describing the structure of a system shows the system's classes Attributes operations.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
CS 350 – Software Design UML – The Unified Modeling Language – Chapter 2 The Unified Modeling Language is a visual language used to create models of programs.
5 Systems Analysis and Design in a Changing World, Fourth Edition.
5 Chapter 5: Modeling Systems Requirements: Events and Things Systems Analysis and Design in a Changing World.
DATA REQIREMENT ANALYSIS
Domain Class Diagram Chapter 4 Part 2 pp
Systems Analysis – ITEC 3155 Modeling System Requirements – Part 2
Presentation transcript:

Modeling system requirements

Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information system for an analyst to focus on few aspects of the system at a time. Many different models can be used by the analyst when developing a system. Models help the analyst recall details of work previously completed.

Models serve a critical role in supporting communication among project team members and with system users. Analyst reviews models with a variety of users to get feedback on the analysts understanding of the system requirements. The requirements models produced by the analyst are used as documentation for future development teams when they maintain or enhance the system.

Types of models Mathematical models: A series of formulas that describe technical aspects of a system. They are used to represent precise aspects of the system that can be best represented by using formulas or mathematical notation. These models are examples of technical requirements. Mathematical notation is the most appropriate way to represent functional requirements

It is also the most natural way for scientific and engineering users to express requirements. An analyst working on scientific and engineering applications better be comfortable with math Mathematical notation is also sometimes efficient for simpler requirements for business sytems.

Descriptive models Not all requirements can be precisely defined with mathematics Descriptive models are narrative memos, reports, or lists that describe some aspect of a system. One example of descriptive model involves writing a process or procedure in a very precise way, referred to as structured english or pseudocode

Graphic models The most useful model is the graphical model. Graphical models include diagrams and schematic representations of some aspect of a system Graphical models make it easy to understand complex relationships that are too difficult to follow when described verbally. Some graphical models actually look similar to a real-world part of a system such as screen design or a report layout design

In graphical model, the analyst use symbols to represent more abstract things The key graphical models used for the analysis phase tend to represent the more abstract aspects of a system, because the analysis phase focuses on fairly abstract questions about system requirements without indicating the details of how they will be implemented

USE CASES Specifics for modeling the functional requirements of an information system A use case is an activity the system performs, usually in response to a request by a user. Techniques for identifying activities or use cases – List all users and think through what they need the system to do for their jobs. By focusing on one type of user at a time, an analyst can systematically address the problem of identifying use cases

Another approach is to start with the existing system and list all system functions that are currently included, adding any new functionality requested by users. Another approach is to talk to all users to get them to describe their goals in using the system.

USE CASE DIAGRAM Use case diagrams are diagrams used to show the various user roles and how those roles use the system. Use case diagrams are convenient ways to document system activities. Sometimes a single. Comprehensive diagram is used to identify all use cases for an entire system Other times, a set of smaller use case diagrams is used

Each use case must also be described in detail using use case narration. The objective of use case analysis is to identify and define all of the elementary business processes that the system must support. Use case is an activity the system carries out, usually in response to a request by a user of the system.

Unified Modeling Language Unified Modeling Language (UML) is a standardized general- purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of software-intensive systems.

CLASS DIAGRAM Classes of objects have attributes and associations. Cardinality also applies among classes. Class diagram is used to show classes of objects for a system. Rectangles represent classes, and the lines connecting the rectangles show the associations among classes.

Class diagrams shows a rectangle with two or three sections. The top section contains the name of the class, the middle section lists the attributes of the class, and the bottom section lists the important methods of the class. Class diagrams are drawn by showing classes and associations among classes.

Types of UML Class diagram Domain model class diagram – Each class symbol includes only two sections. Methods are not shown on a domain model class diagram. – UML notation requires class names to be capitalized. – Attributes begin with a lowercase letter.

Generalization/specialization Hierarchies They are based on the idea that people classify things in terms of similarities and differences. Generalizations are judgments that group similar types of things. Eg. Motor vehicles- cars, trucks, tractors. All motor vehicles share certain general characteristics, so a motor vehicle is a more general class.

Specializations are judgments that categorize different types of things. Eg. Special types of cars include sports cars, sedans, and sport utility vehicles. These types of cars are similar in some ways, yet different in other ways. A generalization/specialization hierarchy is used to structure or rank these things from the more general to the more special.

Each class might have a more general class above it, called a superclass. A class might have a more specialized class below it, called a subclass. Inheritance allows subclasses to share characteristics of their superclasses

Whole-Part Hierarchies Another way people structure information about things is by defining them in terms of their parts. Whole part hierarchies capture the relationships that people make when they learn to make associations between an object and its components. An examples is keyboard which is not a special type of computer but rather part of a computer.

Types of whole-part hierarchies Two types: aggregation and composition Aggregation is used to describe a form of association that specifies a whole-part relationship between the aggregate (whole) and its components (parts) where the parts can exist separately. Composition is used to describe whole-part relationships that are even stronger, where the parts, once associated, can no longer exist separately.

The UML diamond symbol is filled in to represent composition. Whole-part hierarchies serve mainly to allow the analyst to express subtle distinctions about associations among classes.

Design class diagram This diagram shows more about the actual design of the software.