Program Design Method 2

Contents Introduction Object Oriented Programming Use Case Diagram Activity Diagram Class Diagram State Diagram CRC Card Interaction Diagram Implementation Diagram

Introduction

UML or Unified Modelling Language, is mostly used in object-oriented projects. It consists of various kinds of diagrams, such as:

• Use Case Diagram: depicts the interaction between a system and its users.
• Class Diagram: depicts the relation between classes.
• Interaction Diagram: depicts how group of objects collaborate for an use case.
• State Diagram: depicts the different states of a system, subsystem, or an object during its lifetime.
• Activity Diagram: depicts the sequence of activities in a process.
• Component Diagram: depicts the physical software components of the system and the dependencies.
• Deployment Diagram: depicts the physical aspects of a system.

Traditional life cycle models:

• Waterfall: in order, or sequentially.
• V-model: variation of Waterfall, but it emphasizes how the later stages are related to the previous stages.
• Spiral: variation of Waterfall, but it incorporates iteration of life cycle stages, and it also focuses in risks in the system.
• Prototyping: implementation stage is done earlier in the process, and the model is subsequently enhanced during the process.

Traditional high-level system life cycle:

• Requirements: problems, objectives, and risks.
• Analysis: system from the client's perspective.
• Design: the construction of the system.
• Implementation: translating the models into code.
• Installation: necessary things to support clients so the system can be utilized effictively.

Object Oriented Programming

The advantages of Object Oriented Programming:

• Autonomous: does not heavily depend on other modules.
• Cohesive: single, well-defined purpose.
• Straightforward: easy to understand.
• Adaptable: can easily be adapted.
• Based on data
• Encapsulated data
• Well defined public interface

Data Encapsulation / Hiding

• Datas can be hidden inside an obect, so that they are protected and cannot be directly accessed by other parts of the program.
• Information hiding can be achieved through encapsulation, which is the process of concealing internal details of an object.
• Encapsulation is done, so that the interface of a program component reveals minimum internal information regarding the said objects.

Object
An object is a container of a set characteristics and a set of operations that can be performed on its data.

The 3 characteristics of an object:

• Behaviour: are divided into operations, each of them represents the capabilities of the object. They are triggered in response to a message from another object, asking it to perform one of its operations.
• State: is determined by the values of its attribute, and also its links to other objects.
• Identity: every object is unique, its existence is separate, and has its own space in the computer memory. The property of an object distinguishes it from the other objects.

Class
Classes are groups of objects that share common properties/attributes, relationships and behaviour. Objects are also called instances of classes. The creation of an object that belongs to a class, is called instatiation.

Polymorphism
It is a concept where different objects have different responses to the same message. This describes the use of operations of the same name for various purposes. The types of polymorphism:

• Overriding: when a parent class provides an operation, but its child class has its own definition of the said operation. The child's definition of the operation will be used.
• Overload: when there are several operations in the class with the same name, but the response will be different according to the amount of parameters that are passed.

Use Case Diagram

Use Case Diagram is a part of the UML, and it depicts the interaction between a system and its clients. It contains:

Use Case It is a process done by the actors in order to achieve a goal. The use case description describes the required functionality of the use case, the goal, and the course of events. The use case description is grouped into two: High LV Description: general information regarding use case, actor or event. Expanded Use Case: very detailed information; trigger to initiate use case, actors, necessary input, output and stored data, trigger to alert the completion of use case, minor variation in the sequences of events. Identifying use case: Identifying use case from the actors: identify the actors, the system users, how they use the system and what they use it to achieve. Identifying use case from scenarios: scenarios describe a specific sequence of events, and series of interactions between the user and the system in order to achieve a specific goal.

Actor It is an individual that can give or receive information to or from the system, or a representation of a particular way of using the system to achieve a goal.

Use Case Relationship Communication association: shows the association of each of the actor and use case, and is represented by a line that links an actor to an use case. Include: useful when there exists common behaviour to several use cases. That common behaviour can be split off into a separate use case, to avoid repitition. Exclude: shows a significant, alternative and optional functionality.

Boundary It is a box that contains use cases.

Activity Diagram

Similiar to flowchart.

