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

,

Contents:

• Object-Oriented Concepts

• Objects / Classes / Inheritance

• CRC Cards and Object Think

• The Unified Modeling Language (UML) Concepts and Diagrams

• Use Case Modelling

• Package and Other UML Artifacts

• Putting UML To Work

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.

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

Concept

1)

Object

2)

Classes

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}

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.

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.

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

Classes :

• An attribute describes some property that is possessed by all objects of the class.

• 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.

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}

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.

• Inheritance reduces programming labor by using common objects easily.

• 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.

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

The Unified Modelling Language (UML) Concepts and Diagram

• _{The UML approach is well worth investigating and} understanding, due to its wide acceptance and usage. • _{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.

• _{UML consists of things, relationships, and}

diagrams, as illustrated in Figure 10.3.

• _{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.

• _{An example of a group thing is a package.}

• _{Finally, we have annotational things, so that we}

• _{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.

• _{The four basic types of behavioral}

• _{There are two main types of diagrams in UML:}

structural diagrams and behavioral diagrams.

• _{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,}

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.

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.

• A use case always describes three things: an actor that initiates an event; the event that triggers a use case; and the use case that performs the actions triggered by the event.

• 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.

• 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.

•

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,

• _{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}

Activity Diagrams:

•

_Creating

_Activity

Diagrams

•

_{Repository Entries for}

• _{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 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.

•

_{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}

• 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.

Creating Activity

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.

• 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.

• 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.

• Servers use a different format to represent data (ASCII) than do mainframe computers (they use a format called EBCDIC).

• 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.

• 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

•

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

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

SEQUENCE AND COMMUNICATION

DIAGRAMS

•

_{Sequence 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.

• 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.

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

• 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:

oThe name of the message followed by empty parentheses:

messageName().

o The name of the message followed by parameters in parentheses:

messageName(parameter1, parameter2 . . .).

oThe 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.

•

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

• 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,

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.

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 because they have distinct attributes and functions.

• A communication diagram is made up of three parts: objects (also called participants), the communication links, and the messages that can be passed along those links.

• _{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.

• Some UML modeling software, such as IBM’s Rational 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 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.

CLASS DIAGRAM

•

_{Method Overloading}

•

_{Types of Classes}

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.

• Figure 10.13 illustrates a class diagram for course offerings.

• 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.

• The attributes (or properties) are usually designated as private, or only available in the object.

• This is represented on a class diagram by a minus sign in 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.

• 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.

• 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.

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.

TYPES OF CLASSES:

1)

ENTITY CLASSES.

2)

BOUNDARY,

OR

INTERFACE,

CLASSES.

3)

ABSTRACT 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.

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.

• XML helps to provide standardization, because an external partner may add new elements to 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.

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.

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.

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

• The method logic and parameters must be examined to ensure that the method logic has all the information required to complete its work.

ENHANCING SEQUENCE DIAGRAMS:

•

_{A Class Example for the Web}

•

_{Presentation,}

_Business,

_and

• 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.

2) Define one or more interface classes for each actor. Each actor should have his or her own interface class.

3) Create prototype Web pages for all human interfaces.

4) Ensure each use case has one control class, although more may be created during the detailed design. Look for that control class and include it in the sequence diagram.

5) Examine the use case to see what entity classes are present. Include these on the diagram.

6) Realize that the sequence diagram may be modified again when doing detailed design, such as creating additional Web pages or control classes (one for each Web form submitted).

7) To obtain a greater degree of reuse, consider moving methods from a control class to an entity class.

A Class Example for the Web

• Classes may also be represented using special symbols for entity, boundary (or interface), and control classes.

• _{These are called stereotypes, an extension to UML, which are}

special symbols that may be used during analysis, but are often used when performing object-oriented design.

• _{They allow the analyst freedom to play with the design to}

optimize reusability.

• _{The different types of classes are often used when working in}

the systems design phase.

• _{Figure 10.15 is an example illustrating a sequence diagram}

representing a student viewing his or her personal and course information.

• _{In the diagram, :View Student User Interface is an}

• The student is shown on the left as an actor, and he or she provides a userLogon to the :View Student User Interface class.

• This is a Web form that obtains the student’s user ID and password.

• When the student clicks the Submit button, the Web form is passed to a :View Student Interface Controller.

• This class is responsible for the coordination of sending messages and receiving returned information from all the other classes.

• The :View Student Interface Controller sends a

• The studentWebPage is returned to the :View Student User Interface, which displays the information in the Web browser.

• At the bottom of the page is a nextButton that the student clicks to view courses. When the user clicks this button, it sends a Web form to the :View Student Interface Controller.

• This form contains the studentNumber(), sent along with the studentWebPage, and is used to send a message to the :Section class to obtain the section grade.

