1. Software Modeling and Design
UNIT 1

2. Contents in Unit 1 Introduction to software design
Design methods- procedural / structural and object oriented
Requirement Vs Analysis Vs Architecture Vs Design Vs Development
4+1 Architecture UP
COMET use case based software life cycle
Introduction to UML -Basic building blocks
Use case modeling, Use case template

3. Introduction to software design, design methods- procedural / structural and object oriented, Requirement Vs Analysis Vs Architecture Vs Design Vs Development 4+1 Architecture, case study of transferring requirement to design, UP, COMET use case based software life cycle, Introduction to UML -Basic building blocks, Reusability, Use case modeling, Use case template
Case study – Transferring requirements into design using advanced tool

4. Model M: Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions.
To make predictions about the future
A model is always an approximation

5. Models of models of models...
Modeling is relative. We can think of a model as reality and can build another model from it (with additional abstractions).
fM1 fR M1 R
Requirements
Elicitation I1 M2
Analysis I2
fM2 ….
The development of
Software-Systems is a
Transformation of
Models:
Analysis, Design,
Implementation,Testing

6. Systems Development Life Cycle (SDLC)
Systems development project
Planned undertaking with fixed beginning and end
Produces desired result or product
Successful development project:
Provides a detailed plan to follow
Organized, methodical sequence of tasks and activities
Produces reliable, robust, and efficient system

7. Start of lecture. 15 Jan 2018

8. Phases of the Systems Development Lifecycle (SDLC)

9. SDLC (cont..)
Project planning: Initiate, ensure feasibility, plan schedule, obtain approval for project
Analysis: Understand business needs and processing requirements
Design: Define solution system based on requirements and analysis decisions
Implementation: Construction, testing, user training, and installation of new system
Support: Keep system running and improve

10. SDLC and problem-solving
Similar to problem-solving approach
Organization recognizes problem (Project Planning)
Project team investigates, understands problem and solution requirements (Analysis)
Solution is specified in detail (Design)
System that solves problem built and installed (Implementation)
System used, maintained, and enhanced to continue to provide intended benefits (Support)

11. 1. Software Design
Software Design is the process by which an agent creates a specification of a software artifact,
intended to accomplish goals,
using a set of primitive components and
subject to constraints.

12. e.g. of artifacts:
use cases, class diagrams, and
other Unified Modeling Language (UML) models,
requirements and design documents

13. 2. Software Design Notation
A software design notation is a means of describing a software design either graphically or textually, or both.
For example:
class diagrams are a graphical design notation, and
pseudocode is a textual design notation.

14. A design notation suggests a particular approach for performing a design; however, it does not provide a systematic approach for producing a design.

15. 3. Software Design Concept
A software design concept is a fundamental idea that can be applied to designing a system.
For example,
Information hiding is a software design concept.

16. 4. Software Design Strategy
A software design strategy is an overall plan and direction for developing a design.
For example,
object-oriented decomposition is a software design strategy.

17. 3. Software Design Method
A software design method is a systematic approach that describes the sequence of steps to follow in order to create a design,
given the software requirements of the application.
It helps a designer or design team identify the design decisions to be made, the order in which to make them, and the structuring criteria to use in making them.
A design method is based on a set of design concepts, employs one or more design strategies, and documents the resulting design, using a design notation

18. ANALYSIS VS DESIGN PHASE
Contd… from SDLC
ANALYSIS VS DESIGN PHASE

19. Analysis Phase of SDLC Gather information to learn problem domain
Define system requirements
Build prototypes for discovery of requirements
Prioritize requirements
Generate and evaluate alternatives
Review recommendations with management

20. Design Phase of SDLC Design and integrate the network
Design the application architecture
Design the user interfaces
Design the system interfaces
Design and integrate the database
Prototype for design details

21. Transition from Analysis to Design

22. Transition from Analysis to Design
Analysis: A process of extracting and organizing user requirements and establishing an accurate model of the problem domain.(WHAT)
Design: Process of mapping requirements to a system implementation that conforms to desired cost, performance, and quality parameters.(HOW)

23. Transition from analysis to Design
Blurred line between analysis & design
Process of design leads to better understanding of requirements
Can be performed iteratively
No direct & obvious mapping exists between structured analysis and structured design.

