OOSAD UML materi sth UTS

  OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN (OOSAD) USING

  UNIFIED MODELLING LANGUAGE (UML)

Book:

Kenneth E. Kendall and Julie E. Kendall,

  

System Analysis and Design Methods,

  8 th

  Edition, Prentice Hall, 2010

  Contents:

• Object-Oriented Concepts
• Objects / Classes / Inheritance
• CRC Cards and Object Think
• The Unified Modeling Language (UML) Concepts and Diagrams
• Use Case Modelling
• Activity Diagram
• Sequence and Communication Diagrams
• Class Diagram
• Enhancing Sequence Diagrams
• Enhancing Class Diagram
• Statechart Diagrams
• Package and Other UML Artifacts
• Putting UML To Work
• The Important of Using UML For Modeling

  

Introduction

Object-oriented analysis and design can offer an approach that • facilitates logical, rapid, and thorough methods for creating new systems responsive to a changing business landscape.

• Object-oriented techniques work well in situations in which complicated information systems are undergoing continuous maintenance, adaptation, and redesign.
• In this chapter, we introduce the unified modeling language (UML), the industry standard for modeling object-oriented systems. The UML toolset includes diagrams that allow you to visualize • the construction of an object-oriented system.
• Each design iteration takes a successively more detailed look at the design of the system until the things and relationships in the system are clearly and precisely defined in UML documents.
• UML is a powerful tool that can greatly improve the quality of your systems analysis and design, and thereby help create higher-quality information systems.

  Object Oriented Concept

• Object-oriented programming differs from traditional procedural programming by examining the objects that are part of a system.
• Each object is a computer representation of some actual thing or event. General descriptions of the key object-
• oriented concepts of objects, classes, and inheritance are presented in this section, with further details on other UML concepts introduced later in this chapter.

  Object Oriented Concept 1) Object 2) Classes

3) Inheritance

1) Object

• Objects are persons, places, or things that are relevant to the system we are analyzing.
• Object oriented systems describe entities as objects.
• Typical objects may be customers, items, orders, and so on.
• Objects may also be GUI displays or text areas on the display.

  

Object and Classes :

• Objects are typically part of a group of similar items called classes.
• The desire to place items into classes is not new. Describing the world as being made up of animals, vegetables, and minerals is an • example of classification. The scientific approach includes classes of animals (such as mammals), and then • divides the classes into subclasses (such as egg-laying animals and pouched mammals).
• Objects are represented by and grouped into classes that are optimal for reuse and maintainability.
• A class defines the set of shared attributes and behaviors found in each object in the class. For example, records for students in a course section have similar information • stored for each student. The students could be said to make up a class (no pun intended). •
• The values may be different for each student, but the type of information is the same.
• Programmers must define the various classes in the program they are writing.
• When the program runs, objects can be created from the established class. The term instantiate is used when an object is created from a class.

  For example, a program could instantiate a student named PeterWellington as an • object from the class labeled as student.

2) Classes

• Each class should have a name that differentiates it from all other classes. Class names are usually nouns or short phrases and begin
• with an uppercase letter.
• In Figure 10.1 the class is called RentalCar. In UML, a class is drawn as a rectangle.
• The rectangle contains two other important features: a list
• of attributes and a series of methods. These items describe a class, the unit of analysis that is a
• large part of what we call object-oriented analysis and design.

Figure 10.1 : An example of a UML class. A class is depicted as a rectangle consisting of the class name, attributes, and

  methods.

  

Classes :

• possessed by all objects of the class.

  An attribute describes some property that is

• Notice that the RentalCar class possesses the attributes of size, color, make, and model.
• All cars possess these attributes, but each car will have different values for its attributes.
• For example, a car can be blue, white, or some other color.
• Later on we will demonstrate that you can be more specific about the range of values for these properties. When specifying attributes, the first letter is
• usually lowercase.

  

Method :

