Beruflich Dokumente
Kultur Dokumente
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)
Analysis modeling
Let us first look at modeling the problem domain
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
Specifying requirements
Requirements can be specified in a number of ways:
user scenarios functions and feature lists analysis models specification
Traceability table
Captures the relationships between
features and requirements interfaces and requirements requirements themselves (dependencies) aspects etc.
A01 A02 A03 ... R01
requirements
R02
R03 ...
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
Use cases
Use case tells a stylized story about how an enduser 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. AddisonWesley 2000. http://www.usecases.org/
System modeling
Now let us look at modeling the solution domain
DFD is a forerunner of UML and may complement it Arcs are data; boxes are processes/actions
source code test plan execute unit tests test results review test results review decision
squares external entities round rectangles processes arrows data flow open-ended rectangles data stores
http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
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
CRC modeling
Class Responsibility Collaborator (CRC) is a lightweight model
Write on 3x5 index cards Used in extreme programming Can be used for
detailed object-oriented design conceptual modeling
http://www.agilemodeling.com/artifacts/crcModel.htm
CRC example
class is collection of objects
two types of collaboration: request for information request to do something
http://www.agilemodeling.com/artifacts/crcModel.htm
http://www.agilemodeling.com/artifacts/crcModel.htm
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)
1W
5V
light
2. Class Diagram
Switch
Resistor Battery 5V
Light
3. Sequence Diagram
User
Switch
Resistor
Battery
Light
FlipOn()
HeatUp()
Drain()
Shine()
3. Collaboration Diagram
User
1. FlipOn()
Switch
1.2 Shine()
1.1 HeatUp()
Resistor
1.3 Drain()
Light
Battery
4. Statechart Diagram
flipSwitchOn Light Off Light On
flipSwitchOff
Transitions between states of one object (Extension of Finite State Machine (FSM) model)
flipSwitchOn
Not Draining
Cold
Hot
Draining
flipSwitchOff
flipSwitchOff (Battery)
(Resistor)
5. Activity Diagram
Flip Switch On With swimlanes:
Actor1 Actor2
Flip Switch On
Read Book
Summary
We have looked at five UML diagrams: 1. Use case diagrams [Interaction Model]
-- models functionality from users point of view
2. Class diagrams
-- models structure of system using objects
3. Interaction diagrams
(sequence and collaboration) -- models messages passed between objects
4. Statechart diagrams
-- models transitions between states
[State Model]
5. Activity diagrams
The actual UML spec has 12 diagrams, but these five will be sufficient for us.