1

• Every system is a sub-system that is part of a larger system
• Interconnected parts aiming a common goal
• Hierarchy – Tree structure
• Divide and Conquer
2

Source: S. Easterbrook - UofT
• Most used tool for rationalized software
• Why?
– Allows to ignore inconvenient details
– Allows different entities do be treated equally
– Simplify many types of analysis
• On Coding
– Abstraction is the process of naming composite objects and deal with they as unique entities
• Don’t Solve problems
– But simplifies !
3

• Model: It is an abstraction from reality emphasizing specific characteristics
• One single model is not enough to represent all the characteristcs a system must have
• Models are useful to organize information and to specify requirements
• Model can guide elicitation
– Helps to find new questions
4

• Represent a viewpoint for the environment before the system is implemented
• Show alternative solutions
• Show future needs
• Represent parts of the system
• Allow to incrementally deal with complexity – from the more abstract level to the detailed level
• Provide quantitative information about the scope and complexity of the problem
• Allow to communicate with developers and stakeholders
5

• Natural Language
– Easy to understand and to communicate with stakeholders
– Good for elicitation not that much for modelling
– Ambiguity is always a problem
6

7

• Semi-Formal Notation
– Captures structure and some semantics
– Allows some reasoning (some more than others)
– Favor consistency checking
• Diagrams and tables for example
– Visual
• Also facilitates communication with some stakeholders
8

• Formal Notation
– Precise semantics
– Allows model checking
– Allows extensive reasoning
9

• Formalism seeks minimize
– Ambiguity
– Inconsistency
– Omission
• Unique and well defined interpretation of the specification
• Rigor and formalism in specification aims at maximize the above qualities
10

• Problem
– Formal problems are hard to understand
•  e
 exemplar

(
 b
 library
 belongs( b.code,e.n_item
))
• Possible alternatives
– Use a semiformal specification during development
– Use of formal specification only to represent requirements and as a guide to design the modeling, implementation and tests
11

• Systems
• Objects
• Networks
• Agents
• Goals
12

• Old Times “divide et impera”
DIJKSTRA http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html
)
(programming considered a human activity)
• Specify the parts individually
• Satisfied? The Problem is solved?
If one part is still complex: Subdivide it.
13

• Top down Approach
• Disadvantages (Michael Jackson)
– Choosing is a risk
• The big decision is about what division should I make ?
• Decision is made too early
– Lack of knowledge
– Lack of understanding about the problem
– Real world is not always organized in a hierarchical form
• Parallel and concurrent strucutres
14

• Decompose the problem until:
– Every sub-problem is in the same level of detail
– Every sub-problem can be solved in an independent way
– Solutions for each sub-problem can be combined to solve the original problem
• Advantages
– Different people can work different sub-problems
– Facilitates parallelism
– Maintenance gets easier
• Disadvantages
– Solutions for sub-problems may not combine in such a way that would solve the problem
– Real world structure is not hierarquical [Michael Jackson]
15

function 2
Input conction function 1 conection conection function 4 conection
Output function 3
16

Source: S. Easterbrook - UofT
• Decomposition may be of great help
– Restaurant Menu
• Not always work
– Theatre Play
Role actor1
Joint parts
Write Role actor2
Roles
Role actor3
• Not always Possible
– Complex problems
– Atomic problems (add 1+1)
17

Computational World
Real World
Problems
Semantic Gap
Solutions
Requirements
Modeling
18

• The world is composed by Objects (+-)
• Objects are independent, have memory and behavior
• Objects communicate through messages
• Objects are organized in class
(Generalizations)
19

• Disadvantages (Jackson):
– The object idea comes from programming languages and can not be mapped to most of the individuals in the real world
• What was the last time you sent a message to your car?
• When the sun rises does it send a message to birds to sing ?
20

“ The world outside the machine is very rich, full of whim and recalcitrantly multifaceted to be captured in the form of objects.
M. Jackson
21

• Goal-Oriented Models
• For Example KAOS
– System goals x Client Goals
22

