Modeling
-
Upload
cruz-moore -
Category
Documents
-
view
50 -
download
0
description
Transcript of Modeling
![Page 1: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/1.jpg)
Modeling
ECE 417/617:Elements of Software Engineering
Stan BirchfieldClemson University
![Page 2: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/2.jpg)
Overview
• Modeling provides abstraction to bridge the gap between– High-level (world)– Low-level (code)
• Types of modeling: – Analysis modeling
• Models problem domain (users, world)
– System modeling• Models solution domain (software)
![Page 3: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/3.jpg)
Analysis modeling
• Let us first look at modeling the problem domain
![Page 4: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/4.jpg)
Requirements elicitation
• It is important to define what the software is supposed to do before – defining how to do it, or– before actually doing it
• “The hardest single part of building a software system is deciding what to build.” – Fred Brooks
• Requirements elicitation – gathering requirements from users and other stakeholders
![Page 5: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/5.jpg)
Difficulties in specifying requirements
• Customers often do not know what they want ... until they see it
• Customers often have a poor understanding of the ease or difficulty of implementing different capabilities
• The requirements change over time
![Page 6: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/6.jpg)
Steps in gathering requirements
• Inception – establish basic understanding of problem
• Elicitation – Ask the users what is needed• Elaboration – Refine the model of the S/W
functions, features, and constraints• Negotiation – Reconcile conflicts by ranking
requirements and discussing priorities• Specification – Final work product describing the
function and performance of the S/W• Validation – Examine the specification to ensure
that all requirements have been stated unambiguously, inconsistencies have been corrected, etc.
![Page 7: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/7.jpg)
Specifying requirements
• Requirements can be specified in a number of ways:– user scenarios– functions and feature lists– analysis models– specification
![Page 8: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/8.jpg)
Traceability table• Captures the relationships between
– features and requirements– interfaces and requirements– requirements themselves (dependencies)– etc.
A01 A02 A03 ...
R01 √
R02 √ √
R03 √
...
aspectsre
quire
men
ts
![Page 9: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/9.jpg)
User scenarios
• Usage scenarios– identify a thread of usage for the system– enable the S/W team to see how the
functions and features will be used by different classes of end users
– often called use cases
![Page 10: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/10.jpg)
Use cases
• Use case tells a stylized story about how an end-user interacts with the system under a specific set of circumstances
• Can be either– narrative text– outline of tasks or interactions– template-based description, or– diagrammatic representation
• “A use-case captures a contract...” -- Alistair Cockburn, Writing Effective Use Cases. Addison-Wesley 2000. http://www.usecases.org/
![Page 11: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/11.jpg)
Use case exampleUse case: Withdraw money
Level: User goal (Three levels: Summary, User goal, and Sub-function level)
Primary actor: Client
Goal in context: To withdraw money from the client’s account
Preconditions: User has an account, ATM has power and connectivity
Main scenario:1. Client inserts card2. Client types PIN3. Client specifies which account4. Client enters amount to withdraw5. Money is dispensed6. Card is ejected7. Client removes card
Extensions:1a. Card is invalid; card is ejected and client notified.2a. Pin is incorrect; client notified and given no more than two more attempts.4a. Amount exceeds limit; client notified, repeat step.7a. Client does not remove card within time limit; card is retracted.
![Page 12: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/12.jpg)
System modeling
• Now let us look at modeling the solution domain
![Page 13: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/13.jpg)
Data flow diagram (DFD)
• Data flow diagram (DFD) developed in late 1970s– part of Structured Design (one of the earliest methodologies
for software development); aka Structured Systems Analysis and Design Method (SSADM), a waterfall method
– invented by Larry Constantine, who also developed concepts of coupling and cohesion
• DFD is a forerunner of UML and may complement it• Arcs are data; boxes are processes/actions
executeunittests
reviewtest
results
test results review decisiontest plan
source code
![Page 14: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/14.jpg)
Gane and Sarson notation for DFDs
• squares – external entities• round rectangles – processes• arrows – data flow• open-ended rectangles – data
stores
http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
![Page 15: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/15.jpg)
Data flow diagram (DFD)
• DFDs are refined iteratively– Level 0 is context-level DFD; represents s/w as a single bubble with
input and output– Level 1 is achieved by expanding the bubble into additional
bubbles; perform grammatical parse on narrative describing bubble– Continue refining until each bubble performs specific function; high
cohesion– Components: bubbles are processes, boxes are external entities,
arrows are data or control objects, and double lines are data stores• Process specification (PSPEC) describes all flow model
processes that appear at the final level of refinement. It is a minispec for each transform at the lowest level of a DFD
• Program design language description (PDL) is basically pseudocode. One way to represent PSPEC
![Page 16: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/16.jpg)
CRC modeling• Class Responsibility Collaborator (CRC) is a
lightweight model
• Write on 3”x5” index cards• Used in extreme programming• Can be used for
– detailed object-oriented design – conceptual modeling
http://www.agilemodeling.com/artifacts/crcModel.htm
![Page 17: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/17.jpg)
CRC example
class is collection of objects
responsibility is anything a class knows or does
two types of collaboration:• request for information• request to do something
http://www.agilemodeling.com/artifacts/crcModel.htm
![Page 18: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/18.jpg)
Creating CRC cards
Iteratively
• Find classes
• Find responsibilities
• Define collaborators
• Move the cards around
http://www.agilemodeling.com/artifacts/crcModel.htm
![Page 19: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/19.jpg)
Unified modeling language (UML)
• Several competing object-oriented notations developed in 1980s and 1990s
• Rumbaugh and Booch began working together in 1994 at IBM Rational to standardize their notations (OMT and Booch)
• Result was Unified Modeling Language (UML)• Rights owned by Object Management Group
(OMG), www.omg.org• Good reference: M. Blaha and J. Rumbaugh,
Object-Oriented Modeling and Design with UML, 2nd ed.
![Page 20: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/20.jpg)
UML
Unified modeling language (UML) includes three models:
• class model – structural aspects of system (class diagrams)
• state model – temporal, behavioral aspects of system (state diagrams)
• interaction model – collaboration of individual objects (use cases, sequence diagrams, and activity diagrams)
![Page 21: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/21.jpg)
A simple problem to provide brief overview of UML
1 5 V
light
switch
![Page 22: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/22.jpg)
1. Use Case Diagram
SimpleCircuit
FlipOn
FlipOff
ViewLight
User
Functionality from user’s point of view
![Page 23: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/23.jpg)
2. Class Diagram
Battery5V
Switch
Resistor Light
Structure of system (objects, attributes, associations, operations)
![Page 24: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/24.jpg)
3. Sequence Diagram
ResistorSwitch Battery Light
Messages between objects
UserFlipOn() HeatUp() Drain()
Shine()
![Page 25: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/25.jpg)
3. Collaboration Diagram
Resistor
More compact, but harder to interpret
User1. FlipOn()
1.1 HeatUp()
1.3 Drain()1.2 Shine()
Battery
Switch
Light
![Page 26: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/26.jpg)
4. Statechart Diagram
Transitions between states of one object(Extension of Finite State Machine (FSM) model)
LightOff
LightOn
flipSwitchOn
flipSwitchOff
![Page 27: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/27.jpg)
4. Statechart Diagram (different objects)
Cold Hot
flipSwitchOn
flipSwitchOff
NotDraining
Draining
flipSwitchOn
flipSwitchOff
(Resistor) (Battery)
![Page 28: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/28.jpg)
5. Activity Diagram
Actions are states
Flip Switch On Flip Switch Off
With swimlanes:
Actor1 Actor2
Flip Switch On
Read Book
![Page 29: Modeling](https://reader033.fdocuments.us/reader033/viewer/2022042822/56812b13550346895d8f0751/html5/thumbnails/29.jpg)
SummaryWe have looked at five UML diagrams:1. Use case diagrams [Interaction Model]
-- models functionality from user’s point of view
2. Class diagrams [Class Model]-- models structure of system using objects
3. Interaction diagrams [Interaction Model](sequence and collaboration)-- models messages passed between objects
4. Statechart diagrams [State Model]-- models transitions between states
5. Activity diagrams [Interaction Model]-- models flow control as transitions between activities
The actual UML spec has 12 diagrams, but these five will be sufficient for us.