Post on 30-Dec-2015
transcript
SYSTEM MODELING AND THE UNIFIED MODELING LANGUAGE (UML)CS 360
Lecture 6
MODELS FOR REQUIREMENTS ANALYSIS AND SPECIFICATIONA model is a simplification of reality
We build models to better understand the system being developed.
We build models of complex systems because we cannot comprehend such a system in its entirety.
Models can be formal or informal.The more complex a project becomes, the more valuable a formal model becomes.
2
PRINCIPLES OF SOFTWARE MODELINGUML “Unified Modeling Language”
Expresses an idea, not detailed description on functionality. Used to describe a software system at a high level of abstraction.
Serves as a bridge between the requirements specifications and the implementation.
Is process and programming language independent. An industry-standard process for specifying, visualizing, constructing, and documenting information about software systems.
Simplifies the complex process of software design.3
MODELS: DIAGRAMS AND DOCUMENTATION IN UML In UML, a model consists of a diagram and documentation. A diagram is the graphical representation of a set of elements representing components of the software system.
Each diagram is supported by technical documentation that specifies the components represented.
A diagram without documentation is of little value.
4
UML: USE OF GRAPHICAL MODELSMeans of discussion about an existing or proposed system
Way of documenting an existing system Models should be an accurate representation of the system but need not be complete.
Detailed system description that can be used to generate a system implementation Models have to be both correct and complete.
5
TYPES OF UML DIAGRAMSUse Case Diagrams
Interactions between a system and its environmentClass Diagrams
Shows the object classes in the system and the associations between those classes
Sequence Diagrams Interactions between actors and the system, and between system components
State DiagramsShows how the system reacts to internal and external events
6
USE CASE DIAGRAMS (DOCUMENTATION)A use case is a model of the interaction between
External users of a software product (actors) and The software product itself
describes a set of scenarioscaptures user requirementscontract between client and software developers
7
USE CASE DIAGRAMSActors:
A role that a user plays with respect to the system.
Use case: A set of scenarios that describing an interaction between a user and a system.
System boundary: rectangle diagram representing the boundary between the actors and the system. 8
USE CASE DIAGRAMS (LIBRARY)
9
Library System
Borrow
Order Title
Fine
ClientEmployee
Supervisor
BoundaryActor
Use Case
USE CASE DIAGRAMS (FLIGHT CHECK-IN)
10
BoundaryActor
Use Case
CLASS DIAGRAMS (DOCUMENTATION)A class diagram depicts classes and their interrelationshipsUsed for describing structure and behavior in the use cases
Used for requirement capture, end-user interactionDetailed class diagrams are used for developers
Used for communicating software connections/requirements
11
CLASS DIAGRAMSEach class is represented by a rectangle subdivided into three compartments Name Attributes Operations
Modifiers are used to indicate visibility of attributes and operations. ‘+’ is used to denote Public visibility ‘#’ is used to denote Protected visibility ‘-’ is used to denote Private visibility
By default, attributes are hidden and operations are visible.12
CLASS DIAGRAMS (BANK ACCOUNT)
13
Account_Name
- Customer_Name- Balance
+addFunds( )+withDraw( )+transfer( )
Attributes
Operations
Class Name
CLASS DIAGRAMS (SHAPES)
14
Operations
Class Name
Attributes
CLASS DIAGRAMS
15
Subtype2
Supertype
Subtype1
• Inheritance is a required feature of object orientation
• Promotes code reuse and flexability
Regular Customer
Loyalty Customer
Customer Example:
SEQUENCE DIAGRAMS (DOCUMENTATION)Sequence diagrams
Used to model the interactions between the actors and the objects within a system.
Shows interactions of specific use cases.Objects and actors are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by arrows.
16
SEQUENCE DIAGRAMSUsed to model the interactions between the actors and the objects within a system.Shows the sequence of interactions that take place during a particular use case.
Example:User making a phone call
17
SEQUENCE DIAGRAMS (TELEPHONE CALL)
18
Caller Phone Recipient
Picks up
Dial tone
Dial
Ring notification Ring
Picks up
Hello
SEQUENCE DIAGRAMS (BOOKING WEBSITE)
19
STATE DIAGRAMS (DOCUMENTATION)Models the behavior of the system in response to external and internal events.
Shows the system’s responses to stimulioften used for modelling real-time systems.
Shows states as nodes, and events as edges between these nodes. When an event occurs, the system moves from one state to another.
20
STATE DIAGRAMS (BILLING EXAMPLE)State Diagrams show the sequences of states an object goes through during its life cycleabstraction of all possible behaviors
21
Unpaid
Start End
Paid
Invoice created
paying
Invoice destroying
STATE DIAGRAMS (TRAFFIC LIGHT EXAMPLE)
22
Yellow
Red
Green
Traffic LightState
Transition
Event
Start
UML DIAGRAMSUML is a standardized specification language for object modeling
Several UML diagrams:Use-case diagram: models the interaction between actors and software
Class diagram: a model of classes showing the static relationships among them.
Sequence diagram: shows the way objects interact with one another as messages are passed between them.
State diagram: shows states, events that cause transitions between states.
23
MODELING TOOLS: PSEUDO-CODE An informal modeling technique to show the logic behind part of a system.
Example: University Admission Decision adminDecision (application)
if application.SAT == null then error (incomplete) if application.SAT > S1 then accept(application) else if application.GPA > G1 then accept(application) else if application.SAT > S2 and application.GPA > G2
then accept(application) else reject(application)
Pseudo-code can be informal, or a standard used by a software development organization, or based on a regular programming language.
What matters is that its interpretation is understood by everybody involved.
24
PROTOTYPING REQUIREMENTSRapid prototyping is the most comprehensive of all modeling methodsSpecifying requirements by building a system that demonstrates the functionality of key parts of the required system
Particularly valuable for user interfaces
25
REQUIREMENTS DEFINITION: DATA DICTIONARYA data dictionary is a list of names used by the system
Name (e.g., "start date") Brief definition (e.g., what is "date") Where is it used (e.g., source, used by, etc.) May be combined with a glossary
As the system is developed, the data dictionary in the requirements is the basis of the system data dictionary, which is part of the final specification.
26
SOFTWARE MODELING: KEY POINTSA model is an abstract view of a system that ignores system details. System models can be developed to show the system’s context, interactions, structure and behavior.
Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the product. Describes interactions between a system and external actors.
Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system.
27