Model:

 

What is a model?

A model is a small object usually built to scale, that represents in details another larger object.        

For example, a car model or a build complex model is small object that represents a much larger object.

Can a model represent all the detail?

A model cannot represent all the details, but it helps visualize the object.

 

What is a visual Model?

 

A visual model is a way to represent an object or a process in term of tangible representation for an audience to examine and relate to.

For example, a flowchart represents the flow of logic for a code segment.

Only computer professionals such as programmers or analysts can understand and relate to the flowchart. 

Clients or testers may not understand or relate to a flowchart.

 

A visual model is a representation of an object or a process where all the parties involved in building or working such an object or process can understand and relate to it.

All the involved parties would be able to recognize the parts of the object and spot if there is a missing part of the model of representing the object or the process.

 

 

What is a software Model?

 

A software model is the a visual model that captures the structure and behavior of architectures and components, where user, developers-programmer, managers, testers and analysts would be able to recognize the parts of the model and spot if there is a missing part or functionality of the model.

It should not show details in order to simplify the model representation.

It may consist of number of diagrams.

 

Unified Modeling Language (UML):

 

UML is an industry-standard language that allows us to clearly communicate requirements, architectures and design.

UML was originally created by Rational Software, and is now maintained by the standards organization Object Management Group (OMG).

Grady Booch, James Rumbaugh and Ivar Jacobson are the developed, unified for the UML language and standardized it.

They are known as the three Amigos.

UML can be used with any modeling and not necessary the software ones.

 

 

UML defines a number of items, which we will cover the following:

 

1.        Classes

2.        Packages

3.        Interfaces

4.        Containment – by value

5.        Containment – by reference

6.        Cardinality

7.        Dependency

8.        Navigability

9.        Diagrams

 

Class:

 

Object Oriented provides a new way of declaring a user-defined data type that has functionality. 

This user-defined data type contains both the data objects and the methods that perform certain tasks on them. 

The new type is known as a class.

A class or an ABSTRACT data type is a way of grouping logical data and the associated methods within one object (class). 

 

Package:

 

A group of classes of related classes can be grouped under a package to share values and functionality.

A package can be used to help reduce complexity of the model.

Packages can be nested or imported.

 

Interfaces

 

An interface is basically the relationship between model components (objects ).

It is also the interaction between objects.

 

Inheritance:

 

OO inheritance is represented by arrow symbol, where the parent has the arrow pointed to it.

 

Aggregation:

 

It is containment either by value or by reference.

 

Containment – by value

 

Has an object – black diamond

 

Containment – by reference

 

Has a reference or a pointer – white diamond

 

 

Cardinality:

 

Cardinality is the number of elements in a set.

It is basically the association of one object to another.

The association can be as follow:

 

1.        0..0          no association

2.        0..1          zero to one

3.        0..n          zero to n

4.        0..*          zero to many

5.        1..0          one to zero

6.        1..1          one to one

7.        1..n          one to n

8.        1..*          one to many

 

The same can be applied to the second object.

 

 

Dependency:

 

It is one object depends on another object.

The dash arrowed line shows dependency

Are there two ways dependency?

 

 

 

Navigability:

 

It is the relationship between two objects, where it can be uni-directional or bi-directional.

Uni-Directional means one object knows about another object of has a reference to it.  The second object does not know anything about the first object.

Bi-Directional means both have the knowledge of the other existence.

See the UML Guide handout.

 

 

Diagrams:

 

It is a plan, sketch, drawing, or an outline to demonstrate or explain how something works, or to clarify the relationship between the parts of the whole.

 

 

Rational Rose Software:

 

Rational Rose or Rose for short is a menu-driven application with a toolbars to help with commonly used features.

Rose supports the following UML diagrams:

 

1.        Use Case diagram

2.        Sequence diagram

3.        Collaboration diagram

4.        Class diagram

5.        State Transition diagram

6.        Component diagram

7.        Deployment diagram

 

 

Use case:

 

It is high-level piece of functionality that the system will provide.

Use Cases include anything that within the system and their relationships.

Use cases and actors describe the project scope without implementation details.

