The Business Modeling Discipline

1. The Business Modeling Discipline

2. Purpose of Business Modeling • To understand the structure and dynamics of the organization in which a system is to be deployed • To understand current problems in the target organization and identify areas for potential improvement • To ensure customers, end users, and developers have a common understanding of the target organization • To derive the system requirements to support the target organization.

3. Business Modeling • We will create a model of the ‘vision’ of the target organization –with its • Processes • Roles • Responsibilities • Two primary components: • Business Use Case Model, and • Business Object Model • We will discuss each in turn several slides ahead…

4. Why Undertake Business Modeling • The new standard for software development is to try to understand the business domain before or in parallel with development of an application. • Business modeling is a central part of most projects and facilitates the development of Requirements. • According to the RUP, it is the first discipline that should be addressed and is key to acquiring key artifacts that will underpin much future work. • It is also a fundamental discipline in Inception phase.

5. Why Undertake Business Modeling • May not be appropriate for all development efforts. • Business models add more value when there are more people directly involved in using the system and more information to be handled by the system. • Very helpful to understand the environment in which the application will function and how this application will impact the business it is to support or already supports.

6. Why Undertake Business Modelingmore… • Will be using the same technique to model the software system we will build as the business we are now attempting to model. • Some items in the business domain model will relate directly to the software domain. • Business modeling also simplifies relationships between business model artifacts and similar relationships in the system model.

7. Business Modeling Scenarios • Several (five according to author) • Scenario 1 – Organization Chart • Build a simple org chart of business and its processes to get a good understanding of the application you are building. • Where does the application fit? To which organizations might it impact? … • Emphasis is on ‘the organization.’ • Part of the software engineering process and part of the inception phase

8. Business Modeling Scenarios • Scenario 2 – Domain Modeling • Build a model of that information (banking, order management) that will be present at the business level. • Don’t worry about workflows at this time. • Domain Modeling is typically part of the software engineering project and is performed during inception and elaboration phases – but is definitely started in inception and refined in elaboration. • We will develop a domain model – among other things.

9. Business Modeling Scenarios • Scenario 3 – One Business; Many systems. One business-modeling effort that we be input to several other development projects. • The business models will as serve as inputs to building the architecture of the application family. Individual applications may then use this model for individual projects, and will use this system as a baseline or domain, which may be then tailored or used in a dependency role. (different architectural layer) • This business modeling effort is a project by itself!

10. Business Modeling Scenarios • Scenario 4 – Generic Business Model • Important if you are building a single, generalmodel to be used to align organizations in the business that will use it and reduce overall complexity - or at least understand how the different organizations might use the application. • Scenario 5 – Revamp – Business Process Reengineering (BPR) • A complete redo of the way of doing business. Done in several discrete stages – envision new business, reverse engineer existing business, forward-engineer new business, and install new business… • A revolutionary approach to reorganization….

11. Roles and ArtifactsPrimary Roles • Business Process Analyst • Leads / coordinates the business use case modeling by outlining and delimiting the organization being modeled. • Produces vision document, business goals, identifies business use case model and the business actors and how they interact. • Business Designer • Details the business use cases, determines the business workers and entities necessary for each business use case and how they function to realize the business use case. • Defines responsibilities, operations, attributes, and relationships among business workers and business entities. • Others: • Stakeholders – represent parts of the organization that are/will be impacted by the software • Business Reviewer – reviews resulting artifacts

12. Roles and ArtifactsPrimary Artifacts • Business Vision Document • Defines objectives and goals of the business modeling effort • Business Use Case Model • A model of the business’s intended functions. • Used as an essential input to identify roles and deliverables in the organization. (Use Rational Rose) • Business Object Model (Business Analysis Model) • A model that realizes the business use cases. (Use Rational Rose) • A lot of work…

13. Roles and ArtifactsPrimary Artifacts (2) • Others • Target-Organization Assessment – describes the current status of the organization in which a system is to be deployed • Business Rules – policies/conditions that must be satisfied • Supplementary Business Spec – presents definitions of the business not in the business use case model or business object model • Business Glossary – definitions of important terms • Business Architecture Document – comprehensive overview of the architecturally significant aspects of the business from a number of perspectives. • Only used when decisions regarding changes to the business need to be made or when the business needs to be described to other parties.

14. Business Models • 1. Business Use Case Model: • Contains business actors (roles external to the business) and business use cases (business processes) • 2. Business Object Model • Includes the business use case realizations • Includes interacting roles and entities involved. • These are at higher levels of abstraction than the system use cases will be. • e.g. A class at business level represents a responsibility in an organization.

