1. September 15, 2009COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/

2. September 15, 2009COMS W41562 Topics covered in this lecture Software requirements System models (introduction to Unified Modeling Language – UML will be covered in more depth later in the course)

3. September 15, 2009COMS W41563 Software Requirements

4. September 15, 2009COMS W41564 What is a requirement? What is the (future) software system supposed to “do”? Each requirement is a service or feature that the customer needs from a system and/or a constraint under which it must be developed and operated. May range from a high-level abstract statement to a detailed mathematical specification. Requirements serve a dual function –May be the basis for a bid for a contract - therefore must be open to interpretation; –May be the basis for the contract itself - therefore must be defined in detail.

5. September 15, 2009COMS W41565 User requirements Should describe functional and non-functional requirements in such a way that they are understandable by (future) system users who may have little technical knowledge. User requirements are defined using natural language, tables and diagrams as these can be understood by all users. Usage scenarios, user stories, use cases, …

6. September 15, 2009COMS W41566 System requirements More detailed specifications of system functions, services and constraints than user requirements. They are intended to be a basis for developers to design the system. They may be incorporated into the system contract.

7. September 15, 2009COMS W41567 Functional requirements Statements of services and features the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Functional user requirements may be high- level statements of what the system should do but functional system requirements must describe the system services in detail.

8. September 15, 2009COMS W41568 Example: The LIBSYS system A library system that provides a single interface to a number of databases of articles in different libraries. Users can search for, download and print these articles for personal study.

9. September 15, 2009COMS W41569 Examples of functional requirements The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order for a document shall be allocated a unique identifier, which the user shall be able to copy to the account’s permanent storage area.

10. September 15, 2009COMS W415610 Requirements imprecision Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term ‘appropriate viewers’ –User intention - special purpose viewer for each different document type; –Developer interpretation - Provide a text viewer that shows the contents of the document.

11. September 15, 2009COMS W415611 Non-functional requirements Define system properties and constraints, e.g., reliability, response time, storage requirements, device capability, etc. Process requirements may also be specified, mandating a particular IDE (Integrated Development Environment), programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

12. September 15, 2009COMS W415612 Non-functional classifications Product requirements –Requirements that specify that the delivered product must behave in a particular way, e.g., resource utilization, mean time to recovery, etc. Organizational requirements –Requirements that are a consequence of organizational policies and procedures, e.g., process standards used, platform rrestrictions, etc. External requirements –Requirements that arise from factors that are external to the system and its development process, e.g., interoperability requirements, legislative requirements, etc.

13. September 15, 2009COMS W415613 Non-functional requirements examples Product requirement: The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. Organizational requirement: The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP- STAN-95. External requirement: The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

14. September 15, 2009COMS W415614 Goals vs. requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal –A general intention of the user such as ease of use. Verifiable non-functional requirement –A statement based on some measure that can be objectively tested. Goals are helpful to developers as they convey the intentions of the system users.

15. September 15, 2009COMS W415615 Examples A system goal –The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. A verifiable non-functional requirement –Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

16. September 15, 2009COMS W415616 Requirements interaction Conflicts between different non-functional requirements are common in complex systems. Spacecraft system –To minimize weight, the number of separate chips in the system should be minimized. –To minimize power consumption, lower power chips should be used. –However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

17. September 15, 2009COMS W415617 Requirements completeness and consistency In principle, requirements should be both complete and consistent. Complete: Should include descriptions of all facilities required. Consistent: Should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it may be impossible to produce a complete and consistent requirements document.

18. September 15, 2009COMS W415618 Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.

19. September 15, 2009COMS W415619 Library system domain requirements There shall be a standard user interface to all databases, which shall be based on the Z39.50 standard. Z39.50 Because of copyright restrictions, some documents must be deleted immediately upon arrival. Depending on the user’s needs, these documents will either be printed locally on the system server, for manually forwarding to the user, or routed to a network printer.

20. September 15, 2009COMS W415620 Domain requirements problems Understandability –Requirements are expressed in the language of the application domain; –This jargon may not be understood by the software engineers developing the system. Implicitness –Domain specialists understand the area so well that they may not think of making the domain requirements explicit.

21. September 15, 2009COMS W415621 Problems with natural language Lack of clarity –Precision is difficult without making the document hard to read. Requirements confusion –Functional and non-functional requirements tend to be mixed up. Requirements amalgamation –Several different requirements may be expressed together.

22. September 15, 2009COMS W415622 Requirement problems LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that frequent users may receive discounted rates. This requirements statement includes both conceptual and detailed information –Describes the concept of a financial accounting system that is to be included in LIBSYS; –However, it also includes the detail that managers can configure this system - this is unnecessary at this level.

23. September 15, 2009COMS W415623 Guidelines for writing requirements Invent a standard format and use it for all requirements.standard format Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon.

24. September 15, 2009COMS W415624 Requirements vs. design In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable –A system architecture may be designed to structure the requirements; –The system may inter-operate with other systems that generate design requirements; –The use of a specific design may be a domain requirement.

25. September 15, 2009COMS W415625 System Models

26. September 15, 2009COMS W415626 Use cases Use cases are a scenario-based modeling technique that identify the actors in an interaction and describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use cases by showing the sequence of event processing in the system.

27. September 15, 2009COMS W415627 LIBSYS use cases

