SlideShare a Scribd company logo
Software Engineering
&
Project Management
Module 2
Introduction, Modelling Concepts and Class Modelling: What is Object orientation? What is OO development? OO
Themes; Evidence for usefulness of OO development; OO Modelling history. Modelling as Design technique: Modelling,
abstraction, The Three models. Class Modelling: Object and Class Concept, Link and associations concepts,
Generalization and Inheritance, A sample class model, Navigation of class models, and UML diagrams.
Building the Analysis Models: Requirement Analysis, Analysis Model Approaches, Data Modelling Concepts, Object
Oriented Analysis, Scenario-Based Modelling, Flow-Oriented Modelling, class Based Modelling, Creating a Behavioural
Model.
Presented By: Dr. Prakhyath Rai
Introduction
Object oriented means organizing software as a collection of discrete objects that incorporate both
data structure and behaviour.
Characteristics of OO approach:
 Identity - Data is quantized into discrete, distinguishable entities called object. Examples: first paragraph, a
white rook etc.
 Classification - Objects with the same data structure (Attributes) and behaviour (Operations) are grouped
into a class. Examples: Student, Paragraph
 Inheritance - Sharing of attributes and operations (Features) among classes based on a hierarchical
relationship. A superclass has general information that subclass refine and elaborate. Example: Window
(Superclass) -> ScrollingWindow + FixedWindow (Subclasses)
 Polymorphism - Same operation may behave differently for different classes. Example: Move operation of
Queen and Move operation of Pawn.
Operation: Procedure or transformation an object performs or subjected to
Method: An implementation of an operation by a specific class
OO Development
Development – Software lifecycle: Analysis, Design, and Implementation
Essence of OO Development – Identification and Organization of application concepts instead of final
representation in programming language
OO Concepts apply throughout the system development life cycle – from analysis through design to
implementation
1. Modelling Concepts, Not Implementation
 Addressing frontend conceptual issues rather than backend implementation details
 Serves as a medium for specification, analysis, documentation, interfacing and development
 Aids specifiers, developers and customers express abstract concepts clearly and facilitates communication
2. OO Methodology
 System Conception – Starts with conceiving an application and formulating requirements
 Analysis – Analysts scrutinizes and rigorously restates requirements by construction models from system conception
OO Development
2. OO Methodology
 System Design – High level strategy: The System Architecture
 Class Design – Adds details to system design analysis model, Focus on data structures and
algorithms for each class
 Implementation – Translates classes and relationships from class design into a particular
programming language
3. Three Models – To describe systems from different viewpoints
 Class Model – Describes static structure of the objects in the system and their relationship (Class
Diagram)
 State Model – Describes the aspects of the object that change over time (State Diagram)
 Interaction Model – Describes how objects in the system cooperate to achieve broader results (Use-
Case Diagram, Sequence Diagram, Activity Diagram)
OO Themes
1. Abstraction
 Abstraction means focusing on what an object is and does, before deciding how to implement it.
 Focussing on what an object is and does, before deciding on implementation
2. Encapsulation
 Information Hiding - separates the external aspects of an object that are accessible to other
objects, from the internal implementation details that are hidden from other objects.
3. Combining Data and Behaviour
 The caller of an operation need not consider how many implementations exist.
 Operator polymorphism shifts the burden of deciding what implementation to use from the calling
code to the class hierarchy.
OO Themes
4. Sharing
 OO technologies promote sharing at different levels.
 Inheritance of both data structure and behaviour lets subclasses share common code. This sharing via
inheritance is one of the main advantages of OO languages.
 OO development not only lets you share information within an application but also offers the prospect of
reusing designs and code on future projects.
5. Emphasis on the Essence of an Object
 OO technology stresses what an object is, rather than how it is used. The uses of an object depend on the
details of the application and often change during development.
6. Synergy
 Identity, classification, polymorphism and inheritance characterize OO languages. Each of these concepts can
be used in isolation but together they complement each other synergistically.
Evidence for Usefulness of OO Development
1. Testing a physical entity before building it
2. Communication with Customers
3. Visualization
4. Reduction of Complexity
Abstraction:
 Selective examination of certain aspects of a problem.
 The goal of abstraction is to isolate those aspects that are important for some
purpose and suppress those aspects that are unimportant.
 A good model captures the crucial aspects of a problem and omits the others.
The Three Models
Model a system with related but different viewpoints
1. Class Model
 Represents the static, structural and data aspects of a system
2. State Model
 Represents the temporal, behavioural, control aspects of a system
3. Interaction Model
 Represents the collaboration of individual objects, interaction aspects of a system
The 3 kinds of models separate a system into distinct views.
Example: Class model attaches operations to classes and state and interaction models elaborate the
operations
Class Model
 Describes the structure of objects in a system - their identity, their relationships
to other objects, their attributes and their operations.
 Goal in constructing a class model is to capture those concepts from the real
world that are important to an application.
 Class diagrams express the class model. Classes define the attribute values
carried by each object and the operations that each object performs or
undergoes.
 The class model provides context for the state and interaction models
State Model
 Describes those aspects of objects concerned with time and the
sequencing of operations – events that mark changes, states that
context for events and the organization of events and states.
 State diagrams express the state model. Each state diagram shows the
state and event sequences permitted in a system for one class of objects.
 The state model captures control, the aspect of a system that describes
the sequence of operations that occur, without the regard for what the
operations do, what they operate on, or how they are implemented.
Interaction Model
 Describes interactions between objects – how individual objects collaborate to
achieve the behaviour of the system.
 Use cases, sequence diagrams and activity diagrams document the interaction
model.
• Use cases document major themes for interaction between the system and
outside actors.
• Sequence diagrams show the objects that interact and the time sequence of their
interactions.
• Activity diagrams show the flow of control among the processing steps of a
computation.
Relationship among the Three Models
Class Model
 The Class model describes data structure on which the state and interaction models operate.
 The operations in the class model corresponds to events and actions.
State Model
 The state model describes the control structure of objects.
 The state model shows decisions that depend on object values and causes actions that