• The :View Student Interface Controller class sends a getSection() message

to the :Section class, which returns a

sectionGrade.

• The :Section class also sends a

calculateGPA() message to

the :Calculate Grade Point Average

class, which sends a message back to the :Course class.

• _{The :Course class returns the credits,}

which enables the :Calculate Grade

Point Average class to determine the

• The :View Student Interface Controller would repeat sending messages to the :Section class until all sections for the student have been included.

• At this time, the :View Student Interface Controller would send the courseWebPage to the :View Student User Interface class, which would display the information in the browser.

• Using the user interface, control, and entity classes also allows the analyst to explore and play with the design. • The design mentioned previously would display all the

student personal information on one page and the course information on a second page.

• The analyst may modify the design so that the student personal information and the course information appear on one Web page.

One of the difficulties for the analyst is to determine how to include the

studentNumber after clicking the Next button, because the :Student class is no longer available. There are three ways to store and retransmit data from a Web page:

1) Include the information in the URL displaying in the address or location area of the browser. In this case, the location line might read something like the following: application involves medical information, credit card numbers, and so on, this is not a good choice.

Most browsers will also display previous Web address data in subsequent sessions if the user enters the first few characters, and the information may be compromised, leading to identity theft.

2) Store the information in a cookie, a small file stored on the client (browser) computer.

Cookies are the only way to store data that have persistence, existing beyond the current browser session. This enables the Web page to display a message such as “Welcome back, Robin.

3) Web form fields. These fields usually contain data that are sent by the server, are invisible, and do not occupy any space on the Web page. In the view student information example, the :View Student Interface Controller class added a hidden field

containing the studentNumber to the studentWebPage form along with the

nextButton. When the student clicks the

nextButton, the studentNumber is sent to the server and the :View Student Interface Controller knows which student

to obtain course and grade information for.

Presentation, Business, and Persistence Layers in Sequence Diagrams

• In the previous example, we showed all of the classes in the same diagram. When it comes to writing code for systems, it has been useful to look at sequence diagrams as having three distinct layers as follows:

1) The presentation layer, which represents what the user sees. This layer contains the interface or boundary classes.

2) The business layer, which contains the unique rules for this application. This layer contains the control classes.

• Ideally program code would be written separately for each of these layers.

• With the introduction of Ajax, the lines became blurred.

• Ajax, an acronym for asynchronous JavaScript and XML, is a collection of techniques that allows Web applications to retrieve information from the server without altering the display of the current page.

• This turns out to be an advantage because the entire Web page does not need to be reloaded when it gets additional data from the server.

• Before Ajax was created a user visiting aWeb site would answer some questions by entering data on aWeb-based form, then wait until a new page loaded.

• This was necessary because the code to validate, get the data, then answer the user resided on the server.

• With the advent of Ajax, the Web page is updated rapidly because much of the validation and other control logic is now included in the browser JavaScript code or on the client side.

ENHANCING

CLASS DIAGRAMS

1.

Relationships

2.

Generalization/

Specialization

(Gen/

•

The class symbols also may be used on class and

communication diagrams. Figure 10.16 illustrates

•

the class diagram for a student viewing personal

and course information on Web pages.

•

Each class has attributes and methods (which are

not shown on diagrams using this notation).

ENHANCING

• If the class is a user interface type of class, the attributes are the controls (or fields) on the screen or form.

• The methods would be those that work with the screen, such as submit or reset.

• They might also be JavaScript for a Web page, because the code works directly with the Web page.

• If the class is a control class, the attributes would be those needed to implement the class, such as variables used just in the control class.

• If the class is an entity class, the attributes represent those stored for the entity and the methods working directly with the entity, such as creating a new instance, modifying, deleting, obtaining, or printing.

• Web sites may use a combination of many different classes to accomplish user objectives.

• For example, a Web site may use JavaScript to prevalidate data, then pass data to the server control classes, which perform thorough validation, including obtaining data.

• The server control classes may in turn send JavaScript back to the Web page to do some formatting.

1. Relationships

• Another way to enhance class diagrams is to show relationships. Relationships are connections between classes, similar to those found on an entity-relationship diagram.

• These are shown as lines connecting classes on a class diagram.

1)

ASSOCIATIONS

2)

WHOLE/PART RELATIONSHIPS

1) Association

• The simplest type of relationship is an association, or a structural connection between classes or objects.

• Associations are shown as a simple line on a class diagram.

• The end points of the line are labeled with a symbol indicating the multiplicity, which is the same as cardinality on an entity-relationship diagram.

• A zero represents none, a one represents one and only one, and an asterisk represents many.