• A method is an action that can be requested from any object of the class.
• Methods are the processes that a class knows to carry out. Methods are also called operations. For the class of RentalCar, rentOut(),
• checkIn(), and service() are examples of methods.
• When specifying methods, the first letter is usually lowercase.

3. Inheritance

  (Pewarisan) Another key concept of object-oriented systems is inheritance.

• Classes can have children; that is, one class can be created out of another class. In UML, the original—or parent—class is known as a base class.
• The child class is called a derived class.
• A derived class can be created in such a way that it will inherit all the attributes and behaviors of the base class.
• A derived class, however, may have additional attributes and behaviors. For example, there might be a Vehicle class for a car rental company
• that contains attributes such as size, color, and make.
• easily.

  Inheritance reduces programming labor by using common objects

• The programmer only needs to declare that the Car class inherits from the Vehicle class, and then provide any additional details about new attributes or behaviors that are unique to a car.
• All the attributes and behaviors of the Vehicle class are automatically and implicitly part of the Car class and require no additional programming.
• This enables the analyst to define once but use many times, and is similar to data that is in the third normal form, defined only once in one database table. The derived classes shown in Figure 10.2 are Car or Truck. Here the
• attributes are preceded by minus signs and methods are preceded by plus signs.

  

Figure 10.2: A class diagram showing inheritance. Car and Truck

are

  The Unified Modelling Language (UML) Concepts and Diagram

• understanding, due to its wide acceptance and usage.

  The UML approach is well worth investigating and

• UML provides a standardized set of tools to document the analysis and design of a software system.
• The UML toolset includes diagrams that allow people to visualize the construction of an object-oriented system, similar to the way a set of blueprints allows people to visualize the construction of a building. Whether you are working independently or with a large
• systems development team, the documentation that you create with UML provides an effective means of communication between the development team and the business team on a project.
• diagrams, as illustrated in Figure 10.3.

  UML consists of things, relationships, and

• The first components, or primary elements, of as object, but in UML they are called things.
• Structural things are most common. Structural things are classes, interfaces, use cases, and many other elements that provide a way to create models.
• Structural things allow the user to describe relationships. Behavioral things describe how things work. Examples of behavioral things are interactions
• and state machines. Group things are used to define boundaries.

Figure 10.3 : An overall view of UML and its components: Things, Relationships, and Diagrams.

• Relationships are the glue that holds the things together. It is useful to think of relationships in two
• ways.
• Structural relationships are used to tie the things together in the structural diagrams.
• Structural relationships include dependencies, aggregations, associations, and generalizations. Structural relationships show inheritance,
• for example.
• Behavioral relationships are used in the behavioral diagrams.
• structural diagrams and behavioral diagrams.

  There are two main types of diagrams in UML:

• Structural diagrams are used, for example, to describe the relationships between classes.
• They include class diagrams, object diagrams, component diagrams, and deployment diagrams.
• Behavioral diagrams, on the other hand, can be used to describe the interaction between people (called actors in UML) and the thing we refer to as a use case, or how the actors use the system.
• Behavioral diagrams include use case diagrams, sequence diagrams, communication diagrams, statechart diagrams, and activity diagrams.

The six most commonly used UML diagrams are:

  

1. A use case diagram, describing how the system is used. Analysts start

with a use case diagram.

  

2. A use case scenario (although technically it is not a diagram). This

scenario is a verbal articulation of exceptions to the main behavior described by the primary use case.

  

3. An activity diagram, illustrating the overall flow of activities. Each use

case may create one activity diagram.

  

4. Sequence diagrams, showing the sequence of activities and class

relationships. Each use case may create one or more sequence diagrams.

  An alternative to a sequence diagram is a communication diagram, which contains the same information but emphasizes communication instead of timing.

  

5. Class diagrams, showing the classes and relationships. Sequence

diagrams are used (along with CRC cards) to determine classes. An offshoot of a class diagram is a gen/spec diagram (which stands for generalization/specialization).

  

6. Statechart diagrams, showing the state transitions. Each class may create

a statechart diagram, which is useful for determining class methods.

  How these diagrams relate to one another is illustrated in Figure 10.5.