24. Two Approaches for Analysis & Design
Traditional Approach: SSAD(System Structured Analysis and Design)
Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams
Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts
OOAD
Designing systems using self-contained objects and object classes

25. Structured Analysis
Define what system needs to do (processing requirements)
Define data which the system needs to store and use (data requirements)
Define inputs and outputs
Define how functions work together to accomplish tasks
Data Flow Diagrams and Entity Relationship Diagrams show results of Structured Analysis

26. DFD
Better understanding of the functions of the systems could be obtained by considering the flow of data through the system.
DFDs start at a high level of abstraction and proceed to more detailed levels

27. There are essentially two different types of notations for data flow diagrams (Yourdon & Coad or Gane & Sarson) defining different visual representations for processes, data stores, data flow and external entities.
Yourdon and Coad type data flow diagrams are usually used for system analysis and design, while Gane and Sarson type DFDs are more common for visualizing information systems.
Visually, the biggest difference between the two ways of drawing data flow diagrams is how processes look. In the Yourdon and Coad way, processes are depicted as circles, while in the Gane and Sarson diagram the processes are squares with rounded corners.

28. 1. Process Notations.
A process transforms incoming data flow into outgoing data flow.

29. 2. Datastore Notations
Datastores are repositories of data in the system. They are sometimes also referred to as files.

30. 3. Dataflow Notations
Dataflows are pipelines through which packets of information flow.
Label the arrows with the name of the data that moves through it.

31. 4. External Entity Notations
External entities are objects outside the system, with which the system communicates.
External entities are sources and destinations of the system's inputs and outputs.

32. Level 0
Level 1
Level 2

33. Data Flow Diagram (DFD) created using Structured Analysis Technique

35. ERD
There are three basic elements in ER-Diagrams:

36. Entities are the "things" for which we want to store information.
An entity is a person, place, thing or event.
Attributes are the data we want to collect for an entity.
Relationships describe the relations between the entities.

37. Name of the entity must be unique within this model.
In this case, the name of the entity is a name of type, rather than a specific instance of this type.
A concrete representative of the entity is called by the entity instance

38. Entity-Relationship Diagram (ERD) created using the Structured Analysis technique Crows foot notation

39. Crow's Foot notation was proposed by Gordon Everest, originally called Inverted Arrow.
According to this notation, the entity is represented by rectangle containing its name.

40. Cardinality vs Modality
Cardinality refers to the maximum number of times an instance in one entity can be associated with instances in the related entity.
Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity.

41. Cardinality can be 1 or Many and the symbol is placed on the outside ends of the relationship line, closest to the entity,
Modality can be 1 or 0 and the symbol is placed on the inside, next to the cardinality symbol.
For a cardinality of 1 a straight line is drawn.
For a cardinality of Many a foot with three toes is drawn.
For a modality of 1 a straight line is drawn.
For a modality of 0 a circle is drawn.

43. Cardinality using Crows Foot Notation
ONE Artist (can) perform "zero, one, or many" song(s).

45. Structure Chart Created Using Structured Design Technique

46. Structure Chart (SC)
A Structure Chart (SC) in software engineering and organizational theory is a chart which shows the breakdown of a system to its lowest manageable levels.
They are used in structured programming to arrange program modules into a tree.
Each module is represented by a box, which contains the module's name.
The tree structure visualizes the relationships between modules.[3]

47. A structure chart is a top-down modular design tool, constructed of squares representing the different modules in the system, and lines that connect them.
The lines represent the connection and or ownership between activities and subactivities

48. In structured analysis structure charts, according to Wolber (2009), "are used to specify the high-level design, or architecture, of a computer program. As a design tool, they aid the programmer in dividing and conquering a large software problem, that is, recursively breaking a problem down into parts that are small enough to be understood by a human brain. The process is called top-down design, or functional decomposition. Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is drawn and used as a way for the client and the various software designers to communicate. During the actual building of the program (implementation), the chart is continually referred to as "the master-plan

49. Structure Charts - Invocation / Call
Call of subordinate module
Connector element
NOT a data flow
One specific form of control flow
Has a direction
No split or join
No label