• The notation 0..1 represents from zero to one, and the notation 1..* represents from one to many.

Penjelasan Figure 10.17:

• Mahasiswa Lulusan (Graduate Student) mempunyai satu dan hanya satu Thesis.

• Thesis dipunyai satu dan hanya satu Mahasiswa Lulusan (Graduate Student).

• Mahasiswa (Student) daftar paling sedikit satu matakuliah (Course) sampai beberapa matakuliah.

• Matakuliah (Course) didaftar satu dan hanya satu Mahasiswa(Student).

• Mahasiswa(Student) dapat tidak menempati Ruang Asrama (Dorm Room) sampai beberapa kali.

• Ruang Asrama (Dorm Room) ditempati satu dan hanya satu Mahasiswa(Student) .

• Mahasiswa(Student) dapat tidak berpartisipasi dalam Kegiatan Sukarela (Volunteer Activity) sampai beberapa kali.

•

Class diagrams do not restrict the lower limit for an

association.

•

_{For example, an association might be 5..*,}

indicating that a minimum of five must be present.

The same is true for upper limits.

•

For example, the number of courses a student is

currently enrolled in may be 1..10, representing

from 1 to 10 courses. It can also include a range of

values separated by commas, such as 2, 3, 4.

•

In the UML model, associations are usually labeled

•

Association classes are those that are used to break

up a many-to-many association between classes.

•

These are similar to associative entities on an

entity-relationship diagram.

•

Student and Course have a many-to-many

relationship, which is resolved by adding an

association class

called

Section between the

classes of Student and Course.

•

Figure 10.18 illustrates an association

class

called

Section, shown with a dotted line

•

An object in a class may have a relationship to

other objects in the same class, called a reflexive

association.

•

An example would be a task having a precedent

task, or an employee supervising another

employee.

2) WHOLE/PART RELATIONSHIPS

•

Whole/part relationships are when one class

represents the whole object and other classes

represent parts.

•

The whole acts as a container for the parts.

•

_{These relationships are shown on a class diagram by}

a line with a diamond on one end.

•

The diamond is connected to the object that is the

whole.

•

Whole/part relationships (as well as aggregation,

• A whole/part relationship may be an entity object that has distinct parts, such as a computer system that includes the computer, printer, display, and so on, or an automobile that has an engine, brake system, transmission, and so on.

• Whole/part relationships may also be used to describe a user interface, in which one GUI screen contains a series of objects such as lists, boxes, or radio buttons, or perhaps a header, body, and footer area.

• Whole/part relationships have three categories: aggregation, collection, and composition.

2) WHOLE/PART RELATIONSHIPS

a)

Aggregation

b)

Collection

a) Aggregation

• An aggregation is often described as a “has a” relationship.

• Aggregation provides a means of showing that the whole object is composed of the sum of its parts (other objects).

• In the student enrollment example, the department has a course and the course is for a department.

• This is a weaker relationship, because a department may be changed or removed and the course may still exist.

• A computer package may not be available any longer, but the printers and other components still exist.

b) Collection

•

_{A collection consists of a whole and its}

members.

•

_{This may be a voting district with}

voters or a library with books.

•

_{The voters or books may change, but}

the whole retains its identity.

c)Composition

• Composition, a whole/part relationship in which the whole has a responsibility for the part, is a stronger relationship, and is usually shown with a filled-in diamond.

• Keywords for composition are one class “always contains” another class. If the whole is deleted, all parts are deleted.

• An example would be an insurance policy with riders.

• If the policy is canceled, the insurance riders are also canceled.

• In a database, the referential integrity would be set to delete cascading child records.

• In a university there is a composition relationship between a course and an assignment as well as between a course and an exam.

2. Generalization/Specialization (Gen/Spec) Diagrams

• A generalization/specialization (gen/spec) diagram may be considered to be an enhanced class diagram. • Sometimes it is necessary to separate out the

generalizations from the specific instances.

• As we mentioned at the beginning of this chapter, a koala bear is part of a class of marsupials,

• which is part of a class of animals. Sometimes we need to distinguish whether a koala bear is an

• animal or a koala bear is a type of animal. Furthermore, a koala bear can be a stuffed toy animal.

a) GENERALIZATION

b) INHERITANCE

c) POLYMORPHISM

d) ABSTRACT CLASSES

e) IDENTIFYING ABSTRACT CLASSES

f) FINDING CLASSES

g) DETERMINING CLASS METHODS

h) MESSAGES

a) GENERALIZATION

• A generalization describes a relationship between a general kind of thing and a more specific kind of thing.

• This type of relationship is often described as an “is a” relationship.

• _{For example, a car is a vehicle and a truck is a vehicle.}

• In this case, vehicle is the general thing, whereas car and truck are the more specific things.