Figure 10.5. An overall view of UML diagrams showing how each diagram leads to the development of other UML diagrams.

  

Use Case Modelling

• UML is fundamentally based on an object-oriented analysis technique known as use case modeling.
• A use case model shows a view of the system from the user perspective, thus describing what a system does without describing how the system does it.
• UML can be used to analyze the use case model, and to derive system objects and their interactions with each other and with the users of the system. Using UML techniques, you further analyze the objects and their

• interactions to derive object behavior, attributes, and relationships.

• A use case provides developers with a view of what the users want.
• It is free of technical or implementation details.
• We can think of a use case as a sequence of transactions in a system.
• The use case model is based on the interactions and relationships of individual use cases.
• initiates an event; the event that triggers a use case; and the use case that performs the actions triggered by the event.

  A use case always describes three things: an actor that

• In a use case, an actor using the system initiates an event that begins a related series of interactions in the system.
• Use cases are used to document a single transaction or event. An event is an input to the system that happens at a specific
• time and place and causes the system to do something. For more information about use case symbols and how to
• draw use case diagrams, see Chapter 2.

Figure 10.6 is a use case example of student enrollment at a university.

• Notice that only the most important functions are represented.
• The Add Student use case does not indicate how to add students, the method of implementation.
• Students could be added in person, using the Web, using a touch-tone telephone, or any combination of these methods.
• The Add Student use case includes the Verify Identity (Pembuktian Identitas) use case to verify the identity of the student.
• The Purchase Textbook use case extends the Enroll in Class (daftar kelas) use case, and may be part of a system to enroll students in an online course.
• It may seem as if the Change Student Information use case is a minor system feature and should not be included on the use case diagram, but because this information changes frequently, administration has a keen interest in allowing students to change their own personal information.
• The fact that the administrators deem (menganggap) this to be important not only justifies (benar), but calls for, the use case to be written up.
• Students would not be allowed to change grade point average, outstanding fees, and other information.
• This use case also includes the Verify Identity use case, and in this situation, it means having the student enter a user ID and password before gaining access to the system.
• View Student Information allows students to view their personal information, as well as courses and grades.
• A use case scenario example is shown in Figure

10.7. Some of the areas included are optional, and may not be used by all organizations.

• The three main areas are:

  1) A header area containing case identifiers and initiators.

  2) Steps performed. 3) A footer area containing preconditions, assumptions, questions, and other information.

  In the first area the use case is identified by its name, Change Student Information; the actor is identified as a Student; and the Use Case and Triggering Event are described.

• The second area contains a series of steps that are performed as long as no errors are encountered. Finally, in the third area, all of the pre- and postconditions and
• assumptions are identified.
• Some of these are obvious, such as the precondition that the student is on the correct Web page and the assumption that the student has a valid student ID and password.
• Others are not so obvious, such as the out-standing issue regarding how many times the student is allowed to log on to the system.
• Use case diagrams provide the basis for creating other types of diagrams, such as class diagrams and activity diagrams. Use case scenarios are helpful in drawing sequence diagrams.

  Both use case diagrams and use case scenarios are powerful tools to help us understand how a system works in general.

  Activity Diagrams:

• Creating Activity Diagrams
• Repository Entries for an Activity Diagram
• Activity diagrams show the sequence of activities in a process, including sequential and parallel activities, and decisions that are made. An activity diagram is usually created for

• one use case and may show the different possible scenarios.
• The symbols on an activity diagram are illustrated in Figure 10.8.
• A rectangle with rounded ends represents an activity, either a manual one, such as signing a legal document, or an auto-mated one, such as a method or program.

FIGURE 10.8. Specialized symbols are used to draw an activity

  An arrow represents an event.