15. 1. Business Use Case Model • Simple in structure . See pp 151-152 • Shows relationship between business use cases – in general • Very similar to Use Case Model • Different icons • Each use case is identified and actors who interact with this and each business use case.

16. 2. Business Object Model • Much more detailed • Each business use case is realized with business actors and business entities. • Note icons used. (All documented in Visual Modeling with RR 2002 and UML) • You will not need the dashed lines, as these figures (pp. 151 and 152) are showing the relationship between the business modeling and the system models. (underlines  objects) • Notice the difference between the icons in the System Use Case Model (bottom of pp 151-2) and the Business Use Case Models (middle of pp. 151-152).

17. More details on Business Object Model • Automated Business Worker • This applies to us. The Business Worker will become the Business Actor. • The Business Actor will communicate directly with the system in several cases. • E.g. Customer, Owner, Receptionist, Head Waitress, …We will see these again as System actors. • Business Models and Entity Classes • A business entity that is to be managed by an information system will correspond to an entity in the analysis model. • E.g. Menu; Work Schedule; FoodOrder; …

18. Domain Modeling • The term “problem domain” refers to the area that encompasses real-world persons, places, and/or things and concepts related to the problem that the system is being designed to solve. • Domain Modeling is the task of discovering “objects” (classes, actually) that represent those entities and concepts. • (Taken from Use Case Driven Object Modeling with UML – A Practical Approach, by Rosenberg)

19. Domain Modeling (cont.) • Domain Modeling is kind of an inside out approach – working from the data requirements out to build a static model of the problem domain • This contrasts with the outside-in approach we normally take toward user requirements. • Domain modeling and Use Case development merge later. In fact, the dynamic model (system in motion – actors, use case realizations, etc.) drives the static model (the structure of the system.) • The domain model can serve as a glossary of terms, which is very useful to use case developers • Some approaches specify creation of a domain model OR a Glossary.

20. Domain Modeling (cont.) • The domain model is developed from classes – groups of objects with similar properties, common behaviors, common relationships, and common semantics. • Develop a static model of the system by finding appropriate classes that represent the real abstractions in the problem domain. • This serves to underpin system development later. • Sources of Domain (Class) Knowledge: high-level problem statements; requirements; expert knowledge of the problem space; anything that describes the problem space and the desires and needs of the stakeholders. • These must be very carefully parsed and analyzed.

21. Domain Modeling (cont.) • Look through these descriptions for nouns – these are candidate classes in the domain model. • E.g. Menu, customer, food order, Payment, on-line order… • E.g. A domain model looks ‘somewhat’ like an ERD, - but no primary / foreign keys, …) But we DO have relationships and multiplicities between/among these entities, such as: • E.g. Customer (class with attributes /behaviors) ‘orders’ (relationship) Food (class with attributes) – captured graphically. • Customer and Food are entities related by Orders…. • Read the requirements over very closely to capture these ‘nouns.’ Verbs and verb phrases become candidate operations (methods later) or associations. Possessive phrases indicate that the nouns should be attributes rather than objects.

22. Domain Modeling (cont.) • 1. Read/study/analyze the problem domain description • 2. identify nouns, etc. as candidate classes • remove synonyms, …Consider noun phrases too. • 3. Use Rose (Business Modeling) for modeling domain classes w/class notation. See Business Modeling under Use CaseView • Try to identify attributes and operations for your domain classes • 4. Build associations between the domain classes • Identify (name) these association • 5. Add multiplicities carefully • Don’t worry about aggregations and association classes and much more for our exercise. • 6. Model will undergo a refinement later. But try to capture all the domain information you can; model it; and verify it. All is done in Rose

23. Deliverable #1 - Introduction to Business Modeling Due: 2/16 at start of class. Turn in CD that contains all models and has links to text descriptions. Ensure text models are on CD and clearly linked from Rose. See Restaurant Management System requirements version 1 and Versions 1.1 on my web page tomorrow, Wednesday, 2/4/2004 Purpose: To understand the structure and dynamics of the organization; To ensure customers, end-users, and developers understand the organization; To derive requirements on systems to support the organization; To support these, Business Use Case Models and Business Object Models are developed. Deliverable Artifacts: Business use case model Use Cases and Actors - Modeled Business object model Use Cases realized with actors and entities for the modeling Use Cases realized with actors for the Use Case Descriptions. Two additional artifacts are required: Business Vision document - text Business Glossary - text Business Rules - text Domain Model - model in Rational Rose You can use Visio to do this. Visio does provide all the tools and is simple. BUT, you would be much better served to use Rational Rose. So use Rational Rose.