Systems, Process and Use Case Modeling

Introduction

Use case modeling has become the foundation of the most popular de facto standard technique for performing software requirements analysis and specification. However, use case modeling has its well-known problems, and different requirements engineers typically perform use case modeling differently. This paper provides a hierarchically organized set of detailed guidelines for use case modeling (Whitten, Jeffrey, Lonnie Bentley and Kevin Dittman 2007).

The use case model describes the functionality of the system in terms of actions performed by the user of the system (an Actor) and a description of how the system responds to those actions. Not all use cases are developed at this time.

a use case is a technique for capturing functional requirements of systems. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end-users or other systems. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert. Use cases are often co-authored by business analysts and end-users.

use-case modeling facilitates and encourages user involvement which is one of the primary critical success factors for ensuring project success.( Richard Denney 2005).

The benefits of use-case modeling

• Provides a means of identifying, assigning, tracking, controlling and managing system development activities, especially incremental and iterative development.
• Provides an aid in estimating project scope , effort and schedule.
• Provides a baseline for user help systems and manuals as well as system development documentation.
• Provides a tool for requirement traceability.
• Provides a starting point for the identification of data objects or entities.
• Provides a tool for capturing functional requirements.
• Assists in decomposing system scope into more manageable pieces.
• Provides a means of communicating with users and other stakeholders concerning system functionality.
• Provides a means of defining access requirements in terms of adds, changes ,deletes and read.
• Provide a framework for driving the system development project.

How to perform use-case modeling

There are two primary artifacts involved when performing use-case modeling , the first is the use-case diagram which graphically depicts the system as collection of use cases, actors and their relationships. The diagram communicates at a high level the scope of the business events that must be processed by system.

The second artifact called use-case narrative fills in the details of each business event and specifies how the users interact with the system during that event (Richard Denney 2005).

Use case modeling identifies and describes the system functions by using tools called use cases.

Use case

• A use case is a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system”.
• Describes WHAT the system (as a “Black Box”) does from a user’s (actor) perspective.
• The Use Case Model is NOT an inherently object-oriented modeling technique (Whitten, Jeffrey, Lonnie Bentley and Kevin Dittman 2007).

The use cases describe the system functions from the perspective of external users and in manner and terminology they understand.and also represented graphically by a horizontal ellipse with the name of the use case appearing above, below or inside the ellipse. Use case represents a single goal of the system and describes a sequence of activities and user interaction in trying to accomplish the goal.

Use cases are initially defined during the requirements stages of the life cycle and will be additionally refined throughout the life cycle.

The use cases are refined to model usage of the system in more detail m they are updated to specify what the users are trying to accomplish and why.

Advantages of Use Case-modeling

• Use cases are the primary vehicle for requirements capture in RUP
• Use cases are described using the language of the customer (language of the domain which is defined in the glossary)
• Use cases provide a contractual delivery process (RUP is Use Case Driven)
• Use cases provide an easily-understood communication mechanism
• When requirements are traced, they make it difficult for requirements to fall through the cracks
• Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

Disadvantages and problems with Use Case-modeling

• As functional decompositions, it is often difficult to make the transition from functional description to object description to class design
• Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult
• Use Cases make stating non-functional requirements difficult
• Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements are not obvious (Richard Denney 2005).

Actors

Use cases are initiated or triggered by external users called actors. An actor initiates system activity’s use case for the purpose of completing some business task that produces something of measurable value.

There are four types of actors

Primary business actor : the stakeholder that primarily benefits from the execution of the use case by receiving something of measurable or observable value. The primary business actor may or may not initiate the business event.

Primary system actor : the stakeholder that directly interfaces with the system to initiate or trigger the business or system event. primary system actors may interact with primary business actors for the purpose or using the actual system. They facilitate the event through the direct use of the system for the benefits of the primary business actor.( Richard Denney 2005).

• External server actor : the stakeholder that responds to a request from the use case.
• External receiver actor : the stakeholder that is not the primary actor but receives something of measurable or observable value from the use case e.g. warehouse receiving a packing order to prepare a shipment after a customer has placed an order.

Relationships