• Events represent things that happen at a certain time and place.
• A diamond represents either a decision (also called a branch) or a merge.
• Decisions have one arrow going into the diamond and several going out.
• A guard condition, showing the conditionvalues, may be included.
• Merges show several events combining to form one event.
• A long, flat rectangle represents a synchronization bar.
• These are used to show parallel activities, and may have one event going into the synchronization bar and several events going out of it, called a fork.
• A synchronization in which several events merge into one event is called a join.
• There are two symbols that show the start and end of the diagram.
• The initial state is shown as a filled-in circle.
• The final state is shown as a black circle surrounded by a white circle.
• Rectangles surrounding other symbols, called swimlanes, indicate partitioning and are used to show which activities are done on which platform, such as a browser, server, or mainframecomputer; or to show activities done by different user groups.
• Swimlanes are zones that can depict logic as well as the responsibility of a class.
• You can see an example of swimlanes in Figure 10.9, which illustrates an activity diagram for the Change Student Information use case.

• It starts with the student logging onto the system by filling out a Web form and clicking the Submit button. The form is transmitted to the Web
• server, which then passes the data to the mainframe computer.
• The mainframe accesses the STUDENT database and passes either a “Not

• The diamond below the Get Student Record state indicates this decision.
• If the student record has not been found, the Web server displays an error message on the Web page.
• If the student record has been found, the Web server formats a new Web page containing the current student data in a Web form.
• The student may cancel the change from either the Logon System or the Enter Changes states, and the activity halts. If the student enters changes on the Web form and clicks the • Submit button, the change data is transmitted to the server and a program starts running that validates the changes.
• If there are errors, an error message is sent to the Web page. If the data are valid, the student record is updated and a • Change Student Journal Record is written.
• After a valid update, a confirmation Web page is sent to the browser and the activity terminates.

  Creating Activity

Diagrams

• Activity diagrams are created by asking what happens first, what happens second, and so on. You must determine whether activities are done in sequence or in parallel. If
• physical data flow diagrams (as described in Chapter 7) have been created, they may be examined to determine the sequence of activities.
• Look for places where decisions are made, and ask what happens for each of the decision outcomes.

  Activity diagrams may be created by examining all the scenarios for a use case.

  Each path through the various decisions included on the use case is a different scenario. In the main path would be Logon System, Receive Web Form,Get Student

• Record, Display Current Student Data, Enter Changes, Validate Changes, Update Student Record, Create Change Student Journal Record, and Display Confirmation. This isn’t the only scenario that comes from this use case.
• Other scenariosmay occur. One possibility could be Logon System, Receive Web
• Form, Get Student Record, and Display Error Message.
• Another scenario could be Logon System, ReceiveWeb Form, Get Student Record, DisplayCurrent StudentData, EnterChanges,ValidateChanges, andDisplay ErrorMessage.

  The swimlanes are useful to show how the data must be transmitted or • converted, such as from Web to server or from server to mainframe.

  For example, the Change Student Record activity diagram has three • swimlanes.

  The swimlane on the left shows activities that occur on the client browser. • Web pages must be created for these activities. •

• The middle swimlane shows activities that happen on the server.
• Events, such as Form Transmitted, represent data transmitted from the browser to the server, and there must be programs on the server to receive and process the client data. The swimlane on the right represents the mainframe computer. •
• In large organizations it is typical for many Web applications to work with a mainframe computer.
• Much of the data in large organizations exists on mainframe databases and there is an enormous number of mainframe programs in existence.

  When an event crosses the swimlane from the server to the mainframe computer, there must be a mechanism for transmitting the event data between the two platforms.

• (they use a format called EBCDIC).

  Servers use a different format to represent data (ASCII) than do mainframe computers

• Middleware must be present to take care of the conversion.

  IBM computers often use an mqueue (for message queue).

  The mqueue receives data from the server programs, places it in a holding area, and calls a mainframe program, usually written in a language called CICS.

• This program retrieves or updates the data, and sends the results back to the mqueue.
• In the example activity diagram shown, the decision below the Get Student Record state is made on the mainframe computer.
• This means that the message queue receives either a “Not Found” message or the database record for the student. If the mainframe simply placed the Record Status Received in the message queue
>and the decision was evaluated on the server, the server would have to call the mainframe again to obtain the valid data. This would slow down the response to the person waiting at the browser.

  Swimlanes also help to divide up the tasks in a team.

