This preview shows page 1. Sign up to view the full content.
Unformatted text preview: The Business Modeling The Discipline Discipline 1 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. 2 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… 3 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. 4 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. 5 Why Undertake Business Modeling more…
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. 6 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? … – Part of the software engineering process and part of the inception phase Emphasis is on ‘the organization.’ 7 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. 8 Business Modeling Scenarios Scenario 3 – One Business; Many systems. One businessmodeling 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! 9 Business Modeling Scenarios Scenario 4 – Generic Business Model Scenario 5 – Revamp – Business Process Reengineering (BPR) – Important if you are building a single, general model 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. – A complete redo of the way of doing business. Done in several discrete stages – envision new business, reverse engineer existing business, forwardengineer new business, and install new business… – A revolutionary approach to reorganization…. 10 Roles and Artifacts Primary Roles Business Process Analyst – Leads / coordinates the business use case modeling by outlining and delimiting the organization being modeled. Business Designer Produces vision document, business goals, identifies business use case model and the business actors and how they interact. Others: – 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. – Stakeholders – represent parts of the organization that are/will be impacted by the software – Business Reviewer – reviews resulting artifacts 11 Roles and Artifacts Primary Artifacts Business Vision Document Business Use Case Model – Defines objectives and goals of the business modeling effort – 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… 12 Others Roles and Artifacts Primary Artifacts (2) – TargetOrganization 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. 13 Business Models 1. Business Use Case Model: 2. Business Object Model – Contains business actors (roles external to the business) and business use cases (business processes) – 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. 14 1. Business Use Case Model Simple in structure . See pp 151152 – Shows relationship between business use cases – in general – Very similar to Use Case Model – Each use case is identified and actors who interact with this and each business use case. Different icons 15 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 1512) and the Business Use Case Models (middle of pp. 151152). 16 More details on Business Object More Model 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 Business Models and Entity Classes will see these again as System actors. – 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; … 17 Domain Modeling
The term “problem domain” refers to the area that encompasses realworld 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) 18 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 outsidein 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. 19 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: highlevel 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. 20 Domain Modeling (cont.) Look through these descriptions for nouns – these are candidate classes in the domain model. – E.g. Menu, customer, food order, Payment, online 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. 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. 21 Customer and Food are entities related by Orders…. Domain Modeling (cont.) 1. Read/study/analyze the problem domain description 2. identify nouns, etc. as candidate classes 3. Use Rose (Business Modeling) for modeling domain classes w/class notation. See Business Modeling under Use CaseView remove synonyms, …Consider noun phrases too. 4. Build associations between the domain classes Try to identify attributes and operations for your domain classes
Identify (name) these association 5. Add multiplicities carefully 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 Don’t worry about aggregations and association classes and much more for our exercise. 22 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, endusers, 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.
View Full Document
This note was uploaded on 07/26/2011 for the course CEN 6016 taught by Professor Sanchez,a during the Spring '08 term at UNF.
- Spring '08