...
 
Commits (2)
......@@ -71,7 +71,7 @@ image::domain-analysis-picture.png[width=65%,align="center"]
Domain analysis is the process by which a software engineer learns background information. He or she has to learn sufficient information so as to be able to understand the problem and make good decisions during requirements analysis and other stages of the software engineering process. The word ‘domain’ in this case means the general field of business or technology in which the customers expect to be using the software.
Some domains might be very broad, such as ‘airline reservations’, ‘medical diagnosis’, and ‘financial analysis’. Others are narrower, such as ‘the manufacturing of paint’ or ‘scheduling meetings’. People who work in a domain and who have a deep knowledge of it (or part of it), are called domain experts. Many of these people may become customers or users.
To perform domain analysis, you gather information from whatever sources of information are available: these include the domain experts; any books about the domain; any existing software and its documentation, and any other documents he or she can find. The interviewing, brainstorming and use case analysis techniques discussed later in this chapter can help with domain analysis.
To perform domain analysis, you gather information from whatever sources of information are available: these include the domain experts; any books about the domain; any existing software and its documentation, and any other documents he or she can find. The interviewing, brainstorming and use case analysis techniques discussed later in this chapter can help with domain analysis.
As a software engineer, you are not expected to become an expert in the domain; nevertheless, domain analysis can involve considerable work. The following benefits will make this work worthwhile:
* *Faster development*: You will be able to communicate with the stakeholders more effectively, hence you will be able to establish requirements more rapidly. Having performed domain analysis will help you to focus on the most important issues.
......@@ -121,8 +121,8 @@ As a software engineer, you are not expected to become an expert in the domain;
[.notes]
--
* Illustrates meaningful conceptual classes in a problem domain.
* Is a representation of real-world concepts, not software components.
* Illustrates meaningful conceptual classes in a problem domain.
* Is a representation of real-world concepts, not software components.
* Is NOT a set of diagrams describing software classes, or software objects and their responsibilities.
--
......@@ -156,7 +156,7 @@ image::domain-objects.png[width=400px]
== Objects and Actions
* Objects and Actions are at the same level.
* Creating a sound domain model requires careful thought on actions and what they achieve.
* Creating a sound domain model requires careful thought on actions and what they achieve.
[.notes]
--
......@@ -207,7 +207,7 @@ image::actions.png[]
----
UC::teach(student, teacher, skill)
post:
— this skill has been added to the student’s accomplishments
— this skill has been added to the student’s accomplishments
----
== Snapshots describe Actions
......@@ -216,7 +216,7 @@ post:
--
[.col-5]
* Object diagrams may represent the effects of an action.
* Here, the effects of:
* Here, the effects of:
``teach(aurelie, paul, database)``
[.col-5]
......@@ -232,9 +232,9 @@ image::snapshots.png[width=800px]
[source,ocl]
----
UC::teach(student, teacher, skill)
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
student.accomplishments@pre->including(skill).
----
......@@ -253,9 +253,9 @@ image::student-skills.png[height=400px]
[source,ocl]
----
UC::teach(student, teacher, skill)
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
student.accomplishments@pre->including(skill).
----
......@@ -276,7 +276,7 @@ Use of stick figure is optional … stick is indicative that Student may be one
== Associations
* Associations represent real world relationships, not necessarily logical ones.
* Associations just exist.
* Associations just exist.
* The use of associations provides:
** A vocabulary for the actions (the static model).
** The need objects for a given action (the dynamic model).
......@@ -306,17 +306,15 @@ image::seminar-domain-model.png[align=center,width=800px]
== Static Invariant Example
[verse]
--
The analyst has decided that vacation and course run are both kinds of instructor outage (instructor not available)
--
The analyst has decided that vacation and course run are
both kinds of instructor outage (instructor not available)
[source, ocl]
----
inv -- for every CourseRun, its instructor’s qualifications must include the course
context CourseRun
inv -- for every course, its instructor’s qualifications must include the course
inv: instructor.qualifications->includes(course)
inv: instructor.qualifications->includes(Course)
----
[.impact]
......@@ -354,11 +352,11 @@ image::analysis-process.png[width=400px,align=right]
[.notes]
--
* Existing procedures, standards documents, software, and user-manuals: where these do exist, they should be consulted. But keep in mind that procedures as written often do not reflect the actual operations. User-manuals for existing systems are a rich source of information. They act as a key input to * reverse-engineering an abstract model of a system; and therefore, of a business.
* Observation and interviews: actual observation of procedures at work, combined with interviews with the persons involved in these procedures. Techniques such as CRC cards can be very effective at eliciting information on as-is processes.
* Existing relational or E-R models: these provide a quick start on the terminology and some of the candidate object types in the business. However, due to the mores or normalization and the exclusive focus on stored data, these models can often be considerably simplified to build a type model. Where used, triggers and stored procedures often encode many business rules.
* Existing batch-mode systems: often those late-night Cobol batch jobs encode critical sets of business rules. Many of these rules can be captured as time-dependent static invariants on the type model (the batch-job cuts in to make sure no objects will be in violation of these invariants, come sunrise) or as effect invariants, of the form “any time this thing has changed, that other thing must be triggered”.
* Feedback from prototypes, scenarios, models: as always, any “live” media pro- vides very valuable feedback and validation of models being built. For example, storyboards, prototypes of UI screens, CRC-card based scenarios, and model walkthroughs, can all be used.
* Existing procedures, standards documents, software, and user-manuals: where these do exist, they should be consulted. But keep in mind that procedures as written often do not reflect the actual operations. User-manuals for existing systems are a rich source of information. They act as a key input to * reverse-engineering an abstract model of a system; and therefore, of a business.
* Observation and interviews: actual observation of procedures at work, combined with interviews with the persons involved in these procedures. Techniques such as CRC cards can be very effective at eliciting information on as-is processes.
* Existing relational or E-R models: these provide a quick start on the terminology and some of the candidate object types in the business. However, due to the mores or normalization and the exclusive focus on stored data, these models can often be considerably simplified to build a type model. Where used, triggers and stored procedures often encode many business rules.
* Existing batch-mode systems: often those late-night Cobol batch jobs encode critical sets of business rules. Many of these rules can be captured as time-dependent static invariants on the type model (the batch-job cuts in to make sure no objects will be in violation of these invariants, come sunrise) or as effect invariants, of the form “any time this thing has changed, that other thing must be triggered”.
* Feedback from prototypes, scenarios, models: as always, any “live” media pro- vides very valuable feedback and validation of models being built. For example, storyboards, prototypes of UI screens, CRC-card based scenarios, and model walkthroughs, can all be used.
--
== Common Candidates
......@@ -375,7 +373,7 @@ image::analysis-process.png[width=400px,align=right]
* For each conceptual class identified previously, ask the following questions:
. What do you do?
. Whom do you deal with?
* Every time a new verb appears, a new action type is identified.
* Every time a new verb appears, a new action type is identified.
== Relating Action Types and Classes
......@@ -411,7 +409,7 @@ image::analysis-process.png[width=400px,align=right]
[.notes]
--
After establishing classes based on the concepts of use case scenarios, we examine the actions to discover new attributes
After establishing classes based on the concepts of use case scenarios, we examine the actions to discover new attributes
--
== Identify Datatypes
......