• Web designers would be needed for the Web pages displayed on the client browser. Other members would work with programming languages, such as Java, PHP, Ruby on Rails, PERL, or .NET, on the server. Mainframe CICS programmers would write programs that would work with the message
• queue.
• The analyst must ensure that the data that the various team members need is available and correctly defined. Sometimes the data in the message queue is an XML document. If an outside
• organization is involved, the data also might be an XML document.
• The activity diagram provides a map of a use case, and allows the analyst to experiment with moving portions of the design to different platforms and ask “What if?” for a variety of decisions. The use of unique symbols and swimlanes makes this diagram one that people want to
• use to communicate with others. Activity diagrams may be used to construct test plans.
• Each event must be tested to see whether the activity diagram goes to the next state.
>Each decision must be tested to see whether the correct path is taken when the decision conditions occur.

• Activity diagrams are not used for all use cases. Use

  the activity diagram when: 1) It helps to understand the activities of a use case.

  2) The flow of control is complex. 3) There is a need to model workflow. 4) All scenarios need to be shown.

• The analyst would not need an activity diagram when the use case is simple or there is a need to model the change of state.

• Activity diagrams may also be used to model a lower-

  level method, showing detailed logic.

  

Repository Entries for an Activity

Diagram

• Each state and event may be further defined using a text description in a repository, which is a collection of text descriptions for the project. Describe states with information about the state,
• such as the Web page name, elements on the Web page, and so on.
• Describe events with the information that is required to communicate with the next state, such as the data from the Web form, the data that is put into a message queue, or with a description of the event that caused the transition, such as a button click.

  SEQUENCE AND COMMUNICATION DIAGRAMS

• Sequence Diagrams
• Communication Diagrams

  

Sequence Diagrams

• Sequence diagrams can illustrate a succession of interactions between classes or object instances over time. Sequence diagrams are often used to illustrate the processing described in use case • scenarios.
• In practice, sequence diagrams are derived from use case analysis and are used in systems

  design to derive the interactions, relationships, and methods of the objects in the system.

  Sequence diagrams are used to show the overall pattern of the activities or interactions in a • use case.
• Each use case scenario may create one sequence diagram, although sequence diagrams are not always created for minor scenarios. The symbols used in sequence diagrams are shown in Figure 10.10. • Actors and classes or object instances are shown in boxes along the top of the diagram. • The leftmost object is the starting object and may be a person (for which a use case actor • symbol is used), window, dialog box, or other user interface.
• Some of the interactions are physical only, such as signing a contract.
• The top rectangles use indicators in the name to indicate whether the rectangle represents an object, a class, or a class and object.

Figure 10.10. Specialized symbols used to draw a sequence diagram.

  A vertical line represents the lifeline for the class or object, which corresponds to the time from when it is created through when it is destroyed.

• destroyed. A lateral bar or vertical rectangle on the lifeline shows the focus of control when the object is busy doing things.

  An X on the bottom of the lifeline represents when the object is

• Horizontal arrows show messages or signals that are sent between the classes.
• Messages belong to the receiving class. There are some variations in the message arrows.
• Solid arrowheads represent synchronous calls, which are the most common. These are used when the sending class waits for a response from
• the receiving class, and control is returned to the sending class when the class receiving the message finishes executing.
• Half (or open) arrowheads represent asynchronous calls, or those that are sent without an expectation of returning to the sending class. An examplewould be using a menu to run a program. A return is
• shown as an arrow, sometimes with a dashed line.
• Messages are labeled using one of the following formats:
• o

  Messages are labeled using one of the following formats:

  The name of the message followed by empty parentheses: messageName().

  o

  The name of the message followed by parameters in parentheses: messageName(parameter1, parameter2 . . .).

  o

  The message name followed by the parameter type, parameter name, and any default value for the parameter in parentheses:

  