51. Structure Charts - Sequence of Execution
Sequence of subordinate modules in the diagram is not reflecting a binding sequence of invocation
Sequence of invocation is defined in the specification of the super-ordinate module
Module specification is the decisive element

53. Structure Charts - Data Flow
Flow of information
Data transfer
Bound to invocation
Has a direction
No splits or joins
Label: noun

54. Structure Charts - Control Flow
Flow of control (<> invocation) ==> control execution path of targeted module
Bound to invocation
Has a direction
No splits or joins
Label: flag, decision, condition

55. Structure Charts - Data Store
Storage for permanent data
Database / file
Passive; no activity beyond basic retrieval capacity
Serviced by a module
Label: noun
Specified in data-dictionary and/or with an ER-diagram label
Data store

57. Structured Analysis Leads to Structured Design and Structured Programming

58. Structured programming
Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures, for and while loops—in contrast to using simple tests and jumps such as the go to statement, which could lead to "spaghetti code" that is difficult to follow and maintain

59. Two Approaches for Analysis & Design
Traditional Approach: SSAD(System Structured Analysis and Design)
Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams
Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts
OOAD
Designing systems using self-contained objects and classes

60. OOAD methods Three major steps: 1. Identify the objects
2. Determine their attributes and services
3. Determine the relationships between objects

61. Object-Oriented Approach
Views information system as collection of interacting objects that work together to accomplish tasks
OOA
OOD
OOP

62. Object Oriented Analysis (OOA)
Defines types of objects that do work of system
Shows how objects interact with users to complete tasks

63. Object-oriented analysis
The purpose of any analysis activity in the software life-cycle is to create a model of the system's functional requirements that is independent of implementation constraint

64. The primary tasks in OOA are:
Find the objects
Organize the objects
Describe how the objects interact
Define the behavior of the objects
Define the internals of the objects
Common models used in OOA are use cases and object models

65. Object Oriented Design
OOD is the process of planning a system of interacting objects for the purpose of solving a software problem.
It is one approach to software design.

66. Defines object types needed to communicate with people and devices in system
Shows how objects interact to complete tasks
Refines each type of object for implementation with specific language of environment

67. Deliverables of OOD
Sequence diagram
Class diagram

68. Object Oriented Programming (OOP)
Writing statements in programming language

69. General Advantages Understandable Practical Productive Stable
maps the “real-world” objects more directly
manages complexity via abstraction and encapsulation
Practical
successful in real applications
suitable to many, but not all, domains
Productive
experience shows increased productivity over life-cycle
encourages reuse of model, design, and code
Stable
changes minimally perturb objects

70. Phase Structured Object Oriented Analysis Structuring Requirements
DFDs
ER Analysis
Decision Tree
Requirements Engg
Use Case Modelling
Analysis Modelling
(Static & Dynamic)
Design
DB Design
GUI Design
Design System Architecture
Design Classes

71. The Unified Process (UP)

72. The Unified Process (UP)
Object-oriented development approach
Offered by IBM / Rational
Booch, Rumbaugh, Jacobson
Unified Modeling Language (UML) used primarily for modeling
UML can be used with any OO methodology
UP defines 4 life cycle phases
Inception, elaboration, construction, transition

73. The Unified Process (UP) (continued)
Reinforces six best practices
Develop iteratively
Define and manage system requirements
Use component architectures
Create visual models
Verify quality
Control changes

74. UP is divided into four phases Inception Elaboration Construction
Phases in UP
UP is divided into four phases
Inception
Elaboration       
Construction
Transition

75. Iterations
Each phase has iterations, each having the purpose of producing a demonstrable piece of software. The duration of iteration may vary from two weeks or less up to six months.
Inception
Elaboration
Construction
Transition
Iterations

76. The Iterations and the phases

78. Workflow:
Is defined as the repeatable pattern of business activity enabled by the systematic organization of resources into processes that transform the materials, provide services, or process the information.

79. Inception
The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered.
Scope and boundary conditions, acceptance criteria and some requirements are established.

80. Elaboration
An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources.
Define the architecture.
Validate the architecture.

81. Construction The Construction phase is a manufacturing process.
It emphasizes managing resources and controlling operations to optimize costs, schedules and quality.
Develop and test components.
Manage resources and control process.
Assess the iteration

