Presentation is loading. Please wait.

Presentation is loading. Please wait.

NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology.

Similar presentations


Presentation on theme: "NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology."— Presentation transcript:

1 NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology IT Department Software Engineering ESGD3110.101 & ITGD3103.101 1 st Semester 2008/2009 UP Copyrights 2008

2 NI ©UNITEN 2000/01 2 What is an Object? Informally, an object represents an entity, either physical, conceptual or software. Example: Physical entity : Car Conceptual entity: Chemical process Software entity: Linked list. A more formal definition: An object is a concept abstraction, or thing with sharp boundaries and meaning for an application. An object is something that has: State Behaviour Identity

3 NI ©UNITEN 2000/01 3 An Object Has State The state of an object is one of the possible conditions (values of its all attributes at a given time) in which an object may exist. The state of an object normally changes over time. The state of an object is usually implemented by a set of properties (called attributes), with the values of properties, plus the links the object may have with other objects. Example : Object name: Pencil State : Sharp

4 NI ©UNITEN 2000/01 4 An Object Has Behaviour Behaviour determines how an object acts and reacts Behaviour defines how an object reacts to requests from other objects The visible behaviour of an object is modelled by the set of messages it can respond to (the operations the object can perform) Example: Object name: Car engine Behaviour: start(), spark(),ignition(),getGas(), getAir()

5 NI ©UNITEN 2000/01 5 Object has Identity Each object has a unique identity, even if its state is identical to that of another object. It characterises its own existence Distinguish any object in an unambiguous way, and independently from its state. Colour- Blue H/power- 240bph Model-MercedesCLK340 Plate Num-WDG 997 Colour- Blue H/power- 240bph Model-MercedesCLK340 Plate Num-WFN 338

6 NI ©UNITEN 2000/01 6 What are Classes? A class is a description of a group of objects with common properties (attributes), common behaviour (operations), common relationships to other objects (associations and aggregations) and common semantic. A class is an abstract definition of an object. –It defines the structure and behaviour of each object in the class –It serves as a template for creating objects. Abstraction help us deal with complexity

7 NI ©UNITEN 2000/01 7 Naming Classes A class should capture one and only one key abstraction Bad abstraction: Student class which know student information and the student schedule for the current semester Good abstraction: Separate classes for Student and Student Schedule. A class name should be a singular noun that best characterises the abstraction. Difficulty in naming a class may be an indication pf a poorly defined abstraction. Name should come directly from the vocabulary of the domain.

8 NI ©UNITEN 2000/01 8 Naming Classes cont... After naming a class, a brief concise description of the class should be made –Focus on the purpose of the class not on the implementation. Example: –Name: Student –Working Definition: Information about a person registered to attend classes at the University. Look for the “WHATS” and ignore the “HOWS”

9 NI ©UNITEN 2000/01 9 Representing Classes A class is represented using a compartment rectangle A class is comprised of three sections –The first section contain the class name –The second section shows the structure (attributes) –The third section shows the behaviour (operations) The second and third sections may be suppressed if they need not to be visible on the diagram. SportsCar + revenue -model + accelerate() + brake() SportsCar

10 NI ©UNITEN 2000/01 10 Attribute An attribute is a data definition held by instances of class (objects) Attributes do not have behaviour – they are not object Attribute names are simple noun or nouns phrase Each attribute should have a clear, concise definition An attribute value is the value of an attribute for a particular object Each object has a value for every attribute define for its class For example: for an object of the “Lecturer class” –Attribute: –Name : Zainab Ali –Staff ID : 215548 –Subject : Mathematics

11 NI ©UNITEN 2000/01 11 Derived attributes A derived attribute is an attribute whose value may be calculated based on the value of other attribute(s) Used when it is not enough time to re-calculate the value every time it is needed Trades off runtime performance vs. memory required Rectangle Length Width Area

12 NI ©UNITEN 2000/01 12 Operations A class has a set of responsibilities which define the behaviour of the objects in the class The responsibilities of a class are carried by its operations An operation (method) is a service that can be requested from an object to effect behaviour An operation should perform a simple, cohesive function.

13 NI ©UNITEN 2000/01 13 Naming operation Operation should be names to indicate their outcome, not the steps behind the operation. Example: –CalculateBalance() 8Poorly named: Indicates that the balance must be calculated – this is an implementaion decision –GetBalance() Well named: Indicates the outcomes only

14 NI ©UNITEN 2000/01 14 Naming operation cont… Operation should be named from the perspective of the supplier not the client In an oil station,oil is received from the pump One operation from the pump has this responsibility – what should it be called? Good names – dispense(), giveOil()  Bad name – receiveOil() The pump gives the oil – it does not receive the oil

15 NI ©UNITEN 2000/01 15 Class Stereotypes A stereotype is a new type of modeling that extends the semantics of the metamodel. Every class may have at most one stereotype Common stereotype: –Boundary class –Entity class –Control class –Exception class –Utility class Stereotypes are shown in the class name compartment enclosed in >

16 NI ©UNITEN 2000/01 16 Boundary Class A boundary class models communication between the system’s surroundings and its inner workings Responsible for the exchanges of information between the software and one or more of its actors The exchange are done according to a given format and a protocol. Typical boundary classes –Windows (user interface), Communication protocol (system interface), printer interface, sensor and etc.

17 NI ©UNITEN 2000/01 17 Interfaces to other systems A boundary class is also used to model an interface to another system The important characteristics of this type of boundary class are –The information to be passed to the other system –The communication protocol used to ‘talk’ to other system In the ‘Card Validation” scenario,information must be sent to the external Bank System –A class called CardValidation is created to hold the interface to the external system > CardValidation

18 NI ©UNITEN 2000/01 18 Entity Class An entity class models information and associated behaviour that is generally long-lived (persistent) –i.e. Entity class holds persistent information It can reflects a real-life phenomenon It may also needed for the internal tasks of the system The values of its attributes are often provided by an actor The behaviour is surroundings-independent Entity classes in the “Withdraw Money” use case: –account > account

19 NI ©UNITEN 2000/01 19 Control Class A control class models control behaviour specific to one or more use cases A control class –creates, initialises and deletes controlled objects –controls the sequencing or co-ordination of execution of controlled objects –controls concurrency issues for the controlled classes –is, most of the time, the implementation of an intangible object In the Withdraw Money’s scenario, a WithdrawMgr class controls the process of cash withdrawal > WithdrawMgr

20 NI ©UNITEN 2000/01 20 Exercise 4 From the ATM case study 1.Identify all possible objects/classes involved 2.For each of them, classify their –stereotypes, either boundary, control or entity –attributes –operations 3. Create the classes identified using Rational Rose 3.Save your rational model in the diskette


Download ppt "NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology."

Similar presentations


Ads by Google