messageName(parameterType:parameterName(defaultValue).

Parameter types indicate the type of data, such as string, number, or date. o

  The message may be a stereotype, such as «Create», indicating that a new object is created as a result of the message.

• Timing in the sequence diagram is displayed from top to bottom; the first interaction is drawn at the top of the diagram, and the interaction that occurs last is drawn at the bottom of the diagram.
• The interaction arrows begin at the bar of the actor or object that initiates the interaction, and they end pointing at the bar of the actor or object that receives the interaction request.
• The starting actor, class, or object is shown on the left. This may be the actor that initiates the activity or it may be a class representing the user interface.
• Figure 10.11 is a simplified example of a sequence diagram for a use case that admits a student to a university.

• On the left is the newStudentUserInterface class that is used to obtain student information.
• The initialize() message is sent to the Student class, which creates a new student record and returns the student number. To simplify the diagram, the parameters that are sent to the Student class have • been omitted, but would include the student name, address, and so on.
• The next activity is to send a selectDorm message to the Dorm class.
• This message would include dorm selection information, such as a health dorm

  or other student requirements. The Dorm class returns the dorm name and room number.

• The third activity is to send a selectProgram message to the Program class, including the program name and other course of study information.

  The program advisor name is returned to the newStudentUserInterface class. •

• A studentComplete message is sent to the Student class with the dorm, advisor name, and other information.

Figure 10.11. A sequence diagram for student admission. Sequence diagrams emphasize the time ordering of messages. NB: dorm :asrama mahasiswa,

• Sequence diagrams can be used to translate the use case scenario into a visual tool for systems analysis.
• The initial sequence diagram used in systems analysis shows the actors and classes in the system and the interactions between them for a specific process. You can use this version of the sequence diagram to verify
• processes with the business area experts who have assisted you in developing the system requirements.
• A sequence diagram emphasizes the time ordering (sequence) of messages. During the systems design phase, the sequence diagrams are

• refined to derive the methods and interactions between classes.

• Messages from one class are used to identify class relationships.

• The actors in the earlier sequence diagrams are translated to interfaces, and class interactions are translated to class methods.
• Class methods used to create instances of other classes and to perform other internal system functions become apparent in the system design using sequence diagrams.

  Communication

Diagrams

• Communication diagrams were introduced in UML 2.0. Their original name in UML 1.x was collaboration diagrams.

  Communication diagrams describe the interactions of two or more things in the system that perform a behavior that is more than any one of the things can do alone.

• For instance, a car can be broken down into several thousand individual parts.
• The parts are put together to form the major subsystems of the vehicle: the engine, the transmission, the brake system, and so forth. The individual parts of the car can be thought of as classes,
• because they have distinct attributes and functions. The individual parts of the engine form a collaboration, because
• they “communicate” with each other to make the engine run when the driver steps on the accelerator.
• (also called participants), the communication links, and the messages that can be passed along those links.

  A communication diagram is made up of three parts: objects

• Communication di agrams show the same information as a sequence diagram but may be more difficult to read.
• In order to show time ordering, you must indicate a sequence number and describe the message.
• A communication diagram emphasizes the organization of objects, whereas a sequence diagram emphasizes the time ordering of messages. A communication diagram will show a path to indicate how
• one object is linked to another.
• Rose, will automatically convert a sequence diagram to a communication diagram or a communication diagram to a sequence diagram with the click of a button. A communication diagram for the student admission

  Some UML modeling software, such as IBM’s Rational

• example is illustratedin Figure 10.12. Each rectangle represents an object or a class.
• Connecting lines show the classes that need to collaborate or work with each other.
• The messages sent from one class to another are shown along connecting lines. Messages are numbered to show the time sequence.
• Return values may also be included and numbered to

CLASS DIAGRAM

• Method Overloading
• Types of Classes
• Defining Messages and Methods

CLASS DIAGRAM

  Object-oriented methodologies work to discover classes, attributes, methods, • and relationships between classes.

  Because programming occurs at the class level, defining classes is one of the • most important object-oriented analysis tasks.

  Class diagrams show the static features of the system and do not represent • any particular processing.

• A class diagram also shows the nature of the relationships between classes.

  Classes are represented by a rectangle on a class diagram. •

• In the simplest format, the rectangle may include only the class name, but may also include the attributes and methods. Attributes are what the class knows about characteristics of the objects, and • methods (also called operations) are what the class knows about how to do things.
• Methods are small sections of code that work with the attributes.
• offerings.

Figure 10.13 illustrates a class diagram for course

• Notice that the name is centered at the top of the class, usually in boldface type.
• The area directly below the name shows the attributes, and the bottom portion lists the methods. The class diagram shows data storage requirements as
• well as processing requirements.
• Later in the chapter we will discuss the meaning of the diamond symbols shown in this figure.

Figure 10.13. A class diagram for course offerings. The filled-in diamonds show

• private, or only available in the object. This is represented on a class diagram by a minus sign in

  The attributes (or properties) are usually designated as

• front of the attribute name.
• Attributes may also be protected, indicated with a pound symbol (#).
• These attributes are hidden from all classes except immediate subclasses.
• Under rare circumstances, an attribute is public, meaning that it is visible to other objects outside its class. Making attributes private means that the attributes are only
• available to outside objects through the class methods, a technique called encapsulation, or information hiding.
• A class diagram may show just the class name; or the class name and attributes; or the class name, attributes, and methods.

• Showing only the class name is useful when the diagram is very complex and includes many classes. If the diagram is simpler, attributes and methods may be
• included.
• When attributes are included, there are three ways to show the attribute information.
• The simplest is to include only the attribute name, which takes the least amount of space. The type of data (such as string, double, integer, or date)
• may be included on the class diagram.
• The most complete descriptions would include an equal sign () after the type of data followed by the initial value for the attribute.
• Figure 10.14 illustrates class attributes.

Figure 10.14. An extended Student class that shows the type of data and, in

• If the attribute must take on one of a finite number of values, such as a student type with values of F for full-time, P for part-time, and N for nonmatriculating, these may be included in curly brackets separated by commas: studentType:char{F,P,N}.
• Information hiding means that objects’methods must be available to other classes, so methods are often public, meaning that they may be invoked from other classes. On a class diagram, public messages (and any public attributes) are shown with
• a plus sign () in front of them. Methods also have parentheses after them, indicating that data may be passed
• as parameters along with the message.
• The message parameters, as well as the type of data, may be included on the class diagram.
>There are two types of methods: standard and custom. Standard methods are basic things that all classes of objects know how to do, such as create a new object instance. Custom methods are designed for a specific class.

  Method Overloading

• Method overloading refers to including the same method (or operation) several times in a class. The method signature includes the method name and the parameters included
• with the method.
• The same method may be defined more than once in a given class, as long as the parameters sent as part of the message are different; that is, there must be a different message signature. There may be a different number of parameters, or the parameters might be a

• different type, such as a number in one method and a string in another method.

• An example of method overloading may be found in the use of a plus sign in many programming languages. If the attributes on either side of the plus sign are numbers, the two numbers are
• added. If the attributes are strings of characters, the strings are concatenated to form one long string. In a bank deposit example, a deposit slip could contain just the amount of the
• deposit, in which case the bank would deposit the entire amount, or it could contain the deposit amount and the amount of cash to be returned. Both situations would use a deposit check method, but the parameters (one situation would also request the amount of cash to be returned) would be different.

TYPES OF CLASSES: 1) ENTITY CLASSES.

2) BOUNDARY, OR