82. Transition
The transition phase is the phase where the product is put in the hands of its end users.
It involves issues of marketing, packaging, installing, configuring, supporting the user-community, making corrections, etc.

83. UP over

84. COMET

85. What is COMET?
Concurrent Object Modeling and architectural design mEThod
COMET is a design method for UML supporting OO systems
Concurrent
Distributed
Real-Time
Compatible with USDP (Unified Software Development Process)

86. COMET Software Lifecycle
A highly iterative process
Focuses on the use case concept
Functional requirements are recorded in terms of actors and their use of the system, collected into use cases.
A use case is a series of interactions between one or more actors and the system

87. COMET Software Lifecycle

88. COMET Modeling 1. Requirements Modeling
Use cases are generated, and serve as the requirements for the system.
Throwaway prototypes can help to clarify the requirements.

89. Analysis Modeling
Static Models
Class Diagrams show the classes of the problem domain.
Dynamic Models
Show the problem domain objects participating in use cases.

90. 3. Design Modeling
Software architecture is designed
Problem Domain (Analysis Mode) is mapped to Solution Domain (Design Model)
Subsystems are identified and structured
Emphasis is on designing distributed subsystems as configurable components that communicate with each other via messaging.

91. 3. Incremental Prototyping
After modeling, the software subsystems are incrementally constructed and integrated into incremental prototypes.
A phased, iterative approach
Build and test a little at a time.

92. 4. Incremental Software Construction
Incremental Software Construction consists of
Detailed design
Coding
Unit testing

93. 5. Incremental Software Integration
Integration testing of each software is performed
Integration test for the increment
based on the use cases selected
developed for each use case
Is type of white box testing (between object interfaces)
Yields incremental prototype, formed by a software increment
Verified, integrated, then reiterated

94. 6. System Testing
When the incremental prototype is to be turned over to the customer, it must first undergo system testing.
The use cases of the requirements model are tested black box, ensuring the software meets specifications.

95. COMET ends….

96. UML

97. What is UML? Unified Modeling Language
OMG Standard, Object Management Group
Based on work from Booch, Rumbaugh, Jacobson
UML is a modeling language to express and design documents, software
Particularly useful for OO design
Independent of implementation language

98. Object Management Group (OMG)
Is an international, open membership, not-for-profit technology standards consortium.
OMG Task Forces develop enterprise integration standards for a wide range of technologies and industries. 0OMG modeling standards enable visual design, execution and maintenance of software and other processes. Originally aimed at standardizing distributed object-oriented systems, the company now focuses on modeling (programs, systems and business processes) and model-based standards

99. Why use UML Open Standard, Graphical notation for
Specifying, visualizing, constructing, and documenting software systems
Language can be used from general initial design to very specific detailed design across the entire software development lifecycle
Increase understanding/communication of product to customers and developers

100. Support for diverse application areas
Support for UML in many software packages today (e.g. Rational, plugins for popular IDE’s like NetBeans, Eclipse)
Based upon experience and needs of the user community

101. Brief History Flooded with methodologies in early 90’s
Booch, Jacobson, Yourden, Rumbaugh
Booch, Jacobson merged methods 1994
Rumbaugh joined 1995
1997 UML 1.1 from OMG includes input from others, e.g. Yourden
UML v2.0 current version

102. History of UML

103. OMT : Object Modeling Technique
OOSE: Object-Oriented Software Engineering
OOPSLA: Object-Oriented Programming,
Systems, Languages, and Applications.

104. Contributions to UML

105. Systems, Models and Views
A model is an abstraction describing a subset of a system
A view depicts selected aspects of a model
A notation is a set of graphical or textual rules for depicting views
Views and models of a single system may overlap each other
Examples:
System: Aircraft
Models: Flight simulator, scale model
Views: All blueprints, electrical wiring, fuel system

106. 4+1 View Model of Architecture

