CSC 205: Software Engineering I

1. CSC 205: Software Engineering I Dr. Franz J. Kurfess Computer Science Department Cal Poly

2. Introduction Requirements Engineering Requirements Elicitation Requirements Management Project Management System Design Methods and Notations Design Models and Object-Oriented Design Design Analysis and Formal Specification Design Analysis and Verification Conclusions Course Overview

3. Motivation Objectives Context Models Behavioral Models Data Models Object Models CASE workbenches Important Concepts and Terms Chapter Summary Chapter OverviewSystem Design Methods and Notations

4. Logistics • Midterm • Friday, February 16 • Project Presentations • probably Friday, Feb. 9 • with Lori Fisher

5. Motivation • it is helpful to consider a system from different perspectives in order to get a better understanding • various methods concentrate on specific aspects • components • functions • data flow • data structures • tools affiliated with these methods help with the capturing of system information

6. Objectives • to explain why the context of a system should be modeled as part of the re process • to describe behavioral modeling, data modeling and object modeling • to introduce some of the notations used in the Unified Modeling Language (UML) • to show how CASE workbenches support system modeling [Sommerville 01]

7. System Models • abstract descriptions of systems whose requirements are being analyzed [Sommerville 01]

8. System Modeling • helps the analyst to understand the functionality of the system • models can be used to communicate with customers • different models present the system from different perspectives • external perspective • the system’s context or environment • behavioral perspective • the behavior of the system • structural perspective • the system or data architecture [Sommerville 01]

9. Structured Methods • incorporate system modeling as an inherent part of the method • these methods define • a set of models • a process for deriving these models and rules • guidelines that should apply to the models • CASE tools support system modeling as part of a structured method [Sommerville 01]

10. Structured Method Weaknesses • do not model non-functional system requirements • do not usually include information about whether a method is appropriate for a given problem • may produce too much documentation • the system models are sometimes too detailed and difficult for users to understand [Sommerville 01]

11. Model Types • data processing model • how the data is processed at different stages • composition model • how entities are composed of other entities • architectural model • principal sub-systems • classification model • entities with common characteristics • stimulus/response model • the system’s reaction to external or internal events [Sommerville 01]

12. Context Models • used to illustrate the boundaries of a system • social and organizational concerns may affect the decision on where to position system boundaries • architectural models • show the system and its relationship with other systems [Sommerville 01]

13. ATM System Context Security System Branch Accounting System Account Data Base Automated Teller Branch Counter System Usage Data Base Maintenance System [Sommerville 01]

14. Process Models • show the overall process and the processes that are supported by the system • data flow models • may be used to show the processes and the flow of information from one process to another [Sommerville 01]

15. Equipment Procurement Process [Sommerville 01]

16. Behavioral Models • behavioral models are used to describe the overall behavior of a system • two types of behavioral model are shown here • data processing models • show how data is processed as it moves through the system • state machine models • show how the system responds to events • both of these models are required for a description of the system’s behavior [Sommerville 01]

17. Data-processing Models • data flow diagrams • used to model the system’s data processing • show the processing steps as data flows through a system • intrinsic part of many analysis methods • simple and intuitive notation that customers can understand • show end-to-end processing of data [Sommerville 01]

18. Order Processing DFD slightly different notation from examples in the previous chapter [FJK] [Sommerville 01]

19. Data Flow Diagrams • DFDs model the system from a functional perspective • tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system • data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment [Sommerville 01]

20. CASE Toolset DFD [Sommerville 01]

21. State Machine Models • model the behavior of the system • in response to external and internal events • show the system’s responses to stimuli • often used for modeling real-time systems • notation • system states as nodes • events as arcs between these nodes • when an event occurs, the system moves from one state to another • state charts are an integral part of the UML [Sommerville 01]

22. Microwave Oven Model [Sommerville 01]

23. Microwave Oven State Description [Sommerville 01]

24. Microwave Oven Stimuli [Sommerville 01]

25. State Charts • allow the decomposition of a model into sub-models • a brief description of the actions is included • following the ‘do’ in each state • can be complemented by tables describing the states and the stimuli [Sommerville 01]

26. Microwave Oven Operation [Sommerville 01]