INTERFACE, CLASSES.

  3) ABSTRACT CLASSES.

4) CONTROL CLASSES.

1) ENTITY CLASSES

  Entity classes represent real-world items, such as people, things, and so on. •

• Entity classes are the entities represented on an entity-relationship diagram. CASE tools such as Visible Analyst will allow you to create a UML entity class from an entity on an E-R diagram. The analyst needs to determine which attributes to include in the classes. •

• • Each object has many attributes, but the class should include only those that

  are used by the organization.

  For example, when creating an entity class for a student at a college, you • would need to know attributes that identify the student, such as home and campus address, as well as grade point average, total credits, and so on.

• If you were keeping track of the same student for an online clothing store, you would have to know basic identifying information, as well as other descriptive attributes such as measurements or color preferences.

2) BOUNDARY, OR INTERFACE, CLASSES

• Boundary, or interface, classes provide a means for users to work with the system. There are two broad categories of interface classes: human and system.
• A human interface may be a display, window,Web form, dialog box, menu, list box, or other
• display control. It may also be a touch-tone telephone, bar code, or other way for users to interact with the
• system. Human interfaces should be prototyped (as described in Chapter 6), and often a storyboard is used to model the sequence of interactions. System interfaces involve sending data to or receiving data from other systems.
• This may include databases in the organization.
• If data are sent to an external organization, they are often in the form of XML files or other well- published interfaces with clearly defined messages and protocols.
• External interfaces are the least stable, because there is often little or no control over an external partner who may alter the format of the message or data.
• The XMLdocument, but a corporation transforming the data to a format that may be used to append to an internal database may simply choose to ignore the additional elements without any problems. The attributes of these classes are those found on the display or report. The methods are those

  XML helps to provide standardization, because an external partner may add new elements to