28. September 15, 2009COMS W415628 Article printing use case

29. September 15, 2009COMS W415629 Print article sequence

30. September 15, 2009COMS W415630 System modeling System modeling helps the analyst to understand the functionality of the system, and models are also used to communicate with customers. Different models present the system from different perspectives –External perspective showing the system’s context or environment; –Behavioral perspective showing the behavior of the system; –Structural perspective showing the system or data architecture.

31. September 15, 2009COMS W415631 Model types Data processing model showing how the data is processed at different stages. Composition model showing how entities are composed of other entities. Architectural model showing principal sub- systems. Classification model showing how entities have common characteristics. Stimulus/response model showing the system’s reaction to events.

32. September 15, 2009COMS W415632 Context models Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. 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.

33. September 15, 2009COMS W415633 The context of an ATM system

34. September 15, 2009COMS W415634 Process models 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.

35. September 15, 2009COMS W415635 Equipment procurement process

36. September 15, 2009COMS W415636 Behavioral models Behavioral models are used to describe the overall behavior of a system. Two types of behavioral model are: –Data processing models that show how data is processed as it moves through the system; –State machine models that show the system’s response to events. These models show different perspectives so both of them are needed to describe the system’s behavior.

37. September 15, 2009COMS W415637 Data-processing models Data flow diagrams (DFDs) may be used to model the system’s data processing. These show the processing steps as data flows through a system. DFDs are an intrinsic part of many analysis methods. Simple and intuitive notation that customers can understand. Show end-to-end processing of data.

38. September 15, 2009COMS W415638 Order processing DFD

39. September 15, 2009COMS W415639 Data flow diagrams DFDs model the system from a functional perspective. Tracking and documenting 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.

40. September 15, 2009COMS W415640 Insulin pump DFD

41. September 15, 2009COMS W415641 State machine models Model the behavior of the system in response to external and internal events. Show the system’s responses to stimuli, so are often used for modeling real-time systems. State machine models show system states as nodes and events as arrows between these nodes. When an event occurs, the system moves from one state to another.

42. September 15, 2009COMS W415642 Statecharts 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.

43. September 15, 2009COMS W415643 Microwave oven model

44. September 15, 2009COMS W415644 Microwave oven state description

45. September 15, 2009COMS W415645 Microwave oven stimuli

46. September 15, 2009COMS W415646 Microwave oven operation

47. September 15, 2009COMS W415647 Semantic data models Used to describe the logical structure of data processed by the system. An entity-relationship-attribute (ERA) model sets out the entities in the system, the relationships between these entities and the entity attributes Widely used in database design. Can readily be implemented using relational databases.

48. September 15, 2009COMS W415648 Library semantic model

49. September 15, 2009COMS W415649 Data dictionaries Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. Advantages –Support name management and avoid duplication; –Store of organizational knowledge linking analysis, design and implementation; Many IDEs support data dictionaries.

50. September 15, 2009COMS W415650 Data dictionary entries

51. September 15, 2009COMS W415651 Object models Object models describe the system in terms of object classes and their associations. An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. (Not necessarily to be implemented directly as programming language classes.) Various object models may be produced –Inheritance models; –Aggregation models; –Interaction models.

52. September 15, 2009COMS W415652 Object models Natural ways of reflecting the real-world entities manipulated by the system Abstract entities are more difficult to model using this approach Object class identification is recognized as a difficult process requiring a deep understanding of the application domain Object classes reflecting domain entities are often reusable across systems

53. September 15, 2009COMS W415653 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 (base classes). These may then be specialized as necessary. It is sometimes difficult to avoid duplication in different branches of a class hierarchy design.

54. September 15, 2009COMS W415654 Object models and UML UML (Unified Modeling Language) is a representation devised by the developers of widely used object-oriented analysis and design methods.UML It has become an effective standard for object- oriented modeling. Notation –Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section; –Relationships between object classes (known as associations) are shown as lines linking objects; –Inheritance is referred to as generalization and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy.

55. September 15, 2009COMS W415655 Library class hierarchy

56. September 15, 2009COMS W415656 User class hierarchy

57. September 15, 2009COMS W415657 Multiple inheritance Rather than inheriting the attributes and services from a single parent class, a modeling system that supports multiple inheritance allows object classes to inherit from several super-classes. (Multiple inheritance may or may not be supported by the implementation programming language.) This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. Multiple inheritance makes class hierarchy reorganization more complex.

58. September 15, 2009COMS W415658 Multiple inheritance

59. September 15, 2009COMS W415659 Object aggregation An aggregation model shows how classes that are collections are composed of other classes. Aggregation models are similar to the part-of relationship in semantic data models.

60. September 15, 2009COMS W415660 Object aggregation

61. September 15, 2009COMS W415661 Object behavior modeling A 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.

62. September 15, 2009COMS W415662 Issue of electronic library items

63. September 15, 2009COMS W415663 Final Notes

64. September 15, 2009COMS W415664 Teams Announced Next Week! Hopefully before class on Tuesday Teams will be posted on the website team pageteam page If you already formed a full team, assume you’re good to go (but let us know asap if anything changes!) Start thinking about the Project ConceptProject Concept

65. September 15, 2009COMS W415665 Upcoming Deadlines Team project concept due September 29 th Project concept feedback by October 6 th  First iteration begins October 6 th

66. September 15, 2009COMS W415666 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/