• Developed in the early 90’s
• Has been applied to a number of industrial cases
• Is supported by a stable and well defined tool
23

• Informal Goal structuring model
• Producing Formal definitions in temporal logic for each entity
24

25

• Actors and devices are very important
• They are responsible for carrying out the tasks
• Agent-Oriented Models
• New properties
– Pro-Active
– Autonomous
– Distributed
– Intelligent, etc
26

• Models about organizational aspects
• Must portrait aspects relate to management/business
• Software Engineering models are restricited
• Modelling elements linked to organizational concepts are needed
27

possui has tem has benchmarking input
Client
28

• Policies (not procedures)
• identification
– limits
– responsibilities
– tights
• Stability
29

Business Rules
Functional Business
Rules
Non-Functional
Business Rules
Rules from the
Macrosystem
Quality
Rules
30

• A meeting can be rescheduled or canceled
• Supervisors answer to the VP
• CIT and CPP must be deducted every month
31

• Need Models (languages to build a software system)
• Requirements Model
• Specification Model
• Multi-purpose models
32

• Representation
• Organization
• Storage
Perspective about the
Product
33

• Lexicon
• Scenarios
• Sentences
• Requirements
Documents
• Glossary
34

Language Extended Lexicon
(LEL)
• Technique that aims to describe the symbols a a certain language. LEL’s main idea is the existence of an application language. This idea departs from the notion that in the UofD there is one (or more) cultures (social group) and each has its own language.
• Thus, the main objective to be followed by REs is the identification of words or sentences that are peculiar to the social environment under study. Only after these words and sentences are identified the RE will search for their meaning.
35

Language Extended Lexicon
• Use one or more technique for fact gathering
(interviews, observation, document reading)
• Target: Words or sentences that seem to have a special/relevant meaning in the application
• Words or sentences that are frequently used or that brings doubts or that seem to be out of context.
• List of words and sentences.
• Big difference: Elicit functions vs Elicit symbols
.
36

Language Extended Lexicon
• Each symbol is describe with Notions and
Behavioral Responses. Notion represents what the symbol means (denotation). Behavioral Responses describe the effects from the use of this symbol.
Characterize constraints imposed to the symbol or imposed by the symbol
37

Language Extended Lexicon
• Circularity and Minimum vocabulary principles.
– Minimal Vocabulary: Refers to the sole use of frequent words with clear meaning and that are part of a restricted vocabulary
– Circularity: Refers to the use of symbols from the language (LEL symbols) to described notions and behavioral responses
• Studies show that while explaining a symbol actors (stakeholders/users) use symbols from their language.
38

LEL
Notion Behavioral Responses
Subject Who is the subject What actions are executed
Verb Who does, when it happens and what procedures are involved
What are the consequences in the environment (other actions that might take place) and what are the new states
Actions that can be applied to the object
Object Define the object and identify other objects that may have any relationship with this one
State What does it means and which actions led to this
Identify other states and actions that may happen other caused by a state transition
39

Language Extended Lexicon

Renew Book
• Notions Book exemplar is rented to a library user
– User wants to keep the book exemplar longer.
•
Behavioral Responses :
– Library Employee changes return date for the book exemplar
40

Language Extended Lexicon

Return Date
•
Notion
– Established Data to return rented book
• Behavioral Response :
– If return date is prior to current date the book exemplar is overdue
41

42

• For some time they were seen as elicitation techniques (Analysis)
• Range from the more formal to the most used by developers
• Some of them will be covered here:
– DFD, Decision Table, State Chart , External
Events, ER, Data Dictionaries.
43

• Information structure
– Entity relationship diagram
– Class Diagram
• Process and Information Flow
– Dafaflow diargams
– UML activity diagram
• System Behavior
– Statecharts
– Sequence diagrams
44

1
EE i
1
X i
2
EE
2
 process (task, action, activity)

Data storage i
1
X i
2
X y
45


External Entities (origem/destino)

Data Flow i
EE
1
46

