Modeling
description
Transcript of Modeling
![Page 1: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/1.jpg)
Modeling
ECE 417/617:Elements of Software Engineering
Stan BirchfieldClemson University
![Page 2: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/3.jpg)
Analysis modeling
• Let us first look at modeling the problem domain
![Page 4: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/12.jpg)
System modeling
• Now let us look at modeling the solution domain
![Page 13: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/18.jpg)
Creating CRC cardsIteratively• Find classes• Find responsibilities• Define collaborators• Move the cards
around
http://www.agilemodeling.com/artifacts/crcModel.htm
![Page 19: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/20.jpg)
UMLUnified 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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/21.jpg)
A simple problem to provide brief overview of UML
1 5 V
light
switch
![Page 22: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/22.jpg)
1. Use Case DiagramSimpleCircuit
FlipOn
FlipOff
ViewLight
User
Functionality from user’s point of view
![Page 23: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/23.jpg)
2. Class Diagram
Battery5V
Switch
Resistor Light
Structure of system (objects, attributes, associations, operations)
![Page 24: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/24.jpg)
3. Sequence Diagram
ResistorSwitch Battery Light
Messages between objects
UserFlipOn() HeatUp() Drain()
Shine()
![Page 25: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/html5/thumbnails/27.jpg)
4. Statechart Diagram (different objects)
Cold Hot
flipSwitchOn
flipSwitchOff
NotDraining
Draining
flipSwitchOn
flipSwitchOff
(Resistor) (Battery)
![Page 28: Modeling](https://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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://reader035.fdocuments.us/reader035/viewer/2022062814/5681684a550346895dde3d5e/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.