• _{Generalization relationships are used for modeling class}

inheritance and specialization.

b) INHERITANCE

• Several classes may have the same attributes and/or methods.

• When this occurs, a general class is created containing the common attributes and methods.

• The specialized class inherits or receives the attributes and methods of the general class. In addition, the specialized class has attributes and methods that are unique and only defined in the specialized class.

• Creating generalized classes and allowing the specialized class to inherit the attributes and methods helps to foster reuse, because the code is used many times. It also helps to maintain existing program code.

• This allows the analyst to define attributes and methods once but use them many times, in each inherited class.

• One of the special features of the object-oriented approach is the creation and maintenance of large class libraries that are available in multiple languages.

c) POLYMORPHISM

• _{Polymorphism (meaning many forms), or method overriding}

(not the same as method overloading), is the capability of an object-oriented program to have several versions of the same method with the same name within a superclass/subclass relationship.

• _{The subclass inherits a parent method but may add to it or}

modify it. The subclass may change the type of data, or change how the method works.

• For example, there might be a customer who receives an additional volume discount, and the method for calculating an order total is modified.

• The subclass method is said to override the superclass method.

• _{When attributes or methods are defined more than once, the}

most specific one (the lowest in the class hierarchy) is used.

• _{The compiled program walks up the chain of classes, looking}

d) ABSTRACT CLASSES

• Abstract classes are general classes and are used when gen/spec is included in the design.

• The general class becomes the abstract class. The abstract class has no direct objects or class instances, and is only used in conjunction with specialized classes.

• Abstract classes usually have attributes and may have a few methods.

• Figure 10.20 is an example of a gen/spec class diagram. The arrow points to the general class, or superclass.

• Often the lines connecting two or more subclasses to a superclass are joined using one arrow pointing to the superclass, but these could be shown as separate arrows as well.

• Notice that the top level is Person, representing any person.

• The attributes describe qualities that all people at a university have.

• The methods allow the class to change the name and the address (including telephone and email address).

• Student and Employee are subclasses, because they have different attributes and methods.

• An employee does not have a grade point average and a student does not have a salary. This is a simple version, and does not include employees that are students and students that work for the university.

• If these were added, they would be subclasses of the Employee and Student classes.

• Employee has two subclasses, Faculty and Administrator, because there are different attributes and methods for each of these specialized classes.

• Subclasses have special verbs to define them. These are often run-on words, using

e) IDENTIFYING ABSTRACT CLASSES

• You may be able to identify abstract classes by looking to see if a number of classes or database tables have the same elements, or if a number of classes have the same methods.

• _{You can create a general class by pulling out the common}

attributes and methods, or you might create a specialized class for the unique attributes and methods.

f) FINDING CLASSES

• There are a number of ways to determine classes. They may be discovered during interviewing or JAD sessions (described in Chapter 4), during facilitated team sessions, or from brainstorming sessions.

• Analyzing documents and memos may also reveal classes. One of the easiest ways is to use the CRC method described previously in this chapter.

• The analyst should also examine use cases, looking for nouns. Each noun may lead to a candidate, or potential, class.

• They are called candidate classes because some of the nouns may be attributes of a class.

g) DETERMINING CLASS METHODS

• The analyst must determine class attributes and methods.

• Attributes are easy to identify, but the methods that work with the attributes may be more difficult. Some of the methods are standard, and are always associated with a class, such as new(), or the «create» method, which is an extension to UML created by a person or organization, called a stereotype.

• The « » symbols are not simply pairs of greater than and less than symbols, but are called guillemots or chevrons.

• Another useful way to determine methods is to examine a CRUD matrix (see Chapter 7).

• Figure 10.21 illustrates a CRUD matrix for course offerings. Each letter requires a different method.

• If there is a C for create, add a new() method. If there is a U for update, add an update() or change() method. If there is a D for delete, add a delete() or remove() method.

• If there is an R for read, add methods for finding, viewing, or printing.

• In the example shown, the textbook class would need a create method to add a textbook, and a read method to initiate a course inquiry, change a textbook, or find a textbook.

h) MESSAGE

• In order to accomplish useful work, most classes need to communicate with one another.

• Information can be sent by an object in one class to an object in another class using a message, similar to a call in a traditional programming language.

• A message also acts as a command, telling the receiving class to do something. A message consists of the name of the method in the receiving class, as well as the attributes (parameters or arguments) that are passed with the method name.

• The receiving class must have a method corresponding to the message name.

• Since messages are sent from one class to another, they may be thought of as an output or an input.

• The first class must supply the parameters included with the message and the second class uses the parameters. If a physical child data flow diagram exists for the problem domain, it may help to discover methods.