Data Modeling
In Information System Analysis
Yongjun
Li
12247213
Information System Analysis 6840
Data modeling is the basis for understanding customer requirement and designing information system. Following are key concepts of data modeling in object-oriented analysis and traditional analysis. What’s the different of data modeling between object-oriented analysis and traditional analysis? Is it same for agile and traditional software development in analysis stages when analysts use data model? I will discuss these questions in this paper.
In computer science, data modeling is the process of structuring and organizing data. These data structures are then typically implemented in a database management system. In addition to defining and organizing the data, data modeling may also impose constraints or limitations on the data placed within the structure.[3]
For different analysis method there are different definition and different data model type.
There are three types of Data modeling in object-oriented analysis and design.
- Conceptual data models. These models, sometimes called domain models, are typically used to explore domain concepts with project stakeholders. Conceptual data models are often created as the precursor to LDMs or as alternatives to LDMs. [1]
- Logical data models (LDMs). LDMs are used to explore the domain concepts, and their relationships, of your problem domain. This could be done for the scope of a single project or for your entire enterprise. LDMs depict the logical entity types, typically referred to simply as entity types, the data attributes describing those entities, and the relationships between the entities. [1]
- Physical data models (PDMs). PDMs are used to design the internal schema of a database, depicting the data tables, the data columns of those tables, and the relationships between the tables. The focus of this article is on physical modeling. [1]
The quintessential object-oriented step in analysis or investigation is the decomposition of a domain of interest into individual conceptual classes or objects—the things we are aware of. A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest [3.4]
For structured analysis, data modeling is the basis for understanding the information domain of the problem. Data modeling seeks to identify the major data objects that are processed by the system. Data modeling considers data independent of processing. Data modeling establishes the composition of each data object, the relationship between data objects, and the attributes that describe data objects. [26]
|
Data Objects |
A data object is a representation of composite information used by the system. Things from the problem domain that is important for the users of the system. Typically these are the things that are kept as data. We can also consider as entities classes of objects. Note we are making a distinction here between the description of a class of items and a particular item. Consider the distinction between the class of items defined by the concept PERSON and a particular instance of that class, perhaps FRED. The entity defines, generally, the qualities that make an item a member of that class. |
|
Attributes |
Attributes define properties of a data object. They can name an instance, describe the instance, or make reference to another item. Attributes are those values that combine to help us "define" an entity. We do want to take some care to define entities and attributes in a way that assists us in establishing entities descriptive characteristics so we can differentiate one entity from another. |
|
Relationships |
Data objects relate to each other in a variety of, sometimes complex, ways. Relationship tries to indicate the connection between two data objects. |
In analysis stage conceptual data model is a bridge between analysis and design for information system.
Conceptual data models is a detailed model that captures the overall
structure of organizational data that is independent of any database management
of any database management system or other implementation considerations. [2]
Conceptual data modeling is a conceptual schema, or High-level data model or conceptual data model, is a map of concepts and their relationships, for example, a conceptual schema for a karate studio would include abstractions such as student, belt, grading and tournament.[16]
Compare data modeling in Object-oriented
Analysis(OOA) and Structured Analysis(SA)
Now Object-Oriented Analysis is prevail analysis in software development especially for large system.
Function and data approach models can be analyzed for structured analysis (SA), and object-oriented approach can be used in object-oriented (OOA). The following will discuss the data modeling for different analysis.
The function and data approach models a system in terms of two concepts. Without trying to be precise, functions are active and have behavior whereas data are passive containers of information that can be manipulated by the functions. The function and data approach models abstractly the behavior of a traditional computer system with a program and a data store. Most traditional software engineering methods such as SA, JSD, SREM (RDD), SADT are function and data methods.[4]
In the object-oriented approach (and here I also include object- based techniques) a system is modeled in terms of objects only. These objects offer services (behavior) to the surrounding world and they contain information. Real-world entities are directly mapped onto objects in the model world. This is in contrast to the function and data approach wheel the real-world entities are mapped onto two structures: functions and data.[4]
So for SA data can be modeled and function can be express by diagram. For OOA, all state will use data model, conceptual data model, logic data model, physical data model.
In SA after the requirement determined, there are several modeling in different stage. In structuring system process requirement people use process modeling; in structuring system logic requirement requirements use logic modeling; in structuring system data requirements use data modeling [2].
In OOA all analysis stages use data model because in system there are only object and their behavior. There are four stages, define use case, define domain model, define interaction diagrams, and define design class diagrams. So for every stages we can use data modeling to figure it out for analysis.
Which type of modeling we will choose? The answer is it depends.
- In case SA and OOA have different ranges, how do we circumscribe - positively and negatively - these ranges? Any overlaps ? I regard this more as a cultural issue than a technical issue. Even if OOA is more applicable than SA, from a technical perspective, many DP organizations have too much inertia to switch. New paradigms are generally accepted only when the old paradigm fails to solve new problems with which the organization is faced. Thus, I feel the OOA will be more politically acceptable in environments where SA has failed on large, visible projects; and also on projects where reusability and graphical user interfaces are seen as key issues from the onset.[4]
- Can SA be used effectively to produce the requirements for a system that will be designed and implemented in an 00 fashion? The key word in this question, I believe, is “effectively.” From this perspective, the answer is “no.” The transition from structured analysis to structured design is difficult enough; the tranition from SA to OOD/OOP is even more difficult, because the modeling notation is so different, and because the emphasis is so different in SA (i.e., functions) than it is in OOD/OOP (objects). Brute-force methods can be used to move from SA to OOD, but it is not a seamless integration.[4]
- If not, is it possible to adjust SA, what needs to be added? If SA cannot be used at all, what is the key obstacle? Some people have claimed a successful marriage between SA and OOA by using the “event-partitioning” approach described by McMenamin and Palmer in Essential Systems Analysis to “objectify” a requirements model initially created with data flow diagrams; this would them make it possible to go from SA to OOA. But there are three
Compare
Data modeling in agile and traditional Waterfall SDLC.
Waterfall SDLC is useful for some little application because it’s very easy to analysis and design. Agile software development is one of popular method for rapid development.
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.[23]
Agile software development methods propose a new approach to the old problem of quickly developing reliable software that meets user’s needs. But their strong focus on improving the engineering process neglects questions about hot other disciplines fit in, and how agile methods fit in with the larger organization. The role of interaction design, user interface design, and usability in an agile team is unclear. It is also unclear how well
the approaches work with larger teams and projects.[21]
Agile Model Driven Development (AMDD) lifecycle:[25]
Agile development has less in common with the waterfall model. In some eyes the waterfall is discredited, but as of 2004, this model is still in common use. The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts—requirement specifications, design documents, test plans, code reviews and the like. The waterfall model can result in a substantial integration and testing effort toward the end of the cycle, a time period typically extending from several months to several years. The size and difficulty of this integration and testing effort is one cause of waterfall project failure. Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it/adding further functionality throughout the life of the project.[24]
Agile enterprise architects work in an iterative and incremental manner. Agile modelers will follow the practice Apply the Right Artifact(s) and use a wide variety of modeling techniques as required (more on this later). They will also follow the practice Iterate to another Artifact when they realize that the model that they are working on either isn’t the appropriate one with which to depict a concept or because they are simply stuck and need to break out of their “analysis paralysis”. They will also follow the practice Create Several Models In Parallel so that it is easy for them to iterate back and forth between artifacts. Instead of holding a use case modeling session an agile modeler will focus on requirements modeling, or even just modeling, and work on use cases, business rules, change cases, and whatever other artifact they require to get the job done. The advantage of these practices is that the right model is used for the task at hand.
Agile modelers will also follow the practice Model in Small Increments, modeling just enough to fulfill the purpose at hand and then moving on to the next task. They don’t try to create complete models, instead they create models that are just good enough. When they find that their models are not sufficient they work on them some more. The advantage of this approach is that they evolve their models incrementally over time, effectively taking a just-in-time (JIT) model storming approach that enables them to get the models in the hands of their customers as quickly as possible.
On the preceding advice, some
readers may say to themselves “All of this sounds great, particularly for a
project team, but enterprise architecture is different. It’s more
complex. It’s more important. It requires significant modeling up
front to get it right.” Aaarrrrggghhh!!! That’s
old-style thinking.
Follow figure overviews how to take an Agile Model Driven Development (AMDD) approach to enterprise architecture. The enterprise architecture team would define the initial architectural vision and models, a process that would likely take several days or even a week or two. Any longer and you’d be at risk of developing architectural models that don’t actually reflect something that would work in practice. Remember, your models need to be just good enough, not perfect. The idea is that your enterprise model(s) start out small and are fleshed out over time based on the feedback you receive from both the business community and from project teams. [22]
Agile Model Driven Development (AMDD) at the enterprise level.
[22]
In different analysis method you will choose different data model because in different methods the data models are different and you can’t translate them from one to another easily. If you choose agile methodology in your software analysis and design you need choose different data models and you need a rapid modeling tools to meet repaid requirement change. As a key documentation in analysis and design, data modeling should be keep step with code. Because in agile methodology you must allow changes in every stage so you need find a suitable case tool to manage repaid changes, to manage automation, to translate conceptual data modeling to physical model and to reverse easily.
- Scott W. Ambler “Data Modeling 101”http://www.agiledata.org/essays/dataModeling101.html Last updated: November 19, 2006 accessed 11/16/2006
- Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich “Modern System Analysis And Design” Fourth Edition 2004
- http://en.wikipedia.org/wiki/Data_modeling
- George M. Wyner , Jintae Lee, Applying specialization to process models, Proceedings of conference on Organizational computing systems, p.290-301, August 13-16, 1995, Milpitas, California, United States
- Martin,
J., and Odell, J. 1995. Object-Oriented Methods: A Foundation.
- Fowler, M. 1996. Analysis Patterns: Reusable Object
Models.
- Prentice Hall - Larman - Applying UML and Patterns- An Introduction to Object-Oriented Analysis and Design and the Unified Proc
- http://www.comptechdoc.org/independent/uml/begin/umldomainmodel.html
- Extreme programming and agile methods - XP/agile universe 2004 : 4th
Conference on Extreme Programming and Agile Methods, Calgary, Canada,
August 15-18, 2004 ; proceedings / Carmen Zannier,
Hakan Erdogmus, Lowell
Lindstrom (eds.).
- Extreme programming and agile methods :
XP/Agile Universe 2002 : second XP Universe and first Agile Universe
Conference,
- Extreme programming and agile methods - XP/agile universe 2004 : 4th
Conference on Extreme Programming and Agile Methods, Calgary, Canada,
August 15-18, 2004 ; proceedings / Carmen Zannier,
Hakan Erdogmus, Lowell
Lindstrom (eds.).
- http://www.agilemodeling.com/essays/agileModelingXP.htm
- http://www.agiledata.org/essays/agileDataModeling.html
- http://www.agilemodeling.com/aboutam.htm
- Agile
- http://en.wikipedia.org/wiki/Conceptual_schema
- ACM International Conference
Proceeding Series; Vol. 47 archive
Proceedings of the 2003 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology - http://www.agilemodeling.com/essays/introductionToAM.htm
- http://www.agilemodeling.com/essays/whatIsAM.htm
- http://www.agilemodeling.com/essays/whereDoIStart.htm
- Extreme programming and
agile methods-XP/Agile Universe 2004. ISBN 0302-9743
- http://www.agiledata.org/essays/enterpriseArchitecture.html
- http://en.wikipedia.org/wiki/Waterfall_model
- http://en.wikipedia.org/wiki/Agile_software_development
- http://www.agilemodeling.com/essays/agileRequirements.htm
- http://www2.umassd.edu/CISW3/coursepages/pages/cis311/LectureMat/analysis/analysis2.html