change object values and state.
Interaction Model
 The interaction model focusses on the exchanges between objects and provides a holistic
overview of the operation of a system.
Class Modelling - Concepts
 Class & Object Diagram
 Association & Links
 Multiplicity
 Multiplicity & Visibility of Attributes
 Association End Names
 Association Classes
 Qualified Associations
 Ordering, Bags & Sequence
 Generalization and Inheritance
 Overriding Features
Sample Class Diagrams
Sample Class Diagrams
Sample Class Diagrams
Objects
Sample Class Diagrams
Sample
Class
Diagrams Class Model of Windowing System
Sample Class Diagrams Class Model for Managing
Credit Card Accounts
Navigation of Class Model - OCL
Attributes: You can traverse from an object to an attribute value.
 Syntax: source object, followed by a dot and then the attribute name.
 Example: aCreditCardAccount. maximumCredit
Operations: You can also invoke an operation for an object or a collection
of objects.
 Syntax: source object or object collection, followed by a dot and then the operation. The
operation must be followed by parentheses, even if it has no arguments to avoid
confusion with attributes.
 The OCL has special operations that operate on entire collections. The syntax for a
collection operation is the source object collection followed by -> and then the operation.
Navigation of Class Model - OCL
Simple Associations: A 3rd use of dot notation is to traverse an association to a target
end.
 Example: aCustomer.MailingAddress yields a set of addresses for a customer. In contrast,
 aCreditCardAccount.MailingAddress yields a single address.
Qualified Associations: A qualifier lets you make a more precise traversal. The
expression
 aCreditCardAccount.Statement[30 November 1999] finds the statement for a credit card account with the
statement date 30 November 1999. The syntax is to enclose the qualifier value in brackets.
Generalizations: Traversal is implicit for the OCL notation.
 Filters: OCL has several kinds of filters, most common of which is the select operation.
 Example: aStatement.transaction -> select(amount>$100) finds the transactions for a statement more than
$100.
Examples of OCL Expressions
1. What transactions occurred for a credit card account within a time interval?
 aCreditCardAccount.Statement.Transaction -> select(aStartDate <= transactionDate and transactionDate <=
anEndDate)
2. What volume of transactions were handled by an institution in the last year?
 anInstitution.CreditCardAccount.Statement.Transaction -> select(aStartDate <= transactionDate and
transactionDate <= anEndDate).amount->sum( )
3. What customers patronized a merchant in the last year by any kind of credit card?
 aMerchant.Purchase -> select(aStartDate <= transactionDate and transactionDate <=
anEndDate).Statement.CreditCardAccount.MaillingAddress.Customer -> asset( )
4. How many credit card accounts does a customer currently have?
 aCustomer.MaillingAddress.CreditCardAccount -> size( )
5. What is the total maximum credit for a customer, for all accounts?
 aCustomer.MaillingAddress.CreditCardAccount.maximumCredit -> sum( )
Requirement Analysis
Purpose of Requirements Analysis:
 Specification of software’s operational characteristics
 Indication of software’s interface with other system elements
 Establishment of constraints for the software
Modelling Techniques:
 Scenario-based models: View from various system “actors”
 Data models: Depiction of the information domain
 Class-oriented models: Object-oriented classes and collaborations
 Flow-oriented models: Functional elements and data transformation
 Behavioural models: Software behaviour due to external “events”
Importance:
 Provides design information for architectural, interface, and component levels
 Facilitates assessment of software quality
Requirement Analysis
Scenario-Based Modelling:
 Increasingly popular
 Understanding requirements from actor perspectives
 Examples: Use cases, UML models, Swimlane diagram
Data Modelling:
 Managing complex information spaces
 Critical for applications involving data manipulation
Class Modelling:
 Representing object-oriented classes (attributes and operations)
 Collaboration among classes for system functionality
Objectives of Requirements Model
Objectives:
 Describe what the customer requires
 Establish a basis for creating a software design
 Define requirements for validation once the
software is built
Bridge Between System Description and Design:
 Requirements model links system/business
functionality with software design
 Ensures traceability from analysis to design
Requirement Model Rules
Rules of thumb that followed when creating the analysis model:
 The model should focus on requirements that are visible within the problem or business domain. The
level of abstraction should be relatively high.
 Each element of the requirements model should add to an overall understanding of software
requirements and provide insight into the information domain, function, and behaviour of the system.
 Delay consideration of infrastructure and other nonfunctional models until design.
• Example: Database classes, access functions, and behaviour
 Minimize coupling throughout the system.
• Represent relationships between classes and functions but reduce high levels of
interconnectedness
 Be certain that the requirements model provides value to all stakeholders.
 Keep the model as simple as it can be.
Domain Analysis
 Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse on multiple projects
within that application domain.
 [Object-oriented domain analysis is] the identification, analysis, and specification of
common, reusable capabilities within a specific application domain, in terms of common
objects, classes, subassemblies, and frameworks.
Requirements Modelling Approaches
Elements of the analysis model
Structured Analysis
Focus: Data and processes as separate entities
Data Objects: Modelled by attributes and relationships
Processes: Modelled by how they transform data objects
Object-Oriented Analysis
Focus: Definition of classes and their collaboration
Tools: UML and the Unified Process
Class-Based Elements: Objects, operations, relationships,
collaborations
Combined Approach
Hybrid Model: Features of both structured and object-
oriented analysis
Stakeholder Focus: Best combination of representations
for requirements and design
Data Modelling Concepts
Data Objects
 A data object is a representation of composite information that must be understood by
software.
 A data object can be an external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or
event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting
department), a place (e.g., a warehouse), or a structure (e.g., a file).
Data Attributes
Data attributes define the properties of a data object and take on one of three different
characteristics. They can be used to (1) name an instance of the data object, (2) describe the
instance, or (3) make reference to another instance in another table.
Data Modelling Concepts
Relationships
 Connection between data objects
Relationships between data
objects
Tabular representation of data objects
Class based Modelling
Identifying Analysis Classes
 External Entities – Devices, People
 Things – Reports, Letters, Signals
 Occurrences or Events
 Roles – Manager, Accountant
 Organizational Units – Department,