- Functional Decomposition
- Context Diagram
Level 0, 1, 2, …
- Every information that is inputted has to be somehow used
- Stop Condition for decomposition – When I can describe the process within one page using pseudocode a
X b a
1 a
2
X
1 xa
1
X
2 xa
2
X
3 b
47

Example
Finance
Management
Employee
Money Order
Worked-hours tax
Pay Salaries
Total-Payement salaries info-employee
Manager
Human
Resources
48

Worked-hours salaries
Tax info-employee
Calculate
Payment
Groos-salary
Deduct
Tax
Net-salary
Generate
Money
Order
Money
Order
Pay Salaries total-paid
Add to Total
Total-payment
49

Worked-hours
Separate
Regular
Hours info-employee
Overtime salaries
Regular-hours
Calculate
Individual salaries
Regular-salary
Salary-overtime
Calculate
Gross
Salary
Gross-Salary
Calculate Payment
50

- Rules:
- Names:
- Process: verbal phrase
- Flow: substantive or substantivated phrase (use hyphens)
- Data Storage: Same as in Flow
-External Entity: substantive or substantivated phrase playing the role of subject
- Use different names (Output is always different from input)
.
51

• Key point: DFDs are the center of SAD
• Mainly used for information systems\
– But there are adaptations for real-time systems
• Process
– Define current Physical system (concrete)
– Define current logical system (Abstraction)
– Create New logical system
– Create New physical system
52

Evaluation of SA as a whole
• Pros
-easy to learn
-Automated Tool support
- Use of abstraction and decomposition
-Facilitates communication
-Clear definition of system boundaries
• Cons
-Confusion between Modelling the problem and Modelling the solution
-Models the system but not the application domain
-Timing issues are invisible
53

• Objective
To give a description for the date used in the software and how these data relate to each other. It is used to describe the Data base conceptual model
• Concepts
Entity [type]
Relationship
 cardinality (1:1, 1:M, M:N)
Attributes ( characterize entities or relationships)
54

• Exemple
Code time name
N M days Course enrolls
Student address
.
N room number teaches
1
Prof.
address name group
Prof.ID
55

Entity Relationship Model
• Pros
-well known
-data map
- easy to translate to a physical implementation
• Cons
Almost can‘t represent constraints
Doesn‘t model behavior
- weak semantics (based on hypothesis and natural language)
56

57

Making a Decision Table (from the logic on previous slide)
• Step 1
– Identify the decision variables
• Year to date purchases (YTD)
• Number of items ordered
• Delivery date
• Step 2
– Put variable with fewest possible value ranges in the first row of the table
• In this example could put either YTD or number of items
58

• Table so far is just one row:
YTD Purchases > $250 YES NO
• Step 3 – put variable with next fewest possible value ranges as next row in the table, to now get:
YTD Purchases > $250 YES NO
Number of Items (N) N <=3 N>=4 N<=3 N>=4
• Step 4 – keep inserting rows as in step 3 until all decision variables are included in the table 59

• Table now looks like:
YTD Purchases > $250 YES NO
Number of Items (N) N <=3 N>=4 N<=3 N>=4
Delivery Day Next 2 nd 7 th Next 2 nd 7 th Next 2 nd 7 th Next 2 nd 7 th
• Step 5 – Finally put as bottom row of the table the actions for each of the possible conditions – see next slide (fig. 6-22) from the text for the complete table
60

61

Decision Tree
• A graphical description of process logic that uses lines organized like branches of a tree
• Decision table is more compact but decision tree is easier to read
• Sometimes an analyst might use all 3 ways
– Structured English
– Decision Table
– Decision Tree
• Decision tree can be developed in essentially same way as a decision table (only difference is that it runs horizontally – i.e. Rows in a decision table are columns in the tree – just flip the table sideways and you get the tree)
62

63

Decision Tables
• Pros
- easy to create
- easy to check completeness
• Cons
- Lack of details on actions and data
- restricited to small/medium problems
64