A relationship is depicted as a line between two symbols on the use case diagram. the meaning of relationships may differ depending on how the lines are drawn and what types of symbols they connect.

• Associations : relationship between an actor and a use case exist whenever the use case describes an interaction between them. an association that contains an arrowhead on the end touching the use case indicates the use case was imitated by the actor on the other end of the line. associations without arrowheads indicate an interaction between the use case and an external server or receiver actor. An association may be bidirectional or unidirectional (Richard Denney 2005).
• Extends : a use case may contain complex functionality consisting of several steps making the use-case logic difficult to understand.for the purpose of simplifying the use case and making it more easily understood, we can extract the more complex steps into their own use case. The resulting use case is called an extension use case in that it extends the functionality of the original use case. The relationship between the extension use case and the use case it is extending is called an extends relationship. A use case may have many extends relationships but an extension use case can be invoked only by the use case it is extending. The extends relationship is represented as an arrow-headed line either solid or dashed beginning at the extension use case and pointing to the use case it is extending. (Richard Denney 2005).
• Uses (includes) : very commonly you may discover two or more use cases that perform steps of identical functionality.it is best to extract these common steps into their own separate use case called an abstract use case. An abstract use case represents a form of reuse and is an excellent tool for reducing redundancy among use cases (Richard Denney 2005).

Sequence Diagrams

UML provides a graphical means of depicting object interactions over time in Sequence Diagrams. These typically show a user or actor, and the objects and components they interact within the execution of a use case. One sequence diagram typically represents a single Use Case ‘scenario’ or flow of events. (Ivar Jacobson 1992).

Sequence diagrams are an excellent way to document usage scenarios and to both capture required objects early in analysis and to verify object usage later in design. Sequence diagrams show the flow of messages from one object to another, and as such correspond to the methods and events supported by a class/object.

The diagram illustrated below shows an example of a sequence diagram, with the user or actor on the left initiating a flow of events and messages that correspond to the Use Case scenario. The messages that pass between objects will become class operations in the final model.

Implementation Diagram

A Use Case is a formal description of functionality the system will have when constructed. An implementation diagram is typically associated with a Use Case to document what design elements (eg. components and classes) will implement the Use Case functionality in the new system. This provides a high level of traceability for the system designer, the customer and the team that will actually build the system. The list of Use Cases that a component or class is linked to documents the minimum functionality that must be implemented by the component (Ivar Jacobson 1992).

Data modeling

There are several notations for data modeling the actual model is frequently called an relationship diagram(ERD) because it depicts data in terms of the entities and relationships described by the data and there are also several notations for ERDs most are named after their inventor or after a published standard.these data modeling generally support the same fundamental concepts and constructs. we have adopted the martin notation because of its widespread use and case tool support.

The basic concepts of data modeling

Entities

All systems contain data usually lots of data.An entity is something about which the business needs to store data. In system modeling it is useful to assign each abstract concept to a shape.

There is important difference between an entity and its instances. An entity instance is a single occurrence of an entity (Ivar Jacobson 1992).

Attributes

The data stored in each instance. And some attributes can be logically grouped into sepratattributes called compound attributes.

Domains: the values for each attribute are defined in terms of three properties: data type , domain, and default.

The data type for an attribute defines what type of data can be stored in that attribute.

Data typing should be familiar to those of you who have written computer programs , declaring types for variables are common to most programming languages.

For purposes of systems analysis and business requirements definition it is useful to declare logical data types.

An attribute’s data type constrains its domain. the domain of an attribute defines what values the attribute can legitimately take on. the system designers must use technology to enforce the business domains of all attributes (Ivar Jacobson 1992).

Every attribute should have a logical default value that represents the value of attribute if its value is not specified by the user.

Identification

An entity has many instances perhaps thousands or millions there exists a need to uniquely identify each instance based on the data value of one or more attributes.

Every entity must have a key, sometimes more than one attribute is required to uniquely identify an instance of an entity. a key consisting of a group of attributes is called a concatenated key.

