1. 1 M206 Chapter 31: An Overview of Software Development 1.Defining the problem 2.Analyzing the requirement – constructing initial structural model 3.Analyzing the behavior –constructing the dynamic models 1.Identifying the use cases 2.Communication with the user interface 3.Walk-through and navigation of associations 4.Sequence diagrams 4.Communicating with the user 5.Detailed design and implementation

2. 2 What you should do this week  Read Chapters 31  Run LB-31

3. 3 Objectives: Illustrate the main activities involved in an object-oriented approach to software development.  Give you some insight into how moving problem statement  a working software system.  Mentioning many related concepts (greater details will be in later chapters).

4. 4 An Overview of Software Development  Software development is a process starting from an initial description by the client or user produces and delivers a final, tested software system that satisfies these requirements.  It is the process of problem statement  a working software system.

5. 5 Introduction  software development has been divided into the following activities. 1.Requirements analysis – the process of producing a detailed and complete specification of the requirements of the system. 2.Analysis – analysing the specification of requirements to develop a detailed understanding in computing terms of what the system has to do. 3.Design – deciding how the system will meet the specified requirements. 4.Implementation – translating the completed design into program code in some suitable programming language. 5.Testing – not just testing the final product but testing at each stage to ensure that what is produced relates correctly to the previous stage and to the user requirements.

6. 6 Activities of software Development object oriented  Requirements analysis – producing a negotiated statement of requirements. (Requirements analysis)  Developing a structural model – determining the classes and connections between them. (Analysis)  Developing dynamic models – determining what interactions among objects are needed to achieve the behaviour required of the system. (Analysis and Design)  Communicating with the user – designing a user interface and its communication with the domain model. (Analysis and Design)  Detailed design and implementation – deciding what pre-existing classes can be reused as well as writing the actual code. (Design and Implementation)

7. 7 Activities of software Development object oriented  Requirements analysis  Developing a structural model  Developing dynamic models  Communicating with the user  Detailed design and implementation  Requirements analysis  Analysis  Design  Implementation  Testing

8. 8  There is one omission from the above list – testing. This is not because testing is of any less importance in an object-oriented approach.  One of the advantages of an object-oriented approach is that testing becomes easier. Introduction - continued

9. 9  The object-oriented software development method that we use in this course is derived from a method known as CRC (Classes, Responsibilities and Collaborations).  Our method in addition uses the concept of an association between classes and employs some of the diagrammatic notation of the Unified Modelling Language (UML), a notation widely used in the development of object-oriented software.

10. 10 1.Defining the problem – requirements analysis  1.1 initial statement  1.2 produce the NSR

11. 11 1.Defining the problem – requirements analysis  1.1 initial statement Here is a short description of the problem that we shall be using to illustrate the software development process. E.g. A computer system is required for a small video lending library. At any time the system should be able to  list what videos any member currently has on loan  indicate how many copies of any film are not on loan.

12. 12 1.Defining the problem – requirements analysis - continued  1.2 produce (NSR) Analysing the initial statement of requirements in consultation with the client requirements analysis. This process produces an agreed and unambiguous specification called the negotiated statement of requirements (NSR).

13. 13 1.Defining the problem – requirements analysis - continued  In the negotiation process, some of the questions that we might ask about this system are: Can anyone borrow videos? Can a member borrow any number of videos? Does the library have only one copy of each video? How are different copies of a film distinguished? What precisely is meant by ‘film’, ‘video’ and ‘copy’?

14. 14 1.Defining the problem – requirements analysis - continued  The negotiated statement of requirements for the Video Library system The library holds video copies of a number of films. It may have one or more copies of each film. The system should, for each film, hold the film’s title; no two films have the same title. A library member can borrow any video copy of a film that is not currently on loan. However, no member can have more than two copies on loan at a time. When a library member returns a copy it immediately becomes available for loan. Each copy has a unique identifying number.

15. 15 1.Defining the problem – requirements analysis - continued Each member of the library has a unique membership number; the system also holds each member’s name. The system that has to be designed must be able to do the following:  For any film, return the number of copies of that film that are currently available for loan.  For any member, return list all the films that member currently has copies of on loan.  Update the system whenever a copy is borrowed or returned.

16. 16 2Analysing the requirements– constructing an initial structural model  initial structural model Class diagram (classes, links, multiplicity) Class description text  how to build such model 1. analysis the NSR to recognize the class and links  example (a) films, copies, members; (b) film titles, copy numbers, member names, member numbers; (c) the possible links between the entities  A member has copies on loan,  A copy is a copy of a film.

17. 17 2Analysing the requirements– constructing an initial structural model 2. draw the Class Diagram representing the class and associations 3.Add the more information to specify the associations.