Activity Diagram is a part of the UML, and it depicts the internal flow control in the process - such as sequence, selection and iteration. It contains:

Activity It is a set of actions, or processes.

Start / Initial It is the beginning of set of actions, or processes.

End / Stop It is the end of a specific process.

Transition / Connector It depicts the flow from one activities to another.

Branch It depicts the beginning, and end of a branching processes.

Condition It is the condition that decides which transition will be taken from the branching.

Synchronization It depicts the beginning, and end of a parallel processes.

Swimlane It depicts who, or what is doing the activites / processes.

Class Diagram

Class Diagram is a part of the UML, and it depicts the relation between classes. It contains:

Class

Class Relationship Association: a binary relationship that describes an activity between two classes. Numbers are also used to specify how many ... is involved in the interaction: 1: exactly one. 0..1: zero to one. 0..*: zero to many. 1..*: one to many. Aggregation: implies that child classes are independent-can exist without the existence of parent class. Composition: implies that child classes are dependent-cannot exist without the existence of parent class. Generalization: combining similiar classes of objects into a more general class. Specialization: separating a class of objects into a more specific class.

Stages in building a class diagram:

• Identify the objects and derive classes.
• Identify the attributes.
• Identify relationships between classes.
• Write data dictionary to support class diagram.
• Separate responsibilities into operation & attributes.
• Write process specifications to describe the operations.

State Diagram

State Diagram is a part of the UML, and it depicts the states of a system, subsystem, or an object in its lifetime. It is used to model the dynamic aspects of a system, and to define the state changes triggered by internal or external factors. It contains:

State It is a state, or condition of the system.

Start State It is the initial state.

End State It is the end of a state. Should there be multiple states that eventually lead to the same end state, a superstate (really large rectangle) can be drawn instead.

Transition It depicts the flow from one state to another.

Self-Transition Transition that does not change the current state of the system.

Label It is the event that may change the current state of the system.

CRC Card

CRC Card is NOT a part of the UML. It is used to split the overall functionality of a system, into each of the classes. CRC Card looks like the following:
Responsibilities identifies what the class is expected to do. Collaborators are other classes that this card interacts to, in order to fulfill its responsibilities.

Interaction Diagram

Interaction Diagram consists of Sequence Diagram and Collaboration Diagram:

Sequence Diagram It is a part of the UML, and an Interaction Diagram that depicts how operations are carried out in detail, and the interaction between the objects. It contains:

Actor It is an individual that can give or receive information to or from the system, or a representation of a particular way of using the system to achieve a goal.

Object An instance of class.

Frame There are several labels (written on the top-left of the frame) that can be used, but some of the common ones are: alt: alternative actions that depends on a given condition. loop: repeatable actions.

Message Message describes the communication between two lifelines. There are two types of message: Synchronous: requires a response to continue. Asynchronous: does not require a response to continue.

Message Return A message sent as a reply or response to the previous message sent.

Lifeline Lifeline depicts the existence of an object.

Activation Box Activation box depicts whether an object/user is performing an action or operation.

Collaboration Diagram
It is a part of the UML, and an Interaction Diagram that depicts the relationship among the objects. Though similiar to Sequence Diagram, there are several notable differences:

• Sequence diagram is drawn based on time sequence. Unlike it, collaboration diagram is not drawn that way. Hence, numbering is needed to show the sequence of the messages.
• In collaboration diagram, link between objects are explicitly modeled.
• In collaboration diagram, return messages are not modeled.

Implementation Diagram

Implementation Diagram consists of Component Diagram and Deployment Diagram:

Component Diagram
It depicts the physical software components of the system and the dependencies. This software component can be a source file, binary file, executable file, database file, library file, or a web page.

Deployment Diagram
It depicts the physical aspect of a system.

User Interface
It is what the user sees, and interacts with. Guidelines when designing an UI:

• System should be consistent.
• Minimize user tasks that are prone to errors.
• The screen should only contain relevant and necessary informations.
• Interacting with the system should be intuitive.
• Feedback should be informative, not intrusive.
• The language used in the instructions and messages to the user should be clear and concise.
• There should also be an adequate user support with clear and comprehensive instructions, and messages on line help.