MODELS AND MODELING I can’t work without a model. Complete Letters of Vincent Van Gogh , vol. 3, no. B19 When we mean to build, We first survey the plot, then draw the model; King Henry IV. Part II. Act i. Sc. 3.

Goal of Presentation This presentation will Define model and diagrams and explain importance of them to system development. Introduce UML

This presentation will

Define model and diagrams and explain importance of them to system development.

Introduce UML

Definitions A model is a simplified representation of something in the real world , usually for the purpose of understanding that reality, and having all the features of that reality necessary for the current task or problem. Like a map, a model represents something else. Thus modeling is a form of abstraction , that is, the process of focusing only on features essential to the problem at hand. Source: David William Brown, An Intro to Object-Oriented Analysis (Wiley, 2002), p. 30

A model is a simplified representation of something in the real world , usually for the purpose of understanding that reality, and having all the features of that reality necessary for the current task or problem.

Like a map, a model represents something else.

Thus modeling is a form of abstraction , that is, the process of focusing only on features essential to the problem at hand.

What Are Models For? Models are used for: To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and agree on them. To think about the design of a system. To capture design decisions in a mutable form separate from the requirements. To generate usable work products. To organize, retrieve and edit info about large systems. To explore multiple solutions economically. To master complex systems. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 13-4

Models are used for:

To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and agree on them.

To think about the design of a system.

To capture design decisions in a mutable form separate from the requirements.

To generate usable work products.

To organize, retrieve and edit info about large systems.

To explore multiple solutions economically.

To master complex systems.

Levels of Models Models take on different forms and appear at different levels of abstraction. A useful model has the right level of detail and represents only what is important for the task in hand. The amount of detail in the model is adapted to one of the following purposes: Guides to the thought process. Abstract specifications of the essential structure of a system. Full specification of a final system. Exemplars of typical or possible systems. Complete or partial descriptions of systems. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 15-6

Models take on different forms and appear at different levels of abstraction.

A useful model has the right level of detail and represents only what is important for the task in hand.

The amount of detail in the model is adapted to one of the following purposes:

Guides to the thought process.

Abstract specifications of the essential structure of a system.

Full specification of a final system.

Exemplars of typical or possible systems.

Complete or partial descriptions of systems.

Many Matching Models Each model emphasizes some aspect of the real-world thing. Thus, many models are required to reveal all the important details of that thing. Yet, these matching models must eventually fit together. What is represented in one model must be consistent with what is represented in another model. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 51

Each model emphasizes some aspect of the real-world thing.

Thus, many models are required to reveal all the important details of that thing.

Yet, these matching models must eventually fit together.

What is represented in one model must be consistent with what is represented in another model.

Diagrams Diagrams are abstract shapes that are used to represent things or actions from the real world Diagrams follow rules or standards The standards make sure that different people will interpret the diagram in the same way Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 98-9. 40°

Diagrams are abstract shapes that are used to represent things or actions from the real world

Diagrams follow rules or standards

The standards make sure that different people will interpret the diagram in the same way

An Example of a Diagram An activity diagram of the tasks involved in producing a book. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation. Write Chapter Review Chapter Author Printer Typesetter Reviewer Typeset Book Correct Proofs Reset Book Print Book [book complete] [book not complete] Revise Chapter

An activity diagram of the tasks involved in producing a book.

Hiding Detail Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation. Write Chapter Review Chapter Author Printer Typesetter Reviewer Typeset Book Correct Proofs Reset Book Print Book [book complete] [book not complete] Revise Chapter Plan Chapter Produce First Draft Revise Draft [satisfied] [not satisfied] Add Exercises Add References to Bibliography Write Chapter

Diagrams versus Models A diagram illustrates some aspect of a system. A model provides a complete view of a system at a particular stage and from a particular perspective. A model may consist of a single diagram, but most consist of many related diagrams and supporting data and documentation. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 100-1.

A diagram illustrates some aspect of a system.

