Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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 R01 R02 A02 A03 ...
requirements
...
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
test results
review decision
squares external entities round rectangles processes arrows data flow open-ended rectangles data stores
http://www.agilemodeling.com/artifacts/dataFlowDiagram.
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.
CRC example
class is collection of objects two types of collaboration: request for information request to do something
http://www.agilemodeling.com/artifacts/crcModel.
http://www.agilemodeling.com/artifacts/crcModel.
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)
2. Class Diagram
Switc h Resist or Batter y 5V Structure of system (objects, attributes, associations, operations) Ligh t
3. Sequence Diagram
Drain( ) Shine ()
Batter y
Ligh t
3. Collaboration Diagram
Use r
1.1 HeatUp()
Switc h
Resist or 1.3
Drain()
4. Statechart Diagram
flipSwitchO n Ligh t Off flipSwitchO ff Transitions between states of one object (Extension of Finite State Machine (FSM) model) Ligh t On
flipSwitchO ff (Battery )
5. Activity Diagram
Flip Switch On With swimlanes: Actor1 Flip Switch On Read Book Flip Switch Off
Actor2
Summary
We have looked at five UML diagrams: 1. Use case diagrams [Interaction Model]
-- models functionality from users point of view
The actual UML spec has 12 diagrams, but these five will be sufficient for us.