Section 1. Why Model?
There's more to a BA's job than just gathering requirements. This section presents the purpose of the course and introduces the idea that succinct graphical models with defined semantics can be a powerful and efficient way to represent requirements and design solutions—much more powerful, much more efficient, and certainly more precise than words alone.
Section 2. Method Overview
This section provides a roadmap of the five basic models – Process Model, Information Model, State Model, Collaboration Model, Authorization Model, three derived supplementary models (Context Diagram, Sequence Diagrams, and Views), and the relationships between them. Each model represents certain specific concepts, and the concepts in one model are related to concepts in other models. The roadmap introduced in this section will be followed throughout the course to present each of the models and the relationships between them.
Section 3. Use Cases and Scenarios
One way to approach a system is to model the functional behavior of that system. Use cases provide a way to organize and to present system behavior from the perspective of the various participants and stakeholders. This section reviews the key components of a use case, how to create scenarios for different alternative flows, and how to define the pre-and post-conditions of a use case and each of the steps in that use case. Business, system, and implementation behavior are defined in terms of different use case "levels." Far from being an arbitrary organization, each of the different levels represents specific purposes. This section addresses how different use case "levels" represent specific kinds of analysis.
Section 4. Process Modeling Basics
Process models (sometimes called business process models) graphically represent key components of use cases and allow them to be organized into distinct scenarios. Done properly, process modeling identifies key business entities, the different stages in their lifecycles, and the activities that progress these entities through their lifecycles. Because they are graphical models with defined semantics, process models can be more precise than text alone, thereby enabling modelers to create more accurate and more complete use cases.
Section 5. Process Descriptions & Activity Tabulation
While graphical models provide the structure for the concepts in a domain, each of the elements in the models require additional information beyond what appears on the diagrams. In this chapter, participants learn how to describe process models and each of the elements in the models. A large domain often involves a number of different business processes, each with their own process models. Often the same activities appear on several different models. While these different process models provide different contexts, the activities are the same activities regardless of where they appear. This section presents some techniques for organizing and classifying activities by who performs the activity and the contexts under which the activity occurs.
Section 6. Decisions and Alternatives
Simple process models present a straightforward flow of control from beginning to end. Real business processes, however, often involve several points in which decisions are made and alternatives can be taken. This section presents the method for describing alternative flows in a process model and how different scenarios of the same use case may be illustrated using several different diagrams or one single diagram.
Section 7. Concurrency
Real business processes often involve several things happening at once. Process models can and should describe real-world concurrency and exploit opportunities for parallel behavior. This section presents the notations used for describing concurrent activities; how a single activity or condition may start parallel flows, and how to ensure that several parallel activities have all completed.
Section 8. Time
In business processes, some activities may be initiated by the actions of people, organizations or systems. Others, however, are initiated "by the clock," either at specific times (such as a monthly payroll) or after a certain duration. This section shows how to include time-related events and to coordinate activities based on time.
Section 9. Introducing Information Models
Another way to approach a system is to model the business entities, their properties, and the relationships between these entities. An information model, represented as a UML class diagram, provides a unified view of a domain where each term and concept is precisely defined. This section presents how to construct a platform-independent information model that not only grounds the entire set of domain models, but is also a useful basis for the creation of relational and hierarchical data models, object-oriented class structures, user interface designs, and messaging schemas.
Section 10. Relationships: Association & Composition
Just as the things in the real world are related to each other, the classes in an Information Model are connected by several different kinds of relationships. This section explores two of the most basic kinds of relationships: composition, in which one thing is a part of another, and association, in which two things share some other kind of meaningful connection.
Section 11. Attribute Rules
Attributes represent the individual characteristics of a business object. In creating an information model, the analyst should create a set of attributes that are complete, independent, and distinct facts. Finding a good set of attributes is similar to the data modeling concept of "normalization," but is focused upon describing the business problem. Often real-world objects include "derived" characteristics that are based upon other characteristics. This section presents some rules for how to find a good set of attributes, how to find "derived attributes," and how to test attributes for correctness and completeness.
Section 12. Attribute Types
Every attribute has a set of legal values known as the attribute's type. Describing attributes' types can be one of the most valuable detailed analysis activities, as this information is required to correctly create many different implementation artifacts, from database and message schemas to user interface controls. This section presents a scheme for describing various kinds of attribute types: numeric values, symbolic values, and structured values among others.
Section 13. Specialization
In an information model, a class represents a set of things that share common characteristics and common behavior. Real-world problems often involve situations in which some things are common and some things are different. This section presents techniques for dealing with these problems: role specialization, in which one group of objects shares common properties with a larger group, and subclassing, in which a group can be divided into different subsets, each with different properties.
Section 14. Information Descriptions
Just as the elements of a process model require descriptions, classes, attributes, and associations must also be described in detail in order for the readers of a model to clearly understand the concepts presented in the model. The process of writing good descriptions also helps to expose issues in the models and to clarify thinking among the analysts and other stakeholders in the analysis process.
Section 15. Finding Classes
The process of building an Information Model—whether it happens before, during or after use case analysis—involves identifying, classifying, and organizing the conceptual entities in a domain. This section describes different kinds of classes and how to find examples of each kind in a domain, and presents the "object blitz"—a simple yet powerful brainstorming technique for finding classes and starting to build an information model.
Section 16. Views
While an Information Model organizes the facts in a domain into a series of normalized classes and relationships, real presentation forms (such as messages, user interface screens and reports) often involve information that spans several related classes. This section introduces a technique for describing such distinct views in a way that relates the contents of each view to the Information Model, thereby ensuring great consistency among all views and the core Information Model.
Section 17. Authorization Models
Process Models describe what happens in a business process and information models describe the facts in a problem. Although the process models say which actors perform which activities, they do not necessarily enumerate all system activities, nor do they describe important constraints on the performance of those activities. Authorization Models augment the standard use case diagrams with permission constraints that specify exactly the conditions under which different actors can perform different activities.
Section 18. Lifecycle Basics
Every object defined on the Information Model has a lifecycle: a series of stages through which the object progresses over time. Some lifecycles are trivial—"created" and "deleted," for instance, but others are significantly more sophisticated. State models are used to represent these more interesting lifecycles. This section presents the concept of a lifecycle and shows how to construct state models that represent an object's states and the events that cause progression from one state to another. It also powerfully shows the interconnections between the elements in the various analysis models.
Section 19. Coordinated State Models
Complex system behavior can be modeled simply as coordinated state models. This section shows how to create a collaboration model to summarize existing state models as well as how to use the collaboration model to plan system dynamics prior to building state models. Such models and techniques allow analysts to simplify and organize complex system behavior.
Section 20. Finding More Activities
Not all of the activities in a domain are necessarily found by building process models. There are many activities that involve simple creating, updating, and deleting of various business entities, and not all of these activities appear on process models. This section shows how to read an information model to discover these additional activities, how to represent them on authorization models, and how these activities may be clues to additional process models.
Section 21. Model Verification by Simulation
The models presented in this course are formal and precise enough that they can be tested. In this section, analysts learn how to create test cases based upon the process models, to run these tests against the other models, and to use these test cases to create the actual system test cases.
Section 22. User Interfaces and Other Domains
Partitioning by subject matter yields platform-independent application models. For most business analysts, that means separating the "how" of the user interface design from the "what" of the application domain. So where do you put the UI steps that are typically presented as lower-level use cases? In this section, you'll learn how the same modeling techniques used for the application domain can be used to model a basic design for a consistent and robust user interface, and that by bridging the application to the user interface you can create the actual screen layout and flow in a manner that remains consistent with the application models.
Section 23. The Process of Analysis
Any modeling activity exists within the context of a larger process. While this course is emphatically not intended to prescribe a particular process, there are certain factors that are important to modeling and analysis success. This section describes several factors important to the success of a modeling effort. Participants are encouraged to discuss what they have learned so far and which activities are most important for them to achieve success.
Section 24. Designing & Implementing from Models
Models are great, but how do models become systems? How do enterprises use models to manage consistency across multiple projects? This section presents approaches to software and system architectures that take advantage of the many distinct architectural views, shows how those views can also be modeled, and how those architectural models can be used to translate the analysts' business models into working systems.