An entity may have more than one key , Candidate key(candidate identifier) and it is one of a number of keys that may serve as the primary key of an entity, Primary key is that candidate key that will most commonly be used to uniquely identify a single entity instance and the default for a primary is always not null because if the key has no value it cannot serve it’s purpose to identify an instance of an entity and any candidate key that is not selected to become the primary key is called alternate key. (Ivar Jacobson 1992).

Relationships

Entities and attributes do not exist in isolation. The things they represent interact with and impact one another to support the business mission.

A relationship is a natural business association that exists between one or more entities. the relationship may represent an event that links the entities or merely a logical affinity that exists between the entities.

Cardinality defines the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity. Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship.

Degree another measure of the complexity of a data relationship , it is the number of entities that participate in the relationship. and all the relationships are binary( degree=2) that means two different entities participated in the relationship.

Relationships may also exist between different instances of the same entity ( recursive relationship).

Foreign keys a relationship implies that instances of one entity are related to instances or another entity, is should be able to identify those instances involves establishing foreign keys it is a primary key of one entity that is contributed to another entity to identify instances of relationship.

A foreign key always matches the primary key, the primary key is always contributed by the parent to the child as a foreign key. the nonidentifying relationships are those in which each of participating entities has its own independent primary key that’s mean non of the primary key attributes is shared and the identifying relationships are those in which the parent entity contributes its primary key to become part of the primary key of the child entity of any identifying relationship is frequently referred a week entity because its identification is dependent on the parent entity’s existence.

Most popular case tools and data modeling methods use different notations to distinguish between identifying and non-identifying relationships and between strong and weak entities.

A nonspecific relationship is one in which many instances of one entity are associated with many instances of another entity. these types of relationships can be resolved into a pair of one-to-many relationships each entity becomes a parent and a new associative entity is introduced as the child of each parent., for these associative entities the cardinality from child to parent is always one and only one.the cardinality from parent to child depends on the business rule. but not all nonspecific relationships can and should be resolved automatically , occasionally nonspecific relationships result from the failure of the analyst to identify the existence of other entities. (Rolland c. 1993).

The process of logical data modeling

Strategic data modeling

Many organizations select application development projects based on strategic information systems plans. Strategic planning is a separate project that produces an information system strategic plan that defines an overall vision and architecture for information systems. This architecture includes an enterprise data model, information engineering is a methodology that embraces this approach, these enterprise data model typically identifies only the most fundamental of entities , the entities are typically defined but are not described in terms of keys or attributes.(Penker, Magnus, Hans-Erik Eriksson 2000).

Decomposition Diagram

A decomposition diagram shows a high-level function, process, organization, data subject area, or another type of object broken down into lower level, more detailed components. For example, decomposition diagrams may represent organizational structure or functional decomposition into processes

The rules for decomposition are:

• Each process in a decomposition diagram is either a parent process, a child process (of a parent), or both.
• A parent must have two or more children – a single child does not make sense since that would not reveal any additional information about the system.
• In most decomposition diagramming standards, a child may have only one parent.
• A child of one parent may, of course, be the parent of its own children.

A functional decomposition diagram was useful in an information engineering environment. The functions were decomposed to processes. The processes were converted to program specifications. The program specifications were converted to program code. This was a logical progression..(Penker, Magnus, Hans-Erik Eriksson 2000).

If done properly, a functional decomposition diagram should represent the entire organization. This representation should categorize functional needs. As data warehousing has shown, the design is user-centric and is based on the needs of a particular set of users. By examining the functional decomposition diagram at the leaf (lowest) level, an inquiry should be made as to the measurements of that function. This measurement, usually a fact in a data warehouse, should represent how this function analyzes or measures their function. One should guard against analyzing what data is captured by that function, but instead focus on the measurement of fact..(Penker, Magnus, Hans-Erik Eriksson 2000).

By organizing at a fact-to-function level, an organization has a high-level understanding of the measurements across the organization. This is done by function also, as compared with by organizational unit.

The logical models show what the system does, it also illustrates the essence of the system , popular synonyms include essential model, conceptual model and business model.

Physical models show only what a system is or does but also how the system is physically and technically implemented, there are implementation-dependent because they reflect technology choices and the limitations of those technology choices.