Division
 Places – Administrative Block, Lab
 Structures – Sensors, Vehicles
Coad and Yourdon Criteria /
Characteristics
 Retained information
 Needed services
 Multiple attributes
 Common attributes
 Common operations
 Essential requirements
Class based Modelling
Class based Modelling
Class based Modelling
Class-Responsibility-Collaborator (CRC)
Modelling
A set of class-responsibility
collaborator index cards can be
used to define relationships
between classes.
Class based Modelling
Association & Dependencies
Dependencies
Multiplicity
Class based Modelling
Analysis Packages:
Analysis packages are used to
categorize and group classes in a
manner that makes them more
manageable for large systems.
Scenario based Modelling
 Creating a Preliminary Use Case
Consider the SafeHome system, the homeowner
has following functionalities,
• Select camera to view.
• Request thumbnails from all cameras.
• Display camera views in a PC window.
• Control pan and zoom for a specific camera.
• Selectively record camera output.
• Replay camera output.
• Access camera surveillance via the Internet.
Preliminary use-case diagram
for the SafeHome system
Scenario based Modelling
 Refining a Preliminary Use Case
Cockburn [Coc01b] recommends using a “brainstorming” session to derive a
reasonably complete set of exceptions for each use case
 Are there cases in which some “validation function” occurs during this use case?
 Are there cases in which a supporting function (or actor) will fail to respond
appropriately?
 Can poor system performance result in unexpected or improper user actions?
 Writing a Formal Use Case
Scenario based Modelling
Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)
Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame per second.
Activity Diagrams Swimlane Diagrams
Flow Oriented Modelling
 Creating a Data Flow Model
The DFD takes an input-process-
output view of a system.
Data Flow Diagram guidelines:
(1) the level 0 data flow diagram should depict the
software/system as a single bubble;
(2) primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate
processes, data objects, and data stores to be
represented at the next level;
(4) all arrows and bubbles should be labelled with
meaningful names;
(5) information flow continuity must be maintained
from level to level, and
(6) one bubble at a time should be refined.
Context-level DFD for the SafeHome security function
Flow Oriented Modelling
Level 1 DFD for SafeHome
security function
Flow Oriented Modelling
Level 2 DFD that refines the
monitor sensors process
Creating a Behavioural Model
The Behavioural Model indicates how software will respond to external events or stimuli.
Steps in creating a behavioural model are as follows,
1. Evaluate all use cases to fully understand the sequence of interaction within the
system.
2. Identify events that drive the interaction sequence and understand how these events
relate to specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioural model to verify accuracy and consistency.
Behavioural Modelling - State Diagram
State Diagram for Chess
State Diagram Notation UML
Event Types: Change, Time or Signal
Event
Behavioural Modelling
State diagram for the Control
Panel class
Behavioural Modelling in terms of Sequence Diagram
Sequence diagram (partial) for
the SafeHome security function
Additional Modelling Concepts
Aggregation
Composition
Additional Modelling Concepts
State Diagram for Telephone Line
Software Engineering and Project Management - Introduction, Modeling Concepts and Class Modeling + Building the Analysis Models

More Related Content

Similar to Software Engineering and Project Management - Introduction, Modeling Concepts and Class Modeling + Building the Analysis Models

Object Oriented Analysis and Design - OOAD
Object Oriented Analysis and Design - OOADObject Oriented Analysis and Design - OOAD
Object Oriented Analysis and Design - OOAD
PreethaV16
 
Object oriented analysis and design unit- iv
Object oriented analysis and design unit- ivObject oriented analysis and design unit- iv
Object oriented analysis and design unit- iv
Shri Shankaracharya College, Bhilai,Junwani
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)
Manoj Reddy
 
ASP.NET System design 2
ASP.NET System design 2ASP.NET System design 2
ASP.NET System design 2
Sisir Ghosh
 
Bt8901 objective oriented systems1
Bt8901 objective oriented systems1Bt8901 objective oriented systems1
Bt8901 objective oriented systems1
Techglyphs
 
CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V
pkaviya
 
fdocuments.in_unit-2-ooad.ppt
fdocuments.in_unit-2-ooad.pptfdocuments.in_unit-2-ooad.ppt
fdocuments.in_unit-2-ooad.ppt
RAJESH S
 
ArchitectureOfAOMsWICSA3
ArchitectureOfAOMsWICSA3ArchitectureOfAOMsWICSA3
ArchitectureOfAOMsWICSA3
Erdem Sahin
 
Object Oriented Design
Object Oriented DesignObject Oriented Design
Object Oriented Design
Sudarsun Santhiappan
 
Object Oriented Design
Object Oriented DesignObject Oriented Design
Object Oriented Design
Aravinth NSP
 
object modeling chapter 4 for students a
object modeling chapter 4 for students aobject modeling chapter 4 for students a
object modeling chapter 4 for students a
SaudFlash1
 
Ooad
OoadOoad
Ooad
gantib
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software Development
Rishabh Soni
 
Uml
UmlUml
Ch8
Ch8Ch8
SE - System Models
SE - System ModelsSE - System Models
SE - System Models
Jomel Penalba
 
OOP_Module 2.pptx
OOP_Module 2.pptxOOP_Module 2.pptx
OOP_Module 2.pptx
PrasenjitKumarDas2
 
OOAD unit1 introduction to object orientation
 OOAD unit1 introduction to object orientation OOAD unit1 introduction to object orientation
OOAD unit1 introduction to object orientation
Dr Chetan Shelke
 
Software Design Patterns - An Overview
Software Design Patterns - An OverviewSoftware Design Patterns - An Overview
Software Design Patterns - An Overview
Farwa Ansari
 
Object-oriented modeling and design.pdf
Object-oriented modeling and  design.pdfObject-oriented modeling and  design.pdf
Object-oriented modeling and design.pdf
SHIVAM691605
 

Similar to Software Engineering and Project Management - Introduction, Modeling Concepts and Class Modeling + Building the Analysis Models (20)