107. 4+1 View Model of Architecture
End user
Logical view
Development view
Programmers
& software managers
Scenarios
Process View
Physical View
The architecture in fact partially evolved from these scenarios as well as
The model is rather generic, and other notations and tools can be used, other design methods can be used especially for the logical and process decompositions
For each view, the architects can pick a certain architectural style
Similar views in UML
Use case view> - Encompass the use cases that describe the behavior of the system as seen by its end users, analysts, and testers
Design view - Encompass the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution
Process view - Encompass the threads and processes that form the system's concurrency and synchronization mechanisms
Implementation view - Encompass the components and files that are used to assemble and release the physical system
Deployment view - Encompass the nodes that form the system's hardware topology on which the system executes
System Engineer
Integrator

108. Logical View (Object-oriented Decomposition) Viewer: End-user
considers: Functional requirements- What the system should provide in terms of services to its users.
Notation: The Booch notation (OMT) (object and dynamic models)
Tool: Rational Rose

109. Process View (The process decomposition) viewer: Integrators
considers: Non - functional requirements (concurrency, performance, scalability)
style: Several styles would fit in this view (Garlan and Shaw ‘s Architecture styles)

110. Process view (cont.)
Uses multiple levels of abstractions, a logical network of processes at the highest level
A process is a grouping of tasks that form an executable unit:
Major Tasks: Arch. relevant tasks
Minor Tasks: Helper tasks. (Buffering)

111. Development View (Subsystem decomposition) Basis of a line of product
Viewer: Programmers and Software Managers
considers: software module organization (Hierarchy of layers, software management, reuse, constraints of tools)
Style: layered style
Notation: the Booch notation (module, subsystem, layer)

112. Physical View (Mapping the software to the Hardware)
Viewer: System Engineers
Considers: Non-functional req. regarding to underlying hardware (Topology, Communication)
Notation: May have several forms and may Tightly connected to the process view
There may be two architecture:
Test and development
deployment

113. 4+1 View Model of Architecture over…..

114. Models, Views, Diagrams

115. UML Diagrams

117. INTRODUCTION TO UML

118. A Conceptual Model of the UML
BASIC BUILDING BLOCKS

119. BASIC BUILDING BLOCKS 1. Things 2. Relationships 3. Diagrams
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first-class citizens in a model;
Relationships tie these things together;
Diagrams group interesting collections of things.

120. 1. Things in the UML 1. Structural things 2. Behavioral things
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML.
You use them to write well-formed models.

121. A. Structural Things Structural things are the nouns of UML models.
These are the mostly static parts of a model, representing elements that are either conceptual or physical.
In all, there are seven kinds of structural things.

122. A CLASS
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.
A class implements one or more interfaces.
Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations

124. A2. Interface
Is a collection of operations that specify a service of a class or component.
An interface therefore describes the externally visible behavior of that element.
An interface might represent the complete behavior of a class or component or only a part of that behavior.
An interface defines a set of operation specifications (that is, their signatures) but never a set of operation implementations.

125. Graphically, an interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is typically attached to the class or component that realizes the interface.

126. A3. Collaboration
Defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements.
Therefore, collaborations have structural, as well as behavioral, dimensions.
A given class might participate in several collaborations

127. A4. USE CASE
Is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor.
A use case is used to structure the behavioral things in a model.
A use case is realized by a collaboration.
Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name

128. A5. Active Class
Is a class whose objects own one or more processes or threads and therefore can initiate control activity.
An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements.
Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations

129. The previous five things represent conceptual or logical things, following 2 are
Physical Things

130. A6. Component
Is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.
A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations.
Graphically, a component is rendered as a rectangle with tabs, usually including only its name

131. A7. Node
Is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability.
A set of components may reside on a node and may also migrate from node to node.
Graphically, a node is rendered as a cube, usually including only its name

132. 1. Things in the UML 1. Structural things 2. Behavioral things
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML.
You use them to write well-formed models.

133. B. Behavioral things
Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

134. State machine − 
State machine is useful when the state of an object in its life cycle is important.
It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change

135. 1. Things in the UML 1. Structural things 2. Behavioral things
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML.
You use them to write well-formed models.

136. C. Grouping things
Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available −
Package − Package is the only grouping thing available for gathering structural and behavioral things.

138. 1. Things in the UML 1. Structural things 2. Behavioral things
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML.
You use them to write well-formed models.

139. D. Annotational things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. 
Note - It is the only Annotational thing available. A note is used to render comments, constraints, etc. of an UML element

140. 1. Things in the UML 1. Structural things 2. Behavioral things
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

