Software Design by Dr. Eitan Hadar

1. Software DesignbyDr. Eitan Hadar     Email: eitan@netanya.ac.il Web: www.netanya.ac.il/Eitan/

2. Introduction toRequirements Analysis

3. Requirements Software Design - Dr Eitan Hadar (c)

4. Requirements Analysis • The analyst can sit with the customer and ask probing questions, such as these: • What are the primary functions of the system? • What are the secondary functions of the system? • Why is this system being built? What is it replacing and why? • The analyst must then identify the following for each use case: • The role the actors and system play in each scenario • The interactions (flows) necessary to complete the scenario • The sequence of events and data needed to realize the scenario • The variations on the scenario that are possible (other related scenarios) Software Design - Dr Eitan Hadar (c)

5. OOP and Changes to User Requirements • Some characteristics of requirements changes: • Introduction of new entities (similar to existing ones) • Changes to the relationships (is-a / has-a) between entities • Different interactions • … • But, Very little change to the data model • Q: What type of changes is supported by OOP? Software Design - Dr Eitan Hadar (c)

6. OOP vs older paradigms • Traditional paradigm: • Identify the algorithm (functions) required to solve the problem: • Functional decomposition • Control flow • Identify the data structures needed by the functions. • Object-Oriented paradigm: • Identify the abstract objects (data) that represent the problem domain. • Identify the abstract operations supported by the objects, i.e., define the interface to the objects. • The problem solution is a sequence of calls to objects. Verbs = Procedures & Functions Nouns = Data Verbs Supported by Nouns = Function-oriented Nouns Supported by Verbs = Object-oriented Code Data Software Design - Dr Eitan Hadar (c)

7. Use Case Requirement model • Use Case Model: • Requirement gathering tool • Define roles of users • Ask what each user wants to accomplish by using the system (The “Goal”) • Write it in a the user’s language • Users are at the center • Deals with problem-space interfaces Software Design - Dr Eitan Hadar (c)

8. Create Use Case Model • Identify Use Cases and associated Actors • Decompose UC’s with “generalization”, “uses” and “extends” relations • Notice: • use cases can initiate themselves (usually based on the passage of time) and often interact with many actors Software Design - Dr Eitan Hadar (c)

9. Use Case as a Driving Force! (1/3) Problem: How to trace down requirements to Implementation (minimum defects) Solution: UML Use case dependency trace! Software Design - Dr Eitan Hadar (c)

10. Use Case as a Driving Force! (2/3) • Analysis • Suggest large-scale partitioning of the domain • Provide structuring of analysis objects • Clarify system and object responsibilities • Capture and clarify new features as they are added during development • Validate analysis model • Design • Validate the elaboration of analysis models in the presence of design objects Software Design - Dr Eitan Hadar (c)

11. Use Case as a Driving Force! (3/3) • Coding • Clarify purpose and role of classes for coders • Focus coding efforts • Testing • Provide primary and secondary test scenarios for system validation • Deployment • Suggest iterative prototypes for spiral development Software Design - Dr Eitan Hadar (c)

12. UC Software Design - Dr Eitan Hadar (c)

13. Use Case Relations – do not overuse! Software Design - Dr Eitan Hadar (c)

14. Activity Diagram - Scenario elaboration • Flow of activities involved in a single process • Captures dynamic behavior (activity-oriented) • An activity graph is: • A variation of a state machine • States represent the performance of actions or sub-activities • Transitions are triggered by the completion of the actions or sub-activities Software Design - Dr Eitan Hadar (c)

15. Software Design - Dr Eitan Hadar (c)

16. Software Design - Dr Eitan Hadar (c)

17. Actors • Actors may be human users or externally visible subsystems and devices, such as sensors and actuators • Common mistake to assume that actors must be people Software Design - Dr Eitan Hadar (c)

18. Actors (2) • Whenever the actor is a deviceused by a human or the human itself depends on the scope of the system. • If the system development includes the development of devices that interact with a human, then the human is the actor. • If the system must interact with existing (or separately supplied) devices that are, in turn, used by human users, then the interface devices are the actors because they are the first thing outside the system scope that actually interacts with the system. Software Design - Dr Eitan Hadar (c)

19. Messages • During Analysisidentify the semantics and characteristics of the individual messages (including those associated with signaling the occurrence of events) that pass between the system and its set of actors • A message is an abstraction of the exchange of information between a sender and a receiver • Pre- and post-conditional invariants, which are the states assumed to be true prior to sending and after receipt of a message Software Design - Dr Eitan Hadar (c)

20. Type of Messages • A function call • Mail via a real-time operating system (RTOS) • An event via a RTOS • An interrupt • A semaphore-protected shared resource service call • An Ada rendezvous • A remote procedure call (RPC) in a distributed system Software Design - Dr Eitan Hadar (c)