Object Oriented Analysis and Design - OOAD
Object Oriented Analysis and Design - OOADObject Oriented Analysis and Design - OOAD
Object Oriented Analysis and Design - OOAD
 
Object oriented analysis and design unit- iv
Object oriented analysis and design unit- ivObject oriented analysis and design unit- iv
Object oriented analysis and design unit- iv
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)
 
ASP.NET System design 2
ASP.NET System design 2ASP.NET System design 2
ASP.NET System design 2
 
Bt8901 objective oriented systems1
Bt8901 objective oriented systems1Bt8901 objective oriented systems1
Bt8901 objective oriented systems1
 
CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V
 
fdocuments.in_unit-2-ooad.ppt
fdocuments.in_unit-2-ooad.pptfdocuments.in_unit-2-ooad.ppt
fdocuments.in_unit-2-ooad.ppt
 
ArchitectureOfAOMsWICSA3
ArchitectureOfAOMsWICSA3ArchitectureOfAOMsWICSA3
ArchitectureOfAOMsWICSA3
 
Object Oriented Design
Object Oriented DesignObject Oriented Design
Object Oriented Design
 
Object Oriented Design
Object Oriented DesignObject Oriented Design
Object Oriented Design
 
object modeling chapter 4 for students a
object modeling chapter 4 for students aobject modeling chapter 4 for students a
object modeling chapter 4 for students a
 
Ooad
OoadOoad
Ooad
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software Development
 
Uml
UmlUml
Uml
 
Ch8
Ch8Ch8
Ch8
 
SE - System Models
SE - System ModelsSE - System Models
SE - System Models
 
OOP_Module 2.pptx
OOP_Module 2.pptxOOP_Module 2.pptx
OOP_Module 2.pptx
 
OOAD unit1 introduction to object orientation
 OOAD unit1 introduction to object orientation OOAD unit1 introduction to object orientation
OOAD unit1 introduction to object orientation
 
Software Design Patterns - An Overview
Software Design Patterns - An OverviewSoftware Design Patterns - An Overview
Software Design Patterns - An Overview
 
Object-oriented modeling and design.pdf
Object-oriented modeling and  design.pdfObject-oriented modeling and  design.pdf
Object-oriented modeling and design.pdf
 

More from Prakhyath Rai

Software Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity PlanningSoftware Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity Planning
Prakhyath Rai
 
Software Engineering and Project Management - Introduction to Project Management
Software Engineering and Project Management - Introduction to Project ManagementSoftware Engineering and Project Management - Introduction to Project Management
Software Engineering and Project Management - Introduction to Project Management
Prakhyath Rai
 
Software Engineering and Project Management - Software Testing + Agile Method...
Software Engineering and Project Management - Software Testing + Agile Method...Software Engineering and Project Management - Software Testing + Agile Method...
Software Engineering and Project Management - Software Testing + Agile Method...
Prakhyath Rai
 
Software Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringSoftware Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements Engineering
Prakhyath Rai
 
Ethics, Professionalism and Other Emerging Technologies
Ethics, Professionalism and Other Emerging TechnologiesEthics, Professionalism and Other Emerging Technologies
Ethics, Professionalism and Other Emerging Technologies
Prakhyath Rai
 
Internet of Things (IoT)
Internet of Things (IoT)Internet of Things (IoT)
Internet of Things (IoT)
Prakhyath Rai
 
Artificial Intelligence
Artificial IntelligenceArtificial Intelligence
Artificial Intelligence
Prakhyath Rai
 
Data Science
Data ScienceData Science
Data Science
Prakhyath Rai
 
Emerging Exponential Technologies - History & Introduction
Emerging Exponential Technologies - History & IntroductionEmerging Exponential Technologies - History & Introduction
Emerging Exponential Technologies - History & Introduction
Prakhyath Rai
 
Preparation of Project
Preparation of ProjectPreparation of Project
Preparation of Project
Prakhyath Rai
 
Small Scale Industry
Small Scale IndustrySmall Scale Industry
Small Scale Industry
Prakhyath Rai
 
Entrepreneurship
EntrepreneurshipEntrepreneurship
Entrepreneurship
Prakhyath Rai
 
Directing and Controlling
Directing and ControllingDirecting and Controlling
Directing and Controlling
Prakhyath Rai
 
Planning
PlanningPlanning
Planning
Prakhyath Rai
 
Introduction to Management
Introduction to Management Introduction to Management
Introduction to Management
Prakhyath Rai
 
Text MIning
Text MIningText MIning
Text MIning
Prakhyath Rai
 
Text Mining Framework
Text Mining FrameworkText Mining Framework
Text Mining Framework
Prakhyath Rai
 

More from Prakhyath Rai (17)

Software Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity PlanningSoftware Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity Planning
 
Software Engineering and Project Management - Introduction to Project Management
Software Engineering and Project Management - Introduction to Project ManagementSoftware Engineering and Project Management - Introduction to Project Management
Software Engineering and Project Management - Introduction to Project Management
 
Software Engineering and Project Management - Software Testing + Agile Method...
Software Engineering and Project Management - Software Testing + Agile Method...Software Engineering and Project Management - Software Testing + Agile Method...
Software Engineering and Project Management - Software Testing + Agile Method...
 
Software Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringSoftware Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements Engineering
 
Ethics, Professionalism and Other Emerging Technologies
Ethics, Professionalism and Other Emerging TechnologiesEthics, Professionalism and Other Emerging Technologies
Ethics, Professionalism and Other Emerging Technologies
 
Internet of Things (IoT)
Internet of Things (IoT)Internet of Things (IoT)
Internet of Things (IoT)
 
Artificial Intelligence
Artificial IntelligenceArtificial Intelligence
Artificial Intelligence
 
Data Science
Data ScienceData Science
Data Science
 
Emerging Exponential Technologies - History & Introduction
Emerging Exponential Technologies - History & IntroductionEmerging Exponential Technologies - History & Introduction
Emerging Exponential Technologies - History & Introduction
 
Preparation of Project
Preparation of ProjectPreparation of Project
Preparation of Project
 
Small Scale Industry
Small Scale IndustrySmall Scale Industry
Small Scale Industry
 