18. 18 2Analysing the requirements– constructing an initial structural model  If you examine the requirements you will see that no member can have more than two copies on loan at a time.  Thus each instance of Member will be linked at any one time to 0, 1 or 2 instances of Copy by the hasOnLoan association.  We say that the multiplicity of hasOnLoan at the Copy end is 0..2.  In the same way, each instance of Copy is linked at a given time to at most one instance of Member; so the multiplicity of hasOnLoan at the Member end is 0..1.

19. 19 2 Analysing the requirements– constructing an initial structural model 4. Write class description  deal with the attributes of the classes. So we list the attributes of the class, as follows:  Class: Member  Attributes: name "The name of the member" memberNo "The unique membership number of the member“  Class: Copy  Attributes: copyNo "The unique identifying number of the copy“  Class: Film  Attributes: title "The unique title of the film"

20. 20 The initial structural model for the Video Library system  Class: Member Attributes:  name "The name of the member"  memberNo "The unique membership number of the member"  Class: Copy Attributes:  copyNo "The unique identifying number of the copy"  Class: Film Attributes:  title "The unique title of the film"

21. 21 3Analyzing the behavior – constructing dynamic models  Analyzing the behavior –constructing the dynamic models 1.Identifying the use cases 2.Communication with the user interface 3.Walk-through and navigation of associations 4.Sequence diagrams

22. 22 3.1 Identifying use cases -  From the above NSR we can identify four distinct behaviours, or use cases as they are called in the UML. These are as follows.  We will refer to these use cases as: Get Number Available, List Films, Borrow and Return

23. 23 3.2 Communication with the user interface.  A user interface is the means by which the domain model communicates with the real world.

24. 24 3.2 Communication with the user interface. - continued 1.Add an Orchestrating instance: extra object to represent the user interface. In our example we consider the LibAdmin. 2.find the associations between the user interface and the classes of the system.  For our example, possible associations are:

25. 25 3.2 Communication with the user interface. - continued  Get Number Available The user could enter (or perhaps select) the film title and then initiate the use case by, clicking a button. The user interface send a message with the film title as argument to the orchestrating instance. the orchestrating instance start the use case: afilm1, t1 afilm2, t2. afilmn, tn

26. 26 3.2 Communication with the user interface. - continued  List Films It requires the system to be able, for any member, to give a list of the films that the member has copies of on loan. Identify the member by a unique number, send this number to the LibAdmin. This will require admin to keep track of Member instances using their membership numbers amember1, 1 amember2, 2. amembern, n

27. 27 3.3 Walk-throughs and navigation of associations  To analyse a use case we break down its requirements into simpler steps.  These steps constitute what is called a walk-through of the use case.  Our aim at this stage is to give sufficient detail of a walk- through for each use case.

28. 28 3.3 Walk-throughs and navigation of associations - continud  List Films use case.  Given : aMemberNo 1.Locate the instance, aMember, with aMemberNo linked to admin via members. 2.Locate all the instances of Copy that are linked to aMember via hasOnLoan. 3.For each such instance, aCopy, of Copy 4.Locate the instance of Film linked to aCopy via isCopyOf. 5.Form a collection, films, of all the instances of Film located in 4. 6.Retrieve the titles of the instances of Film in films. 7.Result: the relevant film titles.

29. 29 3.3 Walk-throughs and navigation of associations - continud  The object diagram shows how Film instances are located.

30. 30 Walk-throughs and navigation of associations – cont’d  Below is the navigation

31. 31 3.4 Sequence diagrams  show the sequence of messages that are sent to and from objects in order to achieve a particular behaviour.  Below is the Sequence diagram for Get Number Available

32. 32 Sequence diagrams - continued  For the List Films use case we have the following sequence diagram

33. 33 Detailed design and implementation  The developer has to address the following questions:  Which existing classes could be used in our solution?  Could we make use of inheritance and introduce extra classes to give a more logical structure?  What programming constructs can be used to implement the various responsibilities that we have identified for each class?

34. 34 Detailed design and implementation - continued

35. 35 Detailed design and implementation - continued

36. 36 Detailed design and implementation - continued  Class specification for Member

37. 37 Detailed design and implementation - continued  Class specification for LibAdmin

38. 38 Detailed design and implementation - continued  Similarly in LibAdmin, the listFilms: method can be implemented as follows:  listFilms: aMemberNo  | aMember filmList titleList |  "step 1:"  aMember := members at: aMemberNo.  "steps 2,3,4 –  filmList := aMember getFilms.  "step 5:"  titleList := OrderedCollection new.  filmList do: [:aFilm | titleList add: aFilm title].  "return answer:"  ^titleList