Download presentation
Presentation is loading. Please wait.
Published byApril Nicholson Modified over 8 years ago
2
Software Requirements Part 2 Requirements Engineering Modeling
3
Identify guidelines of creating requirements analysis models Explain structured and object-oriented analysis approaches to requirements modeling Identify three classifications of modeling elements based on object-oriented approach Apply use case diagram, activity diagram, class dia- gram, state diagram, and sequence diagram
5
Guidelines of Creating Requirements Analysis Models
6
A graphical representation of business processes, the problems to be solved, and the new proposed product (software) Objectives To describe software requirements To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built Bridges the gap between a software specification and a software design Software specification Design Model Analysis Model
7
Suggested by Arlow and Neustadt: The model should focus on requirements that are visible within the problem or business domain The level of abstraction should be relatively high Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system Delay consideration of infrastructure and other non- functional models until design
8
Suggested by Arlow and Neustadt: Minimize coupling throughout the system Be sure that the analysis model provides value to all stakeholders Keep the model as simple as possible especially if extra diagrams do not provide new information
9
Principle #1: The information domain of a problem must be represented and understood Principle #2: The functions that the software performs must be defined Principle #3: The behavior of the software, as a consequence of external events, must be represented
10
Principle #4: The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle #5: The analysis of task should move from essential information toward implementation detail
11
Structured and Object-oriented Analysis Approaches
12
According to Donald Firesmith: “Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain..” [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks...”
13
An on-going SE activity that is not connected to any software project (by domain analyst) Involves: Defining the domain to be investigated Collecting a representative sample of applications in the domain Analyzing each application in the sample Developing an analysis model for the objects
14
Categorized into two main levels of details: Context (conceptual-level) modeling High-level conceptual descriptions of a product and its environment. Must be supplemented with detailed-level models, e.g.: architectural model Usually usable to non-technical people and decision- makers Technical (detailed-level) modeling
15
Structured Analysis Considers data and the processes that transform the data as separate entities. Includes data models, data flow models and behavioral models e.g., ERD, DFD, state machine model
16
Object-oriented Analysis model objects, classes, and the relationships and behavior associated with them The industry standard for OO modeling is the Unified Modeling Language (UML) specification The current available version is 2.2 (OMG, 2009). e.g., use-case diagrams, activity diagrams (swim-lane diagram), sequence diagram, class diagram, state diagram, etc.
17
Classifications of Modeling Elements
18
Represents how data objects are transformed as they move through the system Data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an “old school” approach, but continues to provide a view of the system that is unique It should be used to supplement other analysis model elements
19
Need to first understand OO concepts, which include objects, classes, attributes, methods, sub- class, super-class, etc. Classifications of OO modeling elements: Scenario-based to show how end-users interact with the system e.g., use-case diagram, activity diagram, swimlane diagram
20
Class-based to specify classes and objects, attributes, operations, and associations and dependencies e.g., class diagram, class responsibility collaborator (CRC) model, collaboration diagram Behavioral to model how the system reacts to external event e.g., event-driven use-case, state diagram, sequence diagram
21
Ivar Jacobson: “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases)” Elements: Actor a ‘stick figure’ that represent roles of people, other system (database, servers, and legacy systems) or equipment that interact with use cases in the system.
22
Use case an oval shape labeled with the use case name (inside or outside the oval) that represent a complete unit of system functionality A use case may be made up of a set of scenario Each scenario describes the steps that consist of an interaction between the actors and the system Just like DFDs, you can continue to add detail by breaking the uses cases into more use cases
23
Use case diagram for SafeHome System
24
Airline Reservation System Check In Passenger Add New Reservation Cancel Reservation Airline Reservation System
25
Uses An arrow drawn from use case A to use case B to indicate that in the process of completing functionality A, functionality B will be performed too e.g., in the Airline Reservation System, the ‘Add New Reservation’ use case uses ‘Check Space Availability’ and ‘Record Passenger Information’ use cases
26
Extends An arrow drawn from use case A to use case B to indicate that the use case A is a special way of doing use case B and must be done to complete use case B e.g., in the Airline Reservation System, there are two ways to assign a seat either by assigning a window seat or by assigning an aisle seat
27
Airline Reservation System Check In Passenger Add New Reservation Cancel Reservation Weigh Luggage Assign Seat Check Seat Availability Record Passenger Information Assign Window Seat Assign Aisle Seat
28
Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario Activity diagrams and statechart diagrams are related While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process The activity diagram shows how those activities depend on one another
29
UML’s basic symbols:
31
A variation of activity diagram Represents the flow of activities described by the use- case, and At the same time, indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle
33
(http://edn.embarcadero.com/article/31863
34
Depicts a collection of system’s classes, their attributes, and the relationships between the classes A class is an object applicable to a system You can think of an object as any person, thing, place, concept, event, and etc. Objects have attributes (information stored about and object or variables for OO programming) and methods or operations (things an object perform)
35
To model a class, use a rectangle with three sections: name of the class (top) list of attributes (middle) methods (bottom). Example: a Student class which has attributes StudentID, Firstname, Lastname, Email, and ContactNumber. Student perform operations such as RegisterCourse, DropCourse, and PrintTranscript. Student StudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript() Name of class List of attributes List of methods
36
Need to show how they are related to each other Two basic types of relationships between classes: Associations This relationship exists when two classes are related to each other Analyze this relationship further by identifying multiplicity of the association because there is possibility that a student might register for none, one, or several courses Some potential multiplicity indicators: (see next slide) There are other types of associations such as association class, aggregation (basic and composition), reflexive associations, and realization. For further explanation, refer to OMG (2009).
37
Example: Registered 0..* attended by Course CourseCode CourseName CreditHours Fees Student StudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript()
38
Inheritance/Generalisation Different classes usually share the same attributes and/or methods To avoid repeating the same attributes and/or methods, you need to take advantage of the inheritance (also known as generalisation) mechanism When class X inherits from class Y, you may say that X is the subclass of Y and Y is the superclass of X UML’s notation for inheritance is a line with upward arrowhead pointing from the subclass to the superclass
39
Example Student StudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript() Course CourseCode CourseName CreditHours Fees Postgraduate ProjectTitle ThesisSubmitDate Undergraduate CreditLimit Registered 0..* attended by
40
Models a customer order from a retail catalog (http://edn.embarcadero.com/article/31863)
41
CRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements (Wir, 1990) A CRC model is really a collection of standard index cards that represent classes The cards are divided into three sections Along the top of the card you write the name of the class In the body of the card you list the class responsibilities on the left and the collaborators on the right (Ambler, 1995)
43
Makes a list of the different states of a system How does the system behave? Indicate how the system makes a transition from one state to another How does the system change state? indicate event indicate action Draw a state diagram, also known as statechart diagram or a sequence diagram
44
State a set of observable circumstances that characterizes the behavior of a system at a given time State transition the movement from one state to another Event an occurrence that causes the system to exhibit some predictable form of behavior Action process that occurs as a consequence of making a transition
45
In the context of behavioral modeling, two different characterizations of states must be considered the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function
46
The state of a class takes on both passive and active characteristics A passive state is simply the current status of all of an object’s attributes The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing
47
Notations: States are rounded rectangles Transitions are arrows from one state to another Events or conditions that trigger transitions are written beside the arrows The initial state (black circle) is a dummy to start the action Final states (2 circles with inner black circle) are also dummy states that terminate the action The action that occurs as a result of an event or condition is expressed in the form/action e.g., Cancel/Quit
48
http://edn.embarcadero.com/article/31863
49
State Diagram for the ControlPanel Class
50
An interaction diagram that show how operations are carried out - what messages are sent and when Are organized according to time Time progresses as you go down the page The objects involved in the operation are listed from left to right according to when they take part in the message sequence
51
Each vertical dotted line is a lifeline, representing the time that an object exists Each arrow is a message call An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline The activation bar represents the duration of execution of the message The diagram has a clarifying note, which is text inside a dog-eared rectangle
53
A sequence diagram for making a hotel reservation http://edn.embarcadero.com/article/31863
54
You have been introduced to: Guidelines of creating requirements analysis models. Two approaches to requirements modeling structured object-oriented analysis Three classifications of modeling elements based on object-oriented approach Several OO modeling elements such as use case diagram, activity diagram, class diagram, state diagram, and sequence diagram
55
Copyright © 2014 College of Information Technology
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.