Entrepreneurship
EntrepreneurshipEntrepreneurship
Entrepreneurship
 
Directing and Controlling
Directing and ControllingDirecting and Controlling
Directing and Controlling
 
Planning
PlanningPlanning
Planning
 
Introduction to Management
Introduction to Management Introduction to Management
Introduction to Management
 
Text MIning
Text MIningText MIning
Text MIning
 
Text Mining Framework
Text Mining FrameworkText Mining Framework
Text Mining Framework
 

Recently uploaded

DBMS Commands DDL DML DCL ENTITY RELATIONSHIP.pptx
DBMS Commands  DDL DML DCL ENTITY RELATIONSHIP.pptxDBMS Commands  DDL DML DCL ENTITY RELATIONSHIP.pptx
DBMS Commands DDL DML DCL ENTITY RELATIONSHIP.pptx
Tulasi72
 
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdfGUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
ProexportColombia1
 
RECENT DEVELOPMENTS IN RING SPINNING.pptx
RECENT DEVELOPMENTS IN RING SPINNING.pptxRECENT DEVELOPMENTS IN RING SPINNING.pptx
RECENT DEVELOPMENTS IN RING SPINNING.pptx
peacesoul123
 
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
PradeepKumarSK3
 
PMSM-Motor-Control : A research about FOC
PMSM-Motor-Control : A research about FOCPMSM-Motor-Control : A research about FOC
PMSM-Motor-Control : A research about FOC
itssurajthakur06
 
Lecture 3 Biomass energy...............ppt
Lecture 3 Biomass energy...............pptLecture 3 Biomass energy...............ppt
Lecture 3 Biomass energy...............ppt
RujanTimsina1
 
Unblocking The Main Thread - Solving ANRs and Frozen Frames
Unblocking The Main Thread - Solving ANRs and Frozen FramesUnblocking The Main Thread - Solving ANRs and Frozen Frames
Unblocking The Main Thread - Solving ANRs and Frozen Frames
Sinan KOZAK
 
readers writers Problem in operating system
readers writers Problem in operating systemreaders writers Problem in operating system
readers writers Problem in operating system
VADAPALLYPRAVEENKUMA1
 
Thermodynamics Digital Material basics subject
Thermodynamics Digital Material basics subjectThermodynamics Digital Material basics subject
Thermodynamics Digital Material basics subject
JigneshChhatbar1
 
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-IDUNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
GOWSIKRAJA PALANISAMY
 
IWISS Catalog 2024
IWISS Catalog 2024IWISS Catalog 2024
IWISS Catalog 2024
Iwiss Tools Co.,Ltd
 
Press Tool and It's Primary Components.pdf
Press Tool and It's Primary Components.pdfPress Tool and It's Primary Components.pdf
Press Tool and It's Primary Components.pdf
Tool and Die Tech
 
OSHA LOTO training, LOTO, lock out tag out
OSHA LOTO training, LOTO, lock out tag outOSHA LOTO training, LOTO, lock out tag out
OSHA LOTO training, LOTO, lock out tag out
Ateeb19
 
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
Jim Mimlitz, P.E.
 
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
sanabts249
 
Conservation of Taksar through Economic Regeneration
Conservation of Taksar through Economic RegenerationConservation of Taksar through Economic Regeneration
Conservation of Taksar through Economic Regeneration
PriyankaKarn3
 
Jet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdfJet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdf
KIET Group of Institutions
 
Stiffness Method for structure analysis - Truss
Stiffness Method  for structure analysis - TrussStiffness Method  for structure analysis - Truss
Stiffness Method for structure analysis - Truss
adninhaerul
 
libro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdflibro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdf
celiosilva66
 
Design and Application of Side Channel Spillways
Design and Application of Side Channel SpillwaysDesign and Application of Side Channel Spillways
Design and Application of Side Channel Spillways
ahmed42488
 

Recently uploaded (20)

DBMS Commands DDL DML DCL ENTITY RELATIONSHIP.pptx
DBMS Commands  DDL DML DCL ENTITY RELATIONSHIP.pptxDBMS Commands  DDL DML DCL ENTITY RELATIONSHIP.pptx
DBMS Commands DDL DML DCL ENTITY RELATIONSHIP.pptx
 
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdfGUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
GUIA_LEGAL_CHAPTER-9_COLOMBIAN ELECTRICITY (1).pdf
 
RECENT DEVELOPMENTS IN RING SPINNING.pptx
RECENT DEVELOPMENTS IN RING SPINNING.pptxRECENT DEVELOPMENTS IN RING SPINNING.pptx
RECENT DEVELOPMENTS IN RING SPINNING.pptx
 
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
21EC63_Module1B.pptx VLSI design 21ec63 MOS TRANSISTOR THEORY
 
PMSM-Motor-Control : A research about FOC
PMSM-Motor-Control : A research about FOCPMSM-Motor-Control : A research about FOC
PMSM-Motor-Control : A research about FOC
 
Lecture 3 Biomass energy...............ppt
Lecture 3 Biomass energy...............pptLecture 3 Biomass energy...............ppt
Lecture 3 Biomass energy...............ppt
 
Unblocking The Main Thread - Solving ANRs and Frozen Frames
Unblocking The Main Thread - Solving ANRs and Frozen FramesUnblocking The Main Thread - Solving ANRs and Frozen Frames
Unblocking The Main Thread - Solving ANRs and Frozen Frames
 
readers writers Problem in operating system
readers writers Problem in operating systemreaders writers Problem in operating system
readers writers Problem in operating system
 
Thermodynamics Digital Material basics subject
Thermodynamics Digital Material basics subjectThermodynamics Digital Material basics subject
Thermodynamics Digital Material basics subject
 
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-IDUNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
UNIT I INCEPTION OF INFORMATION DESIGN 20CDE09-ID
 
IWISS Catalog 2024
IWISS Catalog 2024IWISS Catalog 2024
IWISS Catalog 2024
 
Press Tool and It's Primary Components.pdf
Press Tool and It's Primary Components.pdfPress Tool and It's Primary Components.pdf
Press Tool and It's Primary Components.pdf
 