141. BASIC BUILDING BLOCKS 1. Things 2. Relationships 3. Diagrams
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first-class citizens in a model;
Relationships tie these things together;
Diagrams group interesting collections of things.

142. 2. Relationships There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization

143. 2.1 Dependency
Is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing).
Graphically, a dependency is rendered as a dashed directed line.

144. 2.2 Association
An association is a structural relationship that describes a set of links,
a link being a connection among objects
Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and
often containing other adornments, such as multiplicity and role names

145. 2.3 Generalization
Is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent).
Thus the child shares the structure and the behavior of the parent.
Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent

146. 2.4 Realization
A semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
Two places:
Between interfaces and the classes or components that realize them,
Between use cases and the collaborations that realize them.
Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship

147. 2. Relationships 1. Dependency 2. Association 3. Generalization
4. Realization

148. BASIC BUILDING BLOCKS 1. Things 2. Relationships 3. Diagrams
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first-class citizens in a model;
Relationships tie these things together;
Diagrams group interesting collections of things.

149. 3. Diagrams 1. Class diagram 2. Object diagram 3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

150. Basic Modeling Steps Use Cases Analysis Model Design Model
Capture requirements
Analysis Model
Capture process, key classes
Design Model
Capture details and behaviors of use cases and domain objects
Add classes that do the work and define the architecture

151. UML Baseline Use Case Diagrams Class Diagrams Package Diagrams
Interaction Diagrams
Sequence
Collaboration
Activity Diagrams
State Transition Diagrams
Deployment Diagrams

152. USE CASE MODELING
Are important for v,s,d the behaviour of an element. They make the systems / subsystems approachable /understandable.

153. OBJECTIVE 1. To model the context of a subject (draw line)
2. To model the requirements of a subject

154. USE CASE
Is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor.
A use case is used to structure the behavioral things in a model.
A use case is realized by a collaboration.
Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name

155. EXAMPLE: Use Cases and Flow of Events
ATM System: Use case = Validate User
Main Flow of Events: use case starts when system prompts customer for PIN. Customer can now enter a PIN via the keypad. Customer commits the entry by pressing the Enter button. System then checks this PIN to see if it is valid. If the PIN is valid, system acknowledges the entry, thus ending the use case

156. Use Case Diagrams Purchase Ticket Passenger
Used during requirements elicitation to represent externally visible behavior
Actors represent roles, that is, a type of user of the system
Use cases represent a sequence of interaction for a type of functionality.
The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment
Purchase
Ticket
Passenger

157. UCD to Activity Diagrams.
Scope of each use case

158. Actors
An actor models an external entity which communicates with the system:
User
External system
Physical environment
An actor has a unique name and an optional description.
Examples:
Passenger: A person in the train
GPS : Provides the system with GPS coordinates
Passenger
Stick Figure

159. Use Case
A use case represents a class of functionality provided by the system as an event flow.
A use case consists of:
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
Purchase
Ticket

160. Examples of use cases
Validate user
Register for course
Pay for course

162. INCLUDE RELATIONSHIP
Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case.

163. The include relationship could be used:
to simplify large use case by splitting it into several use cases,
to extract common parts of the behaviors of two or more use cases.
A large use case could have some behaviors which might be detached into distinct smaller use cases to be included back into the base use case using the UML include relationship.
The purpose of this action is modularization of behaviors, making them more manageable.

164. Execution of the included use case is analogous to a subroutine call or macro command in programming.
All of the behavior of the included use case is executed at a single location in the including use case before execution of the including use case is resumed.

166. Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case.
The arrow is labeled with the keyword «include».

167. Included Use Case
Base Use Case

168. Large and complex Checkout use case has several use cases extracted, each smaller use case describing some logical unit of behavior.
Note, that including Checkout use case becomes incomplete by itself and requires included use cases to be complete.

170. Deposit Funds and Withdraw Cash use cases include Customer Authentication use case.

171. EXTEND RELATIONSHIP
Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended.
The extension takes place at one or more extension points defined in the extended use case.
Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword «extend».

172. Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.

173. Registration use case is complete and meaningful on its own.
It could be extended with optional Get Help On Registration use case
Base use Case
Extended use Case

174. Extension Point