27. Semantic Data Models • describe the logical structure of data processed by the system • entity-relation-attribute model • entities in the system • relationships between these entities • entity attributes • widely used in database design • can readily be implemented using relational databases • no specific notation provided in the UML • objects and associations can be used [Sommerville 01]

28. Software Design Semantic Model [Sommerville 01]

29. Data Dictionaries • lists of all of the names used in the system models • also includes descriptions of the entities, relationships and attributes • advantages • support name management and avoid duplication • store of organizational knowledge linking analysis, design and implementation • many CASE workbenches support data dictionaries [Sommerville 01]

30. Data Dictionary Entries [Sommerville 01]

31. Object Models • describe the system in terms of object classes • an object class is an abstraction over a set of objects • common attributes • services (operations) provided by each object • various object models may be produced • inheritance models • aggregation models • interaction models [Sommerville 01]

32. Object Models • natural ways of reflecting the real-world entities manipulated by the system • more abstract entities are more difficult to model • object class identification is a difficult process • requires a deep understanding of the application domain • object classes reflecting domain entities may be reusable across systems [Sommerville 01]

33. Inheritance Models • organize the domain object classes into a hierarchy • classes at the top of the hierarchy reflect the common features of all classes • object classes inherit their attributes and services from one or more super-classes • may then be specialized as necessary • class hierarchy design is a difficult process • duplication in different branches should be avoided [Sommerville 01]

34. The Unified Modeling Language • devised by the developers of widely used object-oriented analysis and design methods • the “three amigos” Booch, Jacobson, Rumbaugh • has become an effective standard for object-oriented modeling • can be used at different levels of abstraction • conceptual level • specification level • implementation level [Sommerville 01]

35. UML Models • functional model • use case diagrams • object model • class diagram • objects, attributes, associations, operations • dynamic model • sequence diagrams • state chart diagrams • activity diagrams

36. UML Notation • object classes • rectangles with the name at the top, attributes in the middle section and operations in the bottom section • associations • relationships between object classes • shown as lines linking objects • inheritance • is referred to as generalization • shown ‘upwards’ rather than ‘downwards’ in a hierarchy

37. Library Class Hierarchy [Sommerville 01]

38. User Class Hierarchy [Sommerville 01]

39. Multiple Inheritance • allows object classes to inherit from several super-classes • rather than inheriting the attributes and services from a single parent class • can lead to semantic conflicts • attributes/services with the same name in different super-classes have different semantics • can simplify specifications of objects substantially • may make class hierarchy reorganization more complex [Sommerville 01]

40. Multiple Inheritance [Sommerville 01]

41. Object Aggregation • aggregation model • shows how classes which are collections are composed of other classes • similar to the part-of relationship in semantic data models [Sommerville 01]

42. Object Aggregation [Sommerville 01]

43. Object Behavior Modeling • behavioral model • shows the interactions between objects to produce some particular system behavior that is specified as a use-case • sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects [Sommerville 01]

44. Issue of Electronic Items [Sommerville 01]

45. CASE Workbenches • coherent set of tools designed to support related software process activities • such as analysis, design or testing • analysis and design workbenches • support system modeling during both requirements engineering and system design • these workbenches may support a specific design method or may provide support for a creating several different types of system model [Sommerville 01]

46. An Analysis and Design Workbench [Sommerville 01]

47. Analysis Workbench Components • diagram editors • model analysis and checking tools • repository and associated query language • data dictionary • report definition and generation tools • forms definition tools • import/export translators • code generation tools [Sommerville 01]

48. Important Concepts and Terms • activity diagram • aggregation model • architectural model • association • behavioral model • CASE workbench • classification model • component • composition model • context model • data dictionary • data flow • data flow diagram • data model • data structure • entity-relation-attribute model • entity-relationship diagram • inheritance model • interaction model • multiple inheritance • object • object class • object model • process model • requirements • sequence diagram • stimulus-response model • state chart/diagram • state machine model • system model • Unified Modeling Language (UML) • use case diagram

49. Chapter Summary

50. Chapter Summary • a model is an abstract system view • complementary types of model provide different system information • context models show the position of a system in its environment • together with other systems and processes • data flow models may be used to model the data processing in a system • state machine models describe the system’s behavior • in response to internal or external events [Sommerville 01]