• required to work with the display, or to produce the report.

  3) ABSTRACT CLASSES

• Abstract classes are classes that cannot be directly instantiated.
• Abstract classes are those that are linked to

  concrete classes in a generalization/

  specialization (gen/spec) relationship. The name of an abstract class is usually
• denoted in italics.

4) CONTROL CLASSES

• Control, or active, classes are used to control the flow of activities, and they act as a coordinator when implementing classes. To achieve classes that are reusable, a class diagram may include many small control classes. •
• Control classes are often derived during system design.
• Often a new control class will be created just to make another class reusable. An example would be the logon process. •
• There might be one control class that handles the logon user interface, containing the logic to check the user ID and password.
• The problem that arises is that the logon control class is designed for a specific logon display. By creating a logon control class that handles just the unique logon display, the data may be passed to a • more general validation control class, which performs a check on user IDs and passwords received from many other control classes receiving messages from specific user interfaces.
• This increases reusability and isolates the logon verification methods from the user interface handling methods. The rules for creating sequence diagrams are that all interface classes must be connected to a control • class.
• Similarly, all entity classes must be connected to a control class. Interface classes, unlike the other two, are never connected directly to entity classes.

  Defining Messages and Methods Each message may be defined using a notation similar to that described for the

• data dictionary (as shown in Chapter 8).
• The definition would include a list of the parameters passed with the message as well as the elements contained in the return message.
• The methods may have logic defined using structured English, a decision table, or a decision tree, as depicted in Chapter 9.
• The analyst can use the techniques of horizontal balancing with any class method.
• All the data returned from an entity class must be obtained either from the attributes stored in the entity class, from the parameters passed on the message sent to the class, or as a result of a calculation performed by the method of the class. The method logic and parameters must be examined to ensure that the method
• logic has all the information required to complete its work.
• Horizontal balancing is further described in Chapter 7.

ENHANCING SEQUENCE DIAGRAMS:

• A Class Example for the Web
• Presentation, Business, and Persistence Layers in Sequence Diagrams

ENHANCING SEQUENCE DIAGRAMS:

• Once the class diagram is drawn, it may be desirable to go back to the sequence diagram and

  include special symbols for each of the different types of classes introduced in the last section.

  Sequence diagrams in particular can be overbearing if an analyst doesn’t have a systematic

  approach to drawing them. The following steps are a useful approach to enhancing a sequence

  diagram:

  1) Include the actor from the use case diagram in the enhanced sequence diagram.

  This will be a stick figure from the use case diagram. There may be an additional actor on the right side of the diagram, such as a credit card company or bank.