System analysts have long recognized the value of separating business and technical concerns that is why they use logical systems models to depict business requirements and physical system models to depict technical designs (Harmsen, N. Brinkkemper, Oei 1994).

System analysis activities tend to focus on the logical system models for the following reasons:

• logical models remove biases that are the result of the way the current system is implemented or the way that anyone person thinks the system might be implemented.
• logical models reduce the risk of missing business requirements, such errors can be costly to correct after the system is implemented, by separating what the system must do from how the system will do it, it’s better to analyze the requirement for completeness , accuracy and consistency.
• Logical models allow communication with end-users in non technical or less technical language.

Logical processes and conventions

logical processes are work or actions that must be performed no matter how the implementation of system. Each logical process is implemented as one or more physical processes that may include work performed by people work performed by robots or machines, or work performed by computer software. It doesn’t matter which implementation is used because logical processes should only indicate that there is work that must be done.

An event is a logical unit of work that must be completed as a whole an event triggered by a discrete input and is completed when the process has responded with appropriate outputs. events called transactions and functions consist of processes that respond to events. (Harmsen, N. Brinkkemper,Oei 1994).

An event process can be further decomposed into elementary processes that illustrate in detail how the system must respond to an event , elementary processes are discrete , detailed activities or tasks required to complete the response to an event, it should be named with a strong action verb followed by an object clause that describes what the work is performed on (Harmsen, N. Brinkkemper,Oei 1994).

Process modeling

a model is representation of reality just as a picture is worth a thousand words , most system models are pictorial representations of reality, models can be built for existing systems as a way to better understand those systems or for purposed systems as a way to document business requirements or technical designs , an important concept is the distinction between logical and physical model.

Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and the logic policies and procedures to be implemented by a system’s process, process modeling originated in classical software. (Rolland c. 1993)

System concepts for process modeling

External agents

All information systems respond to events and conditions in the system’s environment. The environment of an information system includes external agents that form the boundary of the system and define places where the system interfaces with its environment, an external agent defines a person , an organization unit or another organization that lies outside the scope of the project but that interacts with the system, external agent provides the net inputs into a system and receive net outputs from a system.(Curtis B., M. Kellner, J. Over September 1992).

It’s important to recognize that work and activities are occurring inside the external agent, but that work and those activities are said to be “out of scope” and not subject to change, the data flows between your system and these boundaries should not cause substantive change to the work or activities performed by the external agents., the external agents of an information system are rarely fixed as project scope and goals change , the scope of an information system can either grow or shrink , if the system scope grows it can consume some of the original external agents.( Rolland c. 1993)

Datastores

Most information systems capture data for later use, the data is kept in data store, the data store is an inventory of data ,synonyms include file and database, if data flows are data in motion , think of data stores as data at rest.

If data modeling is done before process modeling identification of most data stores is simplified by this rule : ( there should be one data store for each data entity on an entity-relationship diagram)

And if Process modeling is done before data modeling , data store discovery tends to be more arbitrary, in that case it’s better to identify existing implementation of files data stores.

The recommended way that data models precede the process model.

References

Curtis, B., M. Kellner, J. Over (1992). Process Modeling, Communications of ACM, vol 35, pp 75-90.

Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley. ISBN 0-321-19368-7.

Harmsen, A. F.; J. N. Brinkkemper, J. L. H. Oei (1994). Situational Method Engineering for information Systems Project Approaches.

Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional.

Penker, Magnus; Hans-Erik Eriksson (2000). Business Modeling with UML. John Wiley & Sons.ISBN 0-471-29551-5.

Rolland, C. (1993). Modeling the Requirements Engineering Process,3rd European-Japanese Seminar on Information Modeling and Knowledge Bases.

Rolland, C.; N. Prakash, A. Benjamen (1999). A Multi-Model View of Process Modelling.Requirements Engineering. Volume 4, Number 4. London: Springer-Verlag.

Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional.

Whitten, Jeffrey, Lonnie Bentley and Kevin Dittman (2007) Systems Analysis & Design Methods New York, NY: McGraw-Hill.