OSHA LOTO training, LOTO, lock out tag out
OSHA LOTO training, LOTO, lock out tag outOSHA LOTO training, LOTO, lock out tag out
OSHA LOTO training, LOTO, lock out tag out
 
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
SCADAmetrics Instrumentation for Sensus Water Meters - Core and Main Training...
 
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
21CV61- Module 3 (CONSTRUCTION MANAGEMENT AND ENTREPRENEURSHIP.pptx
 
Conservation of Taksar through Economic Regeneration
Conservation of Taksar through Economic RegenerationConservation of Taksar through Economic Regeneration
Conservation of Taksar through Economic Regeneration
 
Jet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdfJet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdf
 
Stiffness Method for structure analysis - Truss
Stiffness Method  for structure analysis - TrussStiffness Method  for structure analysis - Truss
Stiffness Method for structure analysis - Truss
 
libro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdflibro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdf
 
Design and Application of Side Channel Spillways
Design and Application of Side Channel SpillwaysDesign and Application of Side Channel Spillways
Design and Application of Side Channel Spillways
 

Software Engineering and Project Management - Introduction, Modeling Concepts and Class Modeling + Building the Analysis Models

  • 1. Software Engineering & Project Management Module 2 Introduction, Modelling Concepts and Class Modelling: What is Object orientation? What is OO development? OO Themes; Evidence for usefulness of OO development; OO Modelling history. Modelling as Design technique: Modelling, abstraction, The Three models. Class Modelling: Object and Class Concept, Link and associations concepts, Generalization and Inheritance, A sample class model, Navigation of class models, and UML diagrams. Building the Analysis Models: Requirement Analysis, Analysis Model Approaches, Data Modelling Concepts, Object Oriented Analysis, Scenario-Based Modelling, Flow-Oriented Modelling, class Based Modelling, Creating a Behavioural Model. Presented By: Dr. Prakhyath Rai
  • 2. Introduction Object oriented means organizing software as a collection of discrete objects that incorporate both data structure and behaviour. Characteristics of OO approach:  Identity - Data is quantized into discrete, distinguishable entities called object. Examples: first paragraph, a white rook etc.  Classification - Objects with the same data structure (Attributes) and behaviour (Operations) are grouped into a class. Examples: Student, Paragraph  Inheritance - Sharing of attributes and operations (Features) among classes based on a hierarchical relationship. A superclass has general information that subclass refine and elaborate. Example: Window (Superclass) -> ScrollingWindow + FixedWindow (Subclasses)  Polymorphism - Same operation may behave differently for different classes. Example: Move operation of Queen and Move operation of Pawn. Operation: Procedure or transformation an object performs or subjected to Method: An implementation of an operation by a specific class
  • 3. OO Development Development – Software lifecycle: Analysis, Design, and Implementation Essence of OO Development – Identification and Organization of application concepts instead of final representation in programming language OO Concepts apply throughout the system development life cycle – from analysis through design to implementation 1. Modelling Concepts, Not Implementation  Addressing frontend conceptual issues rather than backend implementation details  Serves as a medium for specification, analysis, documentation, interfacing and development  Aids specifiers, developers and customers express abstract concepts clearly and facilitates communication 2. OO Methodology  System Conception – Starts with conceiving an application and formulating requirements  Analysis – Analysts scrutinizes and rigorously restates requirements by construction models from system conception
  • 4. OO Development 2. OO Methodology  System Design – High level strategy: The System Architecture  Class Design – Adds details to system design analysis model, Focus on data structures and algorithms for each class  Implementation – Translates classes and relationships from class design into a particular programming language 3. Three Models – To describe systems from different viewpoints  Class Model – Describes static structure of the objects in the system and their relationship (Class Diagram)  State Model – Describes the aspects of the object that change over time (State Diagram)  Interaction Model – Describes how objects in the system cooperate to achieve broader results (Use- Case Diagram, Sequence Diagram, Activity Diagram)
  • 5. OO Themes 1. Abstraction  Abstraction means focusing on what an object is and does, before deciding how to implement it.  Focussing on what an object is and does, before deciding on implementation 2. Encapsulation  Information Hiding - separates the external aspects of an object that are accessible to other objects, from the internal implementation details that are hidden from other objects. 3. Combining Data and Behaviour  The caller of an operation need not consider how many implementations exist.  Operator polymorphism shifts the burden of deciding what implementation to use from the calling code to the class hierarchy.
  • 6. OO Themes 4. Sharing  OO technologies promote sharing at different levels.  Inheritance of both data structure and behaviour lets subclasses share common code. This sharing via inheritance is one of the main advantages of OO languages.  OO development not only lets you share information within an application but also offers the prospect of reusing designs and code on future projects. 5. Emphasis on the Essence of an Object  OO technology stresses what an object is, rather than how it is used. The uses of an object depend on the details of the application and often change during development. 6. Synergy  Identity, classification, polymorphism and inheritance characterize OO languages. Each of these concepts can be used in isolation but together they complement each other synergistically.
  • 7. Evidence for Usefulness of OO Development 1. Testing a physical entity before building it 2. Communication with Customers 3. Visualization 4. Reduction of Complexity Abstraction:  Selective examination of certain aspects of a problem.  The goal of abstraction is to isolate those aspects that are important for some purpose and suppress those aspects that are unimportant.  A good model captures the crucial aspects of a problem and omits the others.
  • 8. The Three Models Model a system with related but different viewpoints 1. Class Model  Represents the static, structural and data aspects of a system 2. State Model  Represents the temporal, behavioural, control aspects of a system 3. Interaction Model  Represents the collaboration of individual objects, interaction aspects of a system The 3 kinds of models separate a system into distinct views. Example: Class model attaches operations to classes and state and interaction models elaborate the operations
  • 9. Class Model  Describes the structure of objects in a system - their identity, their relationships to other objects, their attributes and their operations.  Goal in constructing a class model is to capture those concepts from the real world that are important to an application.  Class diagrams express the class model. Classes define the attribute values carried by each object and the operations that each object performs or undergoes.  The class model provides context for the state and interaction models
  • 10. State Model  Describes those aspects of objects concerned with time and the sequencing of operations – events that mark changes, states that context for events and the organization of events and states.  State diagrams express the state model. Each state diagram shows the state and event sequences permitted in a system for one class of objects.  The state model captures control, the aspect of a system that describes the sequence of operations that occur, without the regard for what the operations do, what they operate on, or how they are implemented.
  • 11. Interaction Model  Describes interactions between objects – how individual objects collaborate to achieve the behaviour of the system.  Use cases, sequence diagrams and activity diagrams document the interaction model. • Use cases document major themes for interaction between the system and outside actors. • Sequence diagrams show the objects that interact and the time sequence of their interactions. • Activity diagrams show the flow of control among the processing steps of a computation.
  • 12. Relationship among the Three Models Class Model  The Class model describes data structure on which the state and interaction models operate.  The operations in the class model corresponds to events and actions. State Model  The state model describes the control structure of objects.  The state model shows decisions that depend on object values and causes actions that change object values and state. Interaction Model  The interaction model focusses on the exchanges between objects and provides a holistic overview of the operation of a system.
  • 13. Class Modelling - Concepts  Class & Object Diagram  Association & Links  Multiplicity  Multiplicity & Visibility of Attributes  Association End Names  Association Classes  Qualified Associations  Ordering, Bags & Sequence  Generalization and Inheritance  Overriding Features
  • 18. Sample Class Diagrams Class Model of Windowing System
  • 19. Sample Class Diagrams Class Model for Managing Credit Card Accounts
  • 20. Navigation of Class Model - OCL Attributes: You can traverse from an object to an attribute value.  Syntax: source object, followed by a dot and then the attribute name.  Example: aCreditCardAccount. maximumCredit Operations: You can also invoke an operation for an object or a collection of objects.  Syntax: source object or object collection, followed by a dot and then the operation. The operation must be followed by parentheses, even if it has no arguments to avoid confusion with attributes.  The OCL has special operations that operate on entire collections. The syntax for a collection operation is the source object collection followed by -> and then the operation.
  • 21. Navigation of Class Model - OCL Simple Associations: A 3rd use of dot notation is to traverse an association to a target end.  Example: aCustomer.MailingAddress yields a set of addresses for a customer. In contrast,  aCreditCardAccount.MailingAddress yields a single address. Qualified Associations: A qualifier lets you make a more precise traversal. The expression  aCreditCardAccount.Statement[30 November 1999] finds the statement for a credit card account with the statement date 30 November 1999. The syntax is to enclose the qualifier value in brackets. Generalizations: Traversal is implicit for the OCL notation.  Filters: OCL has several kinds of filters, most common of which is the select operation.  Example: aStatement.transaction -> select(amount>$100) finds the transactions for a statement more than $100.
  • 22. Examples of OCL Expressions 1. What transactions occurred for a credit card account within a time interval?  aCreditCardAccount.Statement.Transaction -> select(aStartDate <= transactionDate and transactionDate <= anEndDate) 2. What volume of transactions were handled by an institution in the last year?  anInstitution.CreditCardAccount.Statement.Transaction -> select(aStartDate <= transactionDate and transactionDate <= anEndDate).amount->sum( ) 3. What customers patronized a merchant in the last year by any kind of credit card?  aMerchant.Purchase -> select(aStartDate <= transactionDate and transactionDate <= anEndDate).Statement.CreditCardAccount.MaillingAddress.Customer -> asset( ) 4. How many credit card accounts does a customer currently have?  aCustomer.MaillingAddress.CreditCardAccount -> size( ) 5. What is the total maximum credit for a customer, for all accounts?  aCustomer.MaillingAddress.CreditCardAccount.maximumCredit -> sum( )
  • 23. Requirement Analysis Purpose of Requirements Analysis:  Specification of software’s operational characteristics  Indication of software’s interface with other system elements  Establishment of constraints for the software Modelling Techniques:  Scenario-based models: View from various system “actors”  Data models: Depiction of the information domain  Class-oriented models: Object-oriented classes and collaborations  Flow-oriented models: Functional elements and data transformation  Behavioural models: Software behaviour due to external “events” Importance:  Provides design information for architectural, interface, and component levels  Facilitates assessment of software quality
  • 24. Requirement Analysis Scenario-Based Modelling:  Increasingly popular  Understanding requirements from actor perspectives  Examples: Use cases, UML models, Swimlane diagram Data Modelling:  Managing complex information spaces  Critical for applications involving data manipulation Class Modelling:  Representing object-oriented classes (attributes and operations)  Collaboration among classes for system functionality
  • 25. Objectives of Requirements Model Objectives:  Describe what the customer requires  Establish a basis for creating a software design  Define requirements for validation once the software is built Bridge Between System Description and Design:  Requirements model links system/business functionality with software design  Ensures traceability from analysis to design
  • 26. Requirement Model Rules Rules of thumb that followed when creating the analysis model:  The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.  Each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behaviour of the system.  Delay consideration of infrastructure and other nonfunctional models until design. • Example: Database classes, access functions, and behaviour  Minimize coupling throughout the system. • Represent relationships between classes and functions but reduce high levels of interconnectedness  Be certain that the requirements model provides value to all stakeholders.  Keep the model as simple as it can be.
  • 27. Domain Analysis  Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain.  [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks.
  • 28. Requirements Modelling Approaches Elements of the analysis model Structured Analysis Focus: Data and processes as separate entities Data Objects: Modelled by attributes and relationships Processes: Modelled by how they transform data objects Object-Oriented Analysis Focus: Definition of classes and their collaboration Tools: UML and the Unified Process Class-Based Elements: Objects, operations, relationships, collaborations Combined Approach Hybrid Model: Features of both structured and object- oriented analysis Stakeholder Focus: Best combination of representations for requirements and design
  • 29. Data Modelling Concepts Data Objects  A data object is a representation of composite information that must be understood by software.  A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file). Data Attributes Data attributes define the properties of a data object and take on one of three different characteristics. They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make reference to another instance in another table.
  • 30. Data Modelling Concepts Relationships  Connection between data objects Relationships between data objects Tabular representation of data objects
  • 31. Class based Modelling Identifying Analysis Classes  External Entities – Devices, People  Things – Reports, Letters, Signals  Occurrences or Events  Roles – Manager, Accountant  Organizational Units – Department, Division  Places – Administrative Block, Lab  Structures – Sensors, Vehicles Coad and Yourdon Criteria / Characteristics  Retained information  Needed services  Multiple attributes  Common attributes  Common operations  Essential requirements
  • 34. Class based Modelling Class-Responsibility-Collaborator (CRC) Modelling A set of class-responsibility collaborator index cards can be used to define relationships between classes.
  • 35. Class based Modelling Association & Dependencies Dependencies Multiplicity
  • 36. Class based Modelling Analysis Packages: Analysis packages are used to categorize and group classes in a manner that makes them more manageable for large systems.
  • 37. Scenario based Modelling  Creating a Preliminary Use Case Consider the SafeHome system, the homeowner has following functionalities, • Select camera to view. • Request thumbnails from all cameras. • Display camera views in a PC window. • Control pan and zoom for a specific camera. • Selectively record camera output. • Replay camera output. • Access camera surveillance via the Internet. Preliminary use-case diagram for the SafeHome system
  • 38. Scenario based Modelling  Refining a Preliminary Use Case Cockburn [Coc01b] recommends using a “brainstorming” session to derive a reasonably complete set of exceptions for each use case  Are there cases in which some “validation function” occurs during this use case?  Are there cases in which a supporting function (or actor) will fail to respond appropriately?  Can poor system performance result in unexpected or improper user actions?  Writing a Formal Use Case
  • 39. Scenario based Modelling Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV) Actor: homeowner 1. The homeowner logs onto the SafeHome Products website. 2. The homeowner enters his or her user ID. 3. The homeowner enters two passwords (each at least eight characters in length). 4. The system displays all major function buttons. 5. The homeowner selects the “surveillance” from the major function buttons. 6. The homeowner selects “pick a camera.” 7. The system displays the floor plan of the house. 8. The homeowner selects a camera icon from the floor plan. 9. The homeowner selects the “view” button. 10. The system displays a viewing window that is identified by the camera ID. 11. The system displays video output within the viewing window at one frame per second.
  • 41. Flow Oriented Modelling  Creating a Data Flow Model The DFD takes an input-process- output view of a system. Data Flow Diagram guidelines: (1) the level 0 data flow diagram should depict the software/system as a single bubble; (2) primary input and output should be carefully noted; (3) Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level; (4) all arrows and bubbles should be labelled with meaningful names; (5) information flow continuity must be maintained from level to level, and (6) one bubble at a time should be refined. Context-level DFD for the SafeHome security function
  • 42. Flow Oriented Modelling Level 1 DFD for SafeHome security function
  • 43. Flow Oriented Modelling Level 2 DFD that refines the monitor sensors process
  • 44. Creating a Behavioural Model The Behavioural Model indicates how software will respond to external events or stimuli. Steps in creating a behavioural model are as follows, 1. Evaluate all use cases to fully understand the sequence of interaction within the system. 2. Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3. Create a sequence for each use case. 4. Build a state diagram for the system. 5. Review the behavioural model to verify accuracy and consistency.
  • 45. Behavioural Modelling - State Diagram State Diagram for Chess State Diagram Notation UML Event Types: Change, Time or Signal Event
  • 46. Behavioural Modelling State diagram for the Control Panel class
  • 47. Behavioural Modelling in terms of Sequence Diagram Sequence diagram (partial) for the SafeHome security function
  • 49. Additional Modelling Concepts State Diagram for Telephone Line

Editor's Notes

  1. Although a significant amount of time is spent obtaining and preparing data for machine learning (ML), the bulk of the ML workflow is focused on building, training, deploying, and monitoring “models.” The term “models” gets used frequently and is a core concept. The essence of machine learning can be boiled down to three things: An organization has historical data Patterns exist in this data Once a pattern is identified, it can be used to make predictions about future actions or behaviors For people familiar with Yahoo or Google Mail, they will have probably seen a folder named “Junk” or “Spam.” When looking inside this folder, people generally find it contains email messages they didn’t really want to receive. When people continuously throw away messages that come from the same sender without reading them, at some point they will discover that these messages are automatically placed in the Junk/Spam folder by their email provider. It’s a good bet that an ML algorithm was used create a model that performs these “spam filtering” tasks. Therefore, spam filtering is an excellent example to illustrate what a machine learning model is. In the illustration shown on this slide, a learning model consists of two components – an algorithm a data scientist chose in order to find a pattern that exists (in this case, a pattern that indicates whether an incoming email message is spam), based on the probability that it will do the task it’s expected to do once it has been trained. ML models can be thought of as having two phases: a training phase and a prediction or scoring phase. Going back to the email spam filtering example, a typical spam email message contains words like “sweepstakes,” “inheritance,” or “Viagra.” On the other hand, these words probably don’t appear very often in emails people are likely to be considered valid. During the model training phase, the data scientist would tell the chosen algorithm to look at historical data and note the probability with which each of these words appear in both spam and valid email messages. For example, if it is known that 6,000 out of 10,000 messages in the training data set are spam and if the word “sweepstakes” appears in 2,000 spam emails and 10 valid emails, the probability that a spam email message contains the word sweepstakes is 0.333 (2000/6000 = 0.333). And the probability that this word will appear in a valid email message is 0.0025 (10/4000 = 0.0025). Thus, if an incoming email message contains the word “sweepstakes,” the probability that the message is spam is much higher than the probability that the message is valid. Notes: Machine learning (ML) refers to a broad set of techniques to train a computer to learn from its inputs, using existing data, and one or more “training” methods, instead of being explicitly programmed. ML helps a computer to achieve AI. An algorithm is a procedure used for solving a problem or performing a computation. Algorithms act as an exact list of instructions that conduct a sequence of specified actions in either hardware- or software-based routines.