1 / 20

CSC340: Tutorial 4 Requirements Analysis

CSC340: Tutorial 4 Requirements Analysis. TA: Y. An Date: 9:00-10:00am, Fri. Oct. 23, 2003 Location: BA1130. In this tutorial. Requirements analysis What is a requirement model? Class diagram Class properties and associations. REMEMBER.

Download Presentation

CSC340: Tutorial 4 Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSC340: Tutorial 4Requirements Analysis TA: Y. An Date: 9:00-10:00am, Fri. Oct. 23, 2003 Location: BA1130 CSC340

  2. In this tutorial • Requirements analysis • What is a requirement model? • Class diagram • Class properties and associations CSC340

  3. REMEMBER • We are modeling the environment within which the system will operate, and how that environment interacts with the system. • NOT the internals of the system – that’s system design CSC340

  4. What must a Requirements Model Include? • Must contain an overall description of functions. • Must represent people, physical things and concepts important to the analyst’s understanding of what is going on in the application domain. • Must show connections and interactions among these people, things and relevant concepts. • Must show the business situation in enough detail to evaluate possible designs. • Should be organized in such a way that it is useful later on during design and implementation of the software. • Hence a need for more detailed models that use cases.  Hence the need for Class diagrams CSC340

  5. Classes • A class describes a group of objects with: • Similar properties (attributes), • Common behaviors (operations), • Common relationships to other objects, • And common meaning (“semantics”). • For example, “employee” has a name, employee# and department; an employee is hired, and fired; an employee works in one or more projects. CSC340

  6. Finding Classes • Finding classes in use cases: • Look for noun phrases in the description of a use case; • These are only included in the model if they explain the nature or structure of information in the application. Use case description for check campaign budget: Checks whether the budget for a campaign is likely to be exceeded by the total cost of all the adverts that make it up. CSC340

  7. Finding Classes • Don’t create classes for concepts which: • Are beyond the scope of the system; • Refer to the system as a whole; • Duplicate other classes; • Are too vague or too specific. • Finding classes in other sources: • Reviewing background information; • Users and other stakeholders; • Analysis patterns; CSC340

  8. For example, Agate will want to store information about all its staff members, including current and newly hired staff members. The class staffMember is a way of organizing all these objects (“class instances”) and defining the set of attributes and operations that apply to all staff. StaffMember Class for Agate Name (mandatory) StaffMember staffName Attributes (opetional) claculateBonus() ChangeGrade() Operations (optional) CSC340

  9. Names • Every class must have a unique name • In the Agate system, we shall use instance of these classes. • For example, when we assign staff to work on a campaign, we shall use instances of the classes Campaign and StaffMember. • For each instance of Campaign there will be several instances of StaffMember. Client Campaign StaffMember CSC340

  10. Attributes • Each class can have attributes which represent useful information about instances of a class. • Each attribute has a type. • For example, Campaign has attribute title and detePaid. Campaign title: String datePaid: Date CSC340

  11. Operations • Often derived from actions verbs in use case descriptions. • Some operations will carry out processes to change or do calculations with the attributes of an object. • For example, the directors of Agate might want to know the difference between the estimated cost and the actual cost of a campaign • Campaign would need an opearation CostDifference(). CSC340

  12. Operations • Each operation has a signature, which specifies the types of its parameters and the type of the value it returns ( if any). Campaign title: String campaignStartDate: Date campaignFinishDate: Date estimatedCost: Money actualCost: Money Completed(CompletionDate Date, ActualCost Money) Money CostDifference() CSC340

  13. Association Relationship • An association is a structural relationship which represents a binary relationship between objects. • For example, a person is the child of another person, a car is owned by a person, or a staff member manages a campaign. • An association has a name, and may be specified along with zero, one or two roles. Campaign StaffMember staffContact title startDate estimateCost name staff# startDate qualification CSC340

  14. Association Multiplicity • Can a campaign exist without a member of staff to contact it? • If yes, then the association is optional at the Staff end – zero or one. • If a campaign cannot exist without a member of staff to contact it • Then it is not optional • If it must be contacted by one an only one member of staff then we show it like this – exactly one • What about the other end of the association? • Does every member of staff have to contact exactly one campaign? • No. So the correct multiplicity is zero or more: • Kerry Dent, a more junior member of staff, doesn’t contact any campaigns. • Pete Bywater contacts two. CSC340

  15. Associations with Multiplicity Campaign StaffMember staffContact title startDate estimateCost name staff# startDate qualification 1 0..* “A staff member can contact zero or more campaigns” “A campaign is managed by exactly one staff member” CSC340

  16. Multiplicity • Some example of specifying multiplicity: • Optional (0 or 1) 0..1 • Exactly one 1 =1..1 • Zero or more 0..* • One or more 1..* • A range of value 1..6 • A set of ranges 1..3, 7..10, 15, 19..* CSC340

  17. Associations with Multiplicity Campaign StaffMember staffContact title startDate estimateCost name staff# startDate qualification 0..* 0..* CSC340

  18. Associations with Multiplicity Campaign StaffMember staffContact title startDate estimateCost name staff# startDate qualification 0..* 1 CSC340

  19. Associations with Multiplicity Campaign StaffMember staffContact title startDate estimateCost name staff# startDate qualification 0..* 1..* CSC340

  20. Data Dictionary • A data dictionary contains a precise, authoritative definition of each element in the models developed during an entire project life cycle. • Hidden information that does not appear in diagrams. • Precise definitions of class in diagrams. • A data dictionary usually is maintained by CASE tool. • A CASE tool monitors modification to stored models, automatically adjusting the data dictionary entries in line with changes to the diagrams. • A data dictionary provides a single shared resource for all member authorized to work with it. CSC340

More Related