It is implementation-independent view of the system.

It is composed of actors and functionality.

All parties involved in the development can look at the case diagram and spot each individual role within the system.

They can also see what is missing from the system.

It should not be overloaded with actors and functionality to help make the diagram simple and not confusing.

Use case diagram’s main benefits are:

 

1.        Use case diagram illustrates the system functionality

2.        Communication between all parties involved in system development

3.        Visualization of the system

4.        The system components interactions.

5.        User and system interaction

6.        User expectation of the system

 

 

How to identify the use cases?

 

1.        Examine any documentation the customer provides

2.        High-level scope of the system

3.        Vision of the system

4.        Functionality of the system

5.        Expectation of the system

6.        What is the system will do

7.        What would the user get out of the system

 

Try to put a picture to every item listed above. 

See that you take user or client system description and turn it into a use case (a picture). 

Keep in mind that the objective of the use case is visualization of the system, its parts, parties and functionalities.

 

Use case should be named in business terms and not technical terms.

 

Flow of events:

 

It is to document the flow of logic in the use case.

Flow of events includes:

 

1.        Brief description

A short and to point description of the use case

 

2.        Preconditions

List of conditions that must be met before the start of the use case

 

3.        Primary flow of events

The start and end of a use case and what it will encounter including errors and how to handle them.

 

4.        Alternative flow of events

In case of errors or other things, what are the alternatives?

 

5.        Post-conditions

What must be always true after the end of use case?

 

 

 

 

 

Actor:

 

Actors include anything external to the system.

Actor is anyone or anything that interacts with the system. 

Actors illustrate the interface with the system, which can be people, machines, or software. 

An example, would be as follows:

 

1.        Human

2.        Hardware

3.        Software

4.        Timer or clock

 

Both actors and Use cases show the scope of the project.

Do not model actor-to-actor communication.

 

 

What Is the Rational Unified Process?

 

Most software engineering is amid at developing new software products, or enhancing an existing one. The Rational Unified Process is a Software Engineering Process with the following goals:

 

1.        Ensure the production of high-quality software.

2.        Meets the user’s needs. 

3.        It does that within a predictable schedule and budget.

 

There are seven known steps in any software development cycle starting with Problem Definition and ending with Maintenance.  The Rational Unified Process takes each of the step and breaks it farther down into the following four phases:

 

1.        Inception phase

2.        Elaboration phase

3.        Construction phase

4.        Transition phase

 

Each phase is concluded with a well-defined milestone, which is a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved.  The main objective of the Rational Unified Process is break down each phase into four elements, which are workers, activities, artifacts and workflows. The Rational Unified Process works with models to help visualize the system picture as a whole.  These models help all parties involved with system development communicate and modify the models with their perspective view of the problem and the system.

 

 

Static Structure of the Process:

 

A process describes who is doing what, how, and when. The Rational Unified Process is represented using four primary modeling elements:

 

1.        Workers, the "who"

2.        Activities, the "how"

3.        Artifacts, the "what"

4.        Workflows, the "when"

 

 

Workers:

 

                 Users, analysts, developers, testers and managers makeup the workforce for developing any project. Either individuals or teams of individuals do the project work and identifying he behavior and responsibilities of an individual, or a group of individuals working together as a team is critical step in each phase.  Individual or team role may change with the project progress.  The Unified Process the worker is more the role defining how the individuals should carry out the work. The responsibilities are assigned to a worker includes the following:

 

1.        Performance of a certain set of activities

2.        Being owner (responsibility) of a set of artifacts.

 

The assignment of roles and ownership (responsibility) must be clearly set ahead of time.

 

 

Activity:

 

An activity is the unit of work that an individual must perform. Assignment of activity should be made with the following categories in mind:

1.        The worker’s background

2.        The time needed to finish the work

3.        Which job is a bottleneck

4.        Cooperation may be need.

5.        Order sequence of jobs.

 

 

 

Artifact:

 

Artifacts are the tangible products of the project, the things the project produces or uses while working towards the final product. Artifacts are used as input by workers to perform an activity, and are the result or output of such activities. Artifacts may take various shapes or forms:

 

1.        A model, such as the Use-Case Model or the Design Model

2.        A model element, such as a class, a use case or a subsystem

3.        A document, such as Business Case or Software Architecture Document

4.        Source code

5.        Executables

 

 

Workflows:

 

It is sequences of activities that produce some valuable result, and show the interactions between workers. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. The use of a form of activity diagrams in this white paper.

 

Inception Phase (Setting up or Launch Phase)

 

This is the setup phase or launching phase, where high-level interactions with actors are defined.  It should identify all external entities with which the system interacts.  This phase should simplify the scope of project. This involves the following:

 

1.        Identifying all use cases

2.        Describing a few significant ones.

3.        The business case includes success criteria, risk assessment

4.        Estimate of the resources needed

5.        Establish a phase plan showing dates of major milestones.

 

 

The outcome of the inception phase is:

 

1. A vision document: a general vision of the core project's requirements, key features, and main constraints.
2. An initial use-case model (10%-20% complete).
3. An initial project glossary (may optionally be partially expressed as a domain model).
4. An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast.
5. An initial risk assessment.
6. A project plan, showing phases and iterations.
7. A business model, if necessary.
8. One or several prototypes.

 

 

Elaboration Phase

 

The meaning of the word “Elaboration” is expansion or explanation.  In order for you to explain it or expand it, you have to having the understanding of the whole system, its scope, its major functionality and requirements. The purpose of the elaboration phase is to do the following:

 

1.        Analyze the problem domain

2.        Establish a sound architectural foundation

3.        Develop the project plan

4.        Eliminate the highest risk elements of the project.

 

The outcome of the elaboration phase is:

 

1. A use-case model (at least 80% complete) - all use cases and actors have been identified, and most use-case descriptions have been developed.
2. Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case.
3. A Software Architecture Description.
4. An executable architectural prototype.
5. A revised risk list and a revised business case.
6. A development plan for the overall project, including the coarse-grained (rough) project plan, showing iterations and evaluation criteria for each iteration.
7. An updated development case specifying the process to be used.
8. A preliminary user manual (optional).

 

 

Construction Phase:

 

This is the production phase, where the product is developed, tested and integrated.  Managing this phase is very crucial. All the work that is done in previous phases will payoff in this phase. This phase needs the following:

 

1.        Development Plans

2.        Managing resources

3.        Controlling operations to optimize costs, schedules, and quality

4.        Parallel construction

5.        Workflow synchronization

 

The outcome of the construction phase is a product ready to put in hands of its end-users. At minimum, it consists of:

 

1. The software product integrated on the adequate platforms.
2. The user manuals.
3. A description of the current release.

 

 

Transition Phase

 

The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed. This includes:

 

1. "Beta testing" to validate the new system against user expectations
2. Parallel operation with a legacy system that it is replacing
3. Conversion of operational databases
4. Training of users and maintainers
5. Roll-out the product to the marketing, distribution, and sales teams

 

The transition phase focuses on the activities required to place the software into the hands of the users. Typically, this phase includes several iterations, including beta releases, general availability releases, as well as bug-fix and enhancement releases. Considerable effort is needed in developing user-oriented documentation, training users, supporting users in their initial product use, and reacting to user feedback.  User feedback should be confined primarily to product tuning, configuring, installation, and usability issues. The primary objectives of the transition phase include:

 

1. Achieving user self-supportability
2. Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision
3. Achieving final product baseline as rapidly and cost effectively as practical

 

This phase can range from being very simple to extremely complex, depending on the type of product. For example, a new release of an existing desktop product may be very simple, whereas replacing a nation's air-traffic control system would be very complex

 

 

Iterations

 

Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product or a subset of the final product.

The system can grow incrementally from iteration to iteration to become the final system.

 

 

Benefits of an Iterative Approach

 

Compared to the traditional waterfall process, the iterative process has the following advantages:

 

1. Risks are mitigated earlier
2. Change is more manageable
3. Higher level of reuse
4. The project team can learn along the way
5. Better overall quality