175. The condition of the extend relationship as well as the references to the extension points are optionally shown in a comment note attached to the corresponding extend relationship.
An extension point is a feature of a use case which identifies (references) a point in the behavior of the use case where that behavior can be extended by some other (extending) use case, as specified by extend relationship.
Registration use case is conditionally extended by Get Help On Registration use case in extension point Registration Help.

177. Generalization
Extend
Include
Base use case could be abstract use case (incomplete) or concrete (complete).
Base use case is complete (concrete) by itself, defined independently.
Base use case is incomplete (abstract use case).
Specialized use case is required, not optional, if base use case is abstract.
Extending use case is optional, supplementary.
Included use case required, not optional.
No explicit location to use specialization.
Has at least one explicit extension location.
No explicit inclusion location but is included at some location.
No explicit condition to use specialization.
Could have optional extension condition.
No explicit inclusion condition.

178. Use Cases and Flow of Events
ATM System: Use case = Validate User
Main Flow of Events:
Exceptional Flow of Events:

179. EXAMPLE: Use Cases and Flow of Events
ATM System: Use case = Validate User
Main Flow of Events: use case starts when system prompts customer for PIN. Customer can now enter a PIN via the keypad. Customer commits the entry by pressing the Enter button. System then checks this PIN to see if it is valid. If the PIN is valid, system acknowledges the entry, thus ending the use case

180. Exceptional Flow of Events:
Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the Customer’s account
2. Exceptional Flow of Events:
Customer can clear a PIN number anytime before committing it and reenter a new PIN number.
3. Exceptional Flow of Events:
If the customer enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancels the entire transaction , preventing the Customer from interacting with ATM for 60 seconds.

181. SCENARIO
Each sequence representing one possible flow through all the variations in the use case
Instances are to classes, scenario is to Use Case

182. Use case diagrams commonly contain
· Use cases
· Actors
· Dependency, generalization, and association relationships
Like all other diagrams, use case diagrams may contain notes

183. Use Cases are useful to…
Determining requirements
New use cases often generate new requirements as the system is analyzed and the design takes shape.
Communicating with clients
Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.
Generating test cases
The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

184. Use Case Specification Template
Number
Unique use case number
Name
Brief noun-verb phrase
Summary
Brief summary of use case major actions
Priority
1-5 (1 = lowest priority, 5 = highest priority)
Preconditions
What needs to be true before use case “executes”
Postconditions
What will be true after the use case successfully “executes”
Primary Actor(s)
Primary actor name(s)
Secondary Actor(s)
Secondary actor name(s)
Trigger
The action that causes this use case to begin
Main Scenario
Step
Action
Step #
This is the “main success scenario” or “happy path.” …
Description of steps in successful use case “execution”
This should be in a “system-user-system, etc.” format.
Extensions
Branching Action
Alternative paths that the use case may take
Open Issues
Issue #
Issues regarding the use case that need resolution

185. Use Case Specification Template Example
Number 1
Name
Withdraw Money
Summary
User withdraws money from one of his/her accounts
Priority 5
Preconditions
User has logged into ATM
Postconditions
User has withdrawn money and received a receipt
Primary Actor(s)
Bank Customer
Secondary Actor(s)
Customer Accounts Database
Continued …

186. Trigger
User has chosen to withdraw money
Main Scenario
Step
Action 1
System displays account types 2
User chooses account type 3
System asks for amount to withdraw 4
User enters amount 5
System debits user’s account and dispenses money 6
User removes money 7
System prints and dispenses receipt 8
User removes receipt 9
System displays closing message and dispenses user’s ATM card 11
User removes card 10
System displays welcome message
Extensions
Branching Action 5a
System notifies user that account funds are insufficient 5b
System gives current account balance 5c
System exits option
Open Issues
Should the system ask if the user wants to see the balance?

187. Use Case Diagrams: Summary
Use case diagrams represent external behavior
Use case diagrams are useful as an index into the use cases
Use case descriptions provide meat of model, not the use case diagrams.
All use cases need to be described for the model to be useful.

188. Case study – Transferring requirements into design using advanced tool
Read On….. ( all basic concepts have been covered in class)
Case study – Transferring requirements into design using advanced tool

189. END OF UNIT 1