A model provides a complete view of a system at a particular stage and from a particular perspective.

A model may consist of a single diagram, but most consist of many related diagrams and supporting data and documentation.

Models in Systems Development To understand the user’s world we need: People sensitivity (interviewing and listening skills) for gathering relevant and accurate information. Modeling diagrams to document and communicate what we’ve learned from the users. We are using UML as our modeling notation. Modeling techniques to ensure these notations produce an accurate picture of the user’s business. These are partly defined by: the modeling notation itself, as well as the software process/methodology. Source: David William Brown, An Intro to Object-oriented (Wiley, 2002), p. 38

To understand the user’s world we need:

People sensitivity (interviewing and listening skills) for gathering relevant and accurate information.

Modeling diagrams to document and communicate what we’ve learned from the users.

We are using UML as our modeling notation.

Modeling techniques to ensure these notations produce an accurate picture of the user’s business.

These are partly defined by:

the modeling notation itself, as well as

the software process/methodology.

Developing Models The models that we produce during the development of a system change as the project progresses. They change by degree of: Abstraction Model will become less abstract and more concrete. Formality Degree of formality in which methods, attributes, and constraints are defined will increase as project progress. Level of detail More potential detail in every model as project progresses. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 103-5.

The models that we produce during the development of a system change as the project progresses.

They change by degree of:

Abstraction

Model will become less abstract and more concrete.

Formality

Degree of formality in which methods, attributes, and constraints are defined will increase as project progress.

Level of detail

More potential detail in every model as project progresses.

Iteration 1 Obvious use cases. Simple use case descriptions. Iteration 2 Additional use cases. Simple use case descriptions. Prototypes. Iteration 3 Structured use cases. Structured use case descriptions. Prototypes. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 104. Development of Use Case Model through successive iterations Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 2002 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 2002 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client:

Earlier Models and Diagrams A variety of modeling notations have developed over the years. These include: Process models (data flow diagrams) Data models (ERDs)

A variety of modeling notations have developed over the years. These include:

Process models (data flow diagrams)

Data models (ERDs)

Process Models: Data Flow Diagrams Focus not just on operations but on who does what with whom. That is, the focus is on data and how it processes through an organization. Used Data Flow Diagrams (DFDs) as a way to model the activities, functions, and processes that make up a users’ business.

Focus not just on operations but on who does what with whom. That is, the focus is on data and how it processes through an organization.

Used Data Flow Diagrams (DFDs) as a way to model the activities, functions, and processes that make up a users’ business.

Data Models: ERDs Focus on data modeling rather than on process modeling. Entity Relationship Diagrams (ERDs) used as analysis tool as well as a database design tool.

Focus on data modeling rather than on process modeling.

Entity Relationship Diagrams (ERDs) used as analysis tool as well as a database design tool.

OO Diagramming There are all sorts of different OO diagrams: e.g., Booch OOD, Rumbaugh OMT, Yourdon & Coad, etc. UML ( Unified Modeling Language ) has become the standard notation for OO diagramming and modeling. The modeling notation defined by UML does not define a modeling technique These are defined by the software process/methodology. UML is not a methodology or process; rather it is a universal modeling notation.

There are all sorts of different OO diagrams:

e.g., Booch OOD, Rumbaugh OMT, Yourdon & Coad, etc.

UML ( Unified Modeling Language ) has become the standard notation for OO diagramming and modeling.

The modeling notation defined by UML does not define a modeling technique

These are defined by the software process/methodology.

UML is not a methodology or process; rather it is a universal modeling notation.

UML Defined The Unified Modeling Language (UML) is a general purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

The Unified Modeling Language (UML) is a general purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system.

UML Defined It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about systems. It is intended to be used with all development methods, lifecycle stages, application domains, and media. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

It captures decisions and understanding about systems that must be constructed.

It is used to understand, design, browse, configure, maintain, and control information about systems.

It is intended to be used with all development methods, lifecycle stages, application domains, and media.

Not A Programming Language! The UML is not a programming language ! The UML is a general-purpose modeling notation for discrete systems such as software.

The UML is not a programming language !

The UML is a general-purpose modeling notation for discrete systems such as software.

Goals of UML There were a number of goals behind the development of UML: UML is a general-purpose modeling language that all modelers can use. It is meant to include the concepts of the leading methods so that it can be used as their modeling language. It was intended to be as familiar as possible. It is meant to support good practices for design such as encapsulation, separation of concerns, and capture of the intent of a model construct. It is intended to address current software development issues, such as large scale, distribution, concurrency, patterns and team development. It was to be as simple as possible while still being capable of modeling the full range of practical systems that need to be built. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 8-9

There were a number of goals behind the development of UML:

UML is a general-purpose modeling language that all modelers can use.

It is meant to include the concepts of the leading methods so that it can be used as their modeling language.

It was intended to be as familiar as possible.

It is meant to support good practices for design such as encapsulation, separation of concerns, and capture of the intent of a model construct.

It is intended to address current software development issues, such as large scale, distribution, concurrency, patterns and team development.

It was to be as simple as possible while still being capable of modeling the full range of practical systems that need to be built.

What Does Unified Mean? The word unified has the following relevant meanings for UML: Across historical methods and notations. Across the development lifecycle Across application domains Across implementation languages and platforms Across development processes Across internal concepts Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 7-8

The word unified has the following relevant meanings for UML:

Across historical methods and notations.

Across the development lifecycle

Across application domains

Across implementation languages and platforms

Across development processes

Across internal concepts

UML Building Blocks UML is composed of three building blocks: Things These are the modeling elements Relationships These tie things together Diagrams These are views into UML models Source: Booch, The Unified Modeling Language User Guide (Addison-Wesley, 1998), p. 2.

UML is composed of three building blocks:

Things

These are the modeling elements

Relationships

These tie things together

Diagrams

These are views into UML models

UML Things UML thing may be partitioned into: Structural things Represent the nouns of a UML model such as class, component, use case, etc Behavioral things Represent the verbs of a UML model such as interactions, states, etc. Grouping things Represent things that group elements together such as the package. Annotational things The note Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 9.

UML thing may be partitioned into:

Structural things

Represent the nouns of a UML model such as class, component, use case, etc

Behavioral things

Represent the verbs of a UML model such as interactions, states, etc.

Grouping things

Represent things that group elements together such as the package.

Annotational things

The note

UML Relationships Used to show how two or more things relate to each other. generalization association dependency realization Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 10.

Used to show how two or more things relate to each other.

Diagrams in UML UML diagrams consist of: icons two-dimensional symbols paths Strings UML diagrams are views into the model. They are not the model itself Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation. Plan Chapter Produce First Draft Revise Draft [satisfied] [not satisfied] Add Exercises Add References to Bibliography Write Chapter

UML diagrams consist of:

icons

two-dimensional symbols

paths

Strings

UML diagrams are views into the model.

They are not the model itself

UML Diagrams Static Model Dynamic Model class diagram component diagram deployment diagram object diagram use case diagram sequence diagram collaboration diagram statechart diagram activity diagram Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 11.

UML Parts A system is modeled as a collection of discrete objects that interact to perform work that ultimately benefits an outside user. UML has: static and, dynamic parts. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

A system is modeled as a collection of discrete objects that interact to perform work that ultimately benefits an outside user.

UML has:

static and,

dynamic parts.

Static and Dynamic Information In particular UML captures information about the static structure and the dynamic behavior of a system. The static structure defines the kinds of objects important to a system and to its implementation, as well as the relationships among the objects. The dynamic behavior defines the history of objects over time and the communications among objects to accomplish goals. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

In particular UML captures information about the static structure and the dynamic behavior of a system.

The static structure defines the kinds of objects important to a system and to its implementation, as well as the relationships among the objects.

The dynamic behavior defines the history of objects over time and the communications among objects to accomplish goals.

Organization The UML also contains organization constructs for arranging models into packages that permit software teams to: partition large systems into workable pieces. understand and control dependencies among the packages, and manage the versioning of model units in a complex development environment. The UML contains constructs for representing implementation decisions and for organizing run-time elements into components. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3-4

The UML also contains organization constructs for arranging models into packages that permit software teams to:

partition large systems into workable pieces.

understand and control dependencies among the packages, and

manage the versioning of model units in a complex development environment.

The UML contains constructs for representing implementation decisions and for organizing run-time elements into components.

UML Concepts system The overall thing that is being modeled. sub-system Part of the system. model An abstraction of system or subsystem from a particular perspective or view. Different models present different views of the system. diagram A graphic representation of a set of elements in the model. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 102.

system

The overall thing that is being modeled.

sub-system

Part of the system.

model

An abstraction of system or subsystem from a particular perspective or view.

Different models present different views of the system.

diagram

A graphic representation of a set of elements in the model.

Static Structure Any precise model must first define the universe of discourse. That is, the key concepts from the application, their internal properties, and their relationships to each other. This set of constructs is the static view of the system. The static view is notated by class diagrams (also called class static structure diagrams ) . That is, the application concepts are modeled as classes, each of which describes a set of discrete objects that hold information and communicate to implement behavior. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 9

Any precise model must first define the universe of discourse.

That is, the key concepts from the application, their internal properties, and their relationships to each other.

This set of constructs is the static view of the system.

The static view is notated by class diagrams (also called class static structure diagrams ) .

That is, the application concepts are modeled as classes, each of which describes a set of discrete objects that hold information and communicate to implement behavior.

Class static structure diagrams

Dynamic Behavior There are two ways to model behavior: One is the communication patterns of a set of connected objects as they interact to implement behavior . This is modeled using use case diagrams , sequence diagrams , collaboration diagrams , and activity diagrams . The other is the evolution of an object ’s state over time as it interacts with the rest of the world. State change refers to possible changes in object’s attributes and associations with other objects. This is modeled as a statechart . Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 9-10

There are two ways to model behavior:

One is the communication patterns of a set of connected objects as they interact to implement behavior .

This is modeled using use case diagrams , sequence diagrams , collaboration diagrams , and activity diagrams .

The other is the evolution of an object ’s state over time as it interacts with the rest of the world.

State change refers to possible changes in object’s attributes and associations with other objects.

This is modeled as a statechart .

Use Cases When we analyze a system we try to identify the main functionality that the system will have and the main ways it will be used. Each of these ways the system is going to be used is called a use case . A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. An actor is either a person (user) interacting with the system or, in some cases, another system interacting with the system. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 53

When we analyze a system we try to identify the main functionality that the system will have and the main ways it will be used.

Each of these ways the system is going to be used is called a use case .

A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

An actor is either a person (user) interacting with the system or, in some cases, another system interacting with the system.

Using Use Cases A use case captures the main functionality of the system from a user or actor’s perspective. It also serves as a vehicle to divide the system into parts that can be implemented somewhat separately. For any given system, we will usually develop and implement the most important use cases first. Establishing which use cases are important often follows from looking at the main events in the problem domain. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 54

A use case captures the main functionality of the system from a user or actor’s perspective.

It also serves as a vehicle to divide the system into parts that can be implemented somewhat separately.

For any given system, we will usually develop and implement the most important use cases first.

Establishing which use cases are important often follows from looking at the main events in the problem domain.

Use Case Diagram We can model use cases in a use case diagram. Stick figures represent actors. Ovals represent the use case. The arrows show interactions.

We can model use cases in a use case diagram.

Stick figures represent actors.

Ovals represent the use case.

The arrows show interactions.

Activity Diagrams Used to model business activities/tasks in the very early stages of a project. Also used to describe a system function described by a use case. They are analogous to standard flowcharts.

Used to model business activities/tasks in the very early stages of a project.

Also used to describe a system function described by a use case.

They are analogous to standard flowcharts.

Activity Diagrams [campaign to add] [new campaign] Add a New Client Assign Staff Contact Add New Campaign activities transitions decisions :Campaign object flow object

Activity Diagrams Swimlanes vertical columns labelled with the person, organisation or department responsible for the activities in that column Record Completion of a campaign Issue invoice Campaign Manager Client Accountant Pay invoice Record client payment

Swimlanes

vertical columns

labelled with the person, organisation or department responsible for the activities in that column

Sequence Diagrams The class diagram is limited in that it does not represent time-dependent behaviors. Sequence diagrams present object interactions arranged in time sequence. It shows the actors or objects participating in an interaction and the events they generate arranged in a time sequence. Often, a sequence diagram shows the events that result from a particular instance of a use case but a sequence diagram can also exist in a more generic form. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 62

The class diagram is limited in that it does not represent time-dependent behaviors.

Sequence diagrams present object interactions arranged in time sequence.

It shows the actors or objects participating in an interaction and the events they generate arranged in a time sequence.

Often, a sequence diagram shows the events that result from a particular instance of a use case but a sequence diagram can also exist in a more generic form.

Sequence Diagrams Rectangles represent objects. Stick figures represent actors. Vertical lines represent the lifeline of the object or actor. Horizontal arrows indicate messages.

Rectangles represent objects.

Stick figures represent actors.

Vertical lines represent the lifeline of the object or actor.

Horizontal arrows indicate messages.

Collaboration Diagram A collaboration diagram shows interactions organized around the objects and their messages to each other. Collaboration diagrams and sequence diagrams are used interchangeably. Unlike a sequence diagram, a collaboration diagram shows relationships among object roles and it does not express time as a separate dimension.

A collaboration diagram shows interactions organized around the objects and their messages to each other.

Collaboration diagrams and sequence diagrams are used interchangeably.

Unlike a sequence diagram, a collaboration diagram shows relationships among object roles and it does not express time as a separate dimension.

Statechart Diagram The statechart diagram shows the states an object might be in and the actions or conditions that cause an object to make a transition from one state to another. By documenting events and transitions, a statechart diagram shows the sequence of states an object goes through during its life. Statecharts are extensions of the class diagram and you could create one statechart for each class. In practice, you will only create a statechart for those classes that exhibit especially interesting or complex time-dependent behavior. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 60

The statechart diagram shows the states an object might be in and the actions or conditions that cause an object to make a transition from one state to another.

By documenting events and transitions, a statechart diagram shows the sequence of states an object goes through during its life.

Statecharts are extensions of the class diagram and you could create one statechart for each class.

In practice, you will only create a statechart for those classes that exhibit especially interesting or complex time-dependent behavior.

Statechart Diagram Boxes represent states. Arrows represent transitions between states. Solid dots represent start and end states.

Boxes represent states.

Arrows represent transitions between states.

Solid dots represent start and end states.

Model Organization Computers can deal with large flat models, but humans cannot. In a large system, modeling information must be divided into coherent pieces so that teams can work on different parts concurrently. Packages are general-purpose hierarchical organizational units of UML models. Packages can be used for storage, access control, configuration management, and constructing libraries that contain reusable model fragments. Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 10

Computers can deal with large flat models, but humans cannot.

In a large system, modeling information must be divided into coherent pieces so that teams can work on different parts concurrently.

Packages are general-purpose hierarchical organizational units of UML models.

Packages can be used for storage, access control, configuration management, and constructing libraries that contain reusable model fragments.

Packages If the class diagram becomes large, it will become quite difficult to use for an overview of the system. In such cases we create a high-level view of the system, using some kind of partitioning or cluster scheme. UML calls these clusters packages and provides modeling notation called a package diagram .

If the class diagram becomes large, it will become quite difficult to use for an overview of the system.

In such cases we create a high-level view of the system, using some kind of partitioning or cluster scheme.

UML calls these clusters packages and provides modeling notation called a package diagram .