An Overview of Methodologies, Models and Notations

Chapter 3 Conceptual Design: An Overview of Methodologies, Models and Notations DES !
!N A generic systems development life cycle (SDLC) was presented in an earlier chapter. You may recall that the purpose for this version of a SDLC was to give you a simplified way of sequentially studying the activities that are utili ed to produce software"intensive infor#ation s$ste#s . !n reality the SDLC for such systems is as diverse and varia"le as the organi ations that create these systems. #hat is common is that all organi ations follow some SDLC for the creation$ maintenance and evolution of their software%intensive information systems. As you read through this "oo& remem"er that most of the activities of an SDLC are done iterativel$ and that several activities may "e performed in parallel with others. 'he SDLC that was presented earlier consists of si( ()) activities* +. !nformation Systems ,lanning - "oth enterprise%level and pro.ect%level planning - and /easi"ility Study 0. Analysis - 1equirements Determination 3% DES !N Conceptual and &h$sical 2. Construction (,urchase) and 'esting 3. !mplementation including 'raining and Conversion ). 4volution - 5aintenance and 4nhancement 'his chapter6s focus is on Activity 78 - Design. 1igorous methodologies and automated software development tools support software%intensive information systems development in the 0+st Century9 therefore this chapter will provide an introduction and overview of the design concept leaving the details of design to several chapters that follow. At some point during Analysis and 1equirements Determination the systems analyst needs to "egin to create models of the identified "ehavior$ data and functionality of the proposed information system. Although the point at which the systems analyst does this fluctuates with every pro.ect$ this model creation and refinement activity is design. Some of the models represent and illustrate conceptual design while others represent ph$sical design. 'he difference in general is that conceptual design models are void of technology details whereas physical design models generally include technology% and programming%specific details. 'he following chapters will ela"orate and illustrate more specifically a"out the conceptual and physical design models. :ow let6s loo& more closely at methodologies$ models and notations. ME'(ODO)O! ES ;ow do you change the oil in your car< ;ow do you "a&e a ca&e< ;ow do you study for a test< :o dou"t you have an answer for all of these questions. Assuming you were going to do one of these three tas&s ("a&ing the ca&e sounds "est=yum>)$ you pro"a"ly have ?a way? of doing it. !s your way the correct way< !s your way the only way< !s your way the "est way< !f you answered$ ?yes?
Copyright 1999 Ronald J. Norman Draft date: October 6, 1999 No part of thi man! cript may be reprod!ced "itho!t "ritten permi ion from the a!thor. #hi boo$ "a pre%io! ly p!bli hed by &rentice'(all, )nc.
46
to all three of these questions$ you are in trou"le> #hy< @ecause you may "e suffering from a severe case of a "ig ego> Someone once said$ ?Systems analysts with huge egos to satisfy should "e e(tinct.? ! tend to agree with this statement. Don6t get me wrong. 'here6s nothing wrong with having confidence in ?your way? of doing things$ "ut maturity and professionalism as a systems analyst demand that you recogni e and ac&nowledge that there are other ways to accomplish the same tas&. 'he way something is done in systems analysis and design is usually called a #ethodolog$. #hen tal&ing a"out methodologies$ some people refer to them as the strategy$ process$ steps$ directions$ or actions they choose to do or thin& a"out something. Several software development authors refer to methodologies in software development as a software develop#ent process or simply a software process AAm"ler$ +BBBC. 5ethodologies can "e (+) o"tained or purchased from another "usiness (you purchase a methodology for "a&ing a ca&e when you "uy the ca&e mi(=it6s on the "o()$ (0) created "y your own "usiness or team (you may have created your own way to study for a test)$ or (8) a com"ination of the two. /or e(ample$ you may use the ca&e mi( methodology generally "ut ta&e shortcuts (li&e not using measuring cups and spoons)$ or do things a little differently along the way (li&e putting the eggs in the "owl "efore the ca&e mi( even though the methodology says to put the ca&e mi( in the "owl first). 5a&ing changes to an e(isting methodology creates a new one= your own=and is often referred to as a h$*rid #ethodolog$ "ecause of the changes that were made. 'here are literally thousands of methodologies for developing information systems "ecause most "usinesses prefer to create their own hy"rid methodology in order to ma(imi e the methodology6s utility to their own organi ational culture. Dating "ac& to the "eginning of information systems development$ four general methodology classifications have evolved= traditional, structured anal$sis + design, infor#ation ,data- #odeling, and o*.ect"oriented . /igure 8.+ presents a "rief summary of each of these "y highlighting some of the more commonly associated techniques and tools used as part of each methodology. Some information systems development colleagues "elieve that protot$ping should "e thought of as yet a fifth general methodology classification. Dn the other hand$ prototyping and its myriad of variations can often "e introduced as part of any of the four general methodology classifications presented here. 'herefore$ prototyping will "e considered a technique used as part of a methodology and will "e presented as such in this "oo&. 5any systems analysis and design pro.ects incorporate some aspect of prototyping since there are many "enefits associated with prototyping. 'hese "enefits are discussed in the prototyping section of the "oo&. 'he 'raditional Methodolog$ 'oday classifying one6s methodology as "eing traditional is often a ?politically correct? way of saying that you have no methodology at all or$ at "est$ an unstructured$ unrepeata"le$ un% measura"le$ ad hoc way of doing something. Can you develop an information system using a traditional methodology< Df course> Someone does it every day> A team consisting of e(actly one
47
mem"er (you developing a system for yourself) pro"a"ly could use and get away very nicely with using this methodology. 'he traditional methodology "ecomes much less effective as the si e of the team grows or as the comple(ity of the information system grows. /or reference purposes$ some tools used in con.unction with a traditional methodology are system flowcharts and hierarchical input%process%output charts (;!,D). 'he implication "eing made here with respect to a traditional methodology is that this methodology has serious pro"lems in most information systems development situations9 however$ the tools used to support it have applica"ility in certain development situations.
Structured Anal$sis and Design Methodolog$ 'he structured anal$sis and design #ethodolog$ classification$ also referred to as the data flow #odeling methodology$ emerged in the mid%+BEFs to complement structured programming$ and today is one of the dominant methodologies "eing utili ed for "usiness%oriented information systems development$ such as is done in management information systems (5!S) departments within "usinesses and governmental agencies. !n this methodology$ the real world is descri"ed "y the flow of data through an information system and the transfor#ations of the data into information as the data move from input to storage to output. A structured analysis and design methodology$ as its name implies$ adds dimensions that allow it to "e rigorous (formali ed)$ repeata"le$ and measura"le. !n addition$ a
48
new dimension was added starting in the early +BGFs=it can "e enhanced "y automated support called co#puter"aided software engineering ,CASE- . 'he CAS4 acronym has evolved more recently into newer terms such as integrated/software develop#ent environ#ent , DE or SDE- . 'erms such as these continue to evolve in the hopes of maintaining relevance (and mar&eting hype) so that in a few years there may "e other terms used to refer to this classification of automated software development tool suite. !n the first edition of this te(t ! referred to this type of software tool suite e(clusively as CAS4. !n this edition ! will mostly refer to this type of software tool suite as !D4 or SD4 (although a few carry%over CAS4 terms may still show up). 'he predominant focus of the structured analysis and design methodology is to do the analysis and design utili ing a functional perspective (approach). !n other words$ the systems analyst uses a ?#hat does the system have to do<? pro"lem%solving approach. #ith the introduction of CAS4H!D4 tools around +BG2$ computeri ed software support has emerged to provide assistance for drawing the methodology notations$ validating and verifying the methodology models that the notations represent$ and allowing management to monitor the progress of a pro.ect via computeri ed pro.ect management support.
/or reference purposes$ names such as Constantine$ De5arco$ Iane$ ;atley$ 5yers$ Drr$ ,aige%Jones$ ,almer$ Sarson$ Stevens$ #ard$ #arnier (warn%yea)$ Yourdon$ and others have made significant and documented contri"utions to the structured analysis and design methodology classification. 'ools such as data flow diagra#s ,D0Ds-$ structure charts$ #arnier%Drr diagrams$ ,etri nets$ and data dictionaries are often used in con.unction with the structured analysis and
49
design methodology. 1emem"er$ conceptually there are only two dominant generic structured analysis and design methodologies (Yourdon$ and Iane and Sarson)$ "ut "usinesses have in most cases created their own hy"rid versions of the generic ones. /igure 8.0 illustrates a sample D/D that is the dominant model used in structured analysis and design. nfor#ation Modeling Methodolog$ 'he infor#ation #odeling #ethodolog$ classification also referred to as the data #odeling methodology or infor#ation engineering methodology$ emerged in the early +BGFs as "usinesses "egan to em"race data"ase management systems. 'oday it too is a popular methodology used to assist in the development of "usiness%oriented information systems. An information modeling methodology su"scri"es to the notion that good engineering is simple engineering. !t approaches the development of information systems predominantly from an infor#ation perspective rather than a functional perspective$ as does the structured analysis and design methodology. 'he real world is descri"ed "y its data and the data6s attri"utes and their relationships to each other. As with the structured analysis and design methodology$ information modeling adds dimensions that allow it$ too$ to "e rigorous (formali ed)$ repeata"le$ measura"le and automated. 'he predominant focus of this methodology is to do the analysis and design from an information perspective. !n other words$ the systems analyst uses a ?#hat information does the system have to "e a"le to provide the user<? pro"lem%solving approach. 'oday there are only a handful of purchasa"le !D4 technology products that fully support an information modeling methodology. /or reference purposes$ names such as ,eter Chen$ James 5artin$ and !an ,almer among others have made significant and documented contri"utions to the information modeling methodology classification. 'ools and techniques such as an entit$"relationship diagra# (see /igure 8.8)$ "usiness area analysis (@AA)$ and information models are often used in con.unction with the information modeling methodology.
50
Su##ar$ Co##ent Methodologies
on
the
Structured
Anal$sis
Design
and
nfor#ation
Modeling
!n my opinion$ the fundamental or &ey difference "etween these two methodologies=which "y the way are often utili ed or "lended together=is the primary pro"lem%solving strategy pic&ed "y the systems analysts. 'he fact is that each of these methodologies must address "oth function and information (data) in order to successfully and completely address information systems needs. As ! have already stated$ it6s really a matter of the primary pro"lem%solving strategy used to address the functions and information. Does a systems analyst "egin with functions or information< 'he structured analysis and design methodology advocates would say ?functions.? 'he information modeling methodology advocates would say ?information.? @oth sides would agree that they need "oth functions and information (data)$ "ut they would disagree with the fundamental (primary) pro"lem%solving strategy used to discover the functions first and data second or the data first and the functions second. O*.ect"Oriented Methodolog$ 'he o".ect%oriented systems analysis and design methodology classification emerged in the mid % to late +BGFs as "usinesses "egan to seriously consider o".ect%oriented%programming languages for developing and implementing systems. 4ven though Si#ula$ circa +B))$ is credited as "eing the first o".ect%oriented language$ popular o".ect%oriented (or o".ect%ena"ledHenhanced) languages such as Smalltal&$ CKK$ D".ective C$ and 4iffel came into their own in the +BGFs and Java was introduced "y Sun 5icrosystems in mid%+BB3. A few other o".ect%enhanced products made their way to the mar&etplace in the +BBFs - perhaps most nota"ly Lisual @asic$ Delphi and ,ower@uilder. All of these o".ect%oriented languages approach programming from a significantly different paradigm than previous programming languages. 1ather than follow the structured$ deterministic$ and sequential programming paradigm associated with languages such as CD@DL$ /ortran$ C$ @asic$ ,LH!$ Ada$ Algol and others$ these languages follow the approach pioneered "y Simula "ased on o*.ects, attri*utes, responsi*ilities, and #essages. Dften history repeats itself. Such is the case with o".ect %oriented analysis and design. Just as structured analysis and design emerged as a complement to structured programming in the +BEFs$ o".ect%oriented analysis and design emerged as a complement to o".ect%oriented programming in the +BGFs. 'he pro"lem%solving strategy inherent in o".ect%oriented programming is to approach the pro"lem from an o".ect (e.g.$ person$ place$ thing or concept) perspective rather than the functional perspective of traditional and structured methodologies or the information perspective of an information engineering methodology. @ecause of this$ o".ect%oriented programming "egan to capture mind% and mar&et%share as a dominant programming paradigm mostly in computer science$ software engineering and scientific programming environments while "usiness%oriented programming remained somewhat s&eptical of its value to them. #ith the increased emphasis on graphical user interfaces (IM!) and software that runs on distri"uted and heterogeneous$ client%server (multi%tier) computer hardware
51
platforms across the !nternet even "usiness%oriented programming is shifting to o".ect% orientation. Since o".ect%oriented programming6s pro"lem%solving strategy is unique$ the need for an o".ect%oriented systems analysis and design approach leading up to the programming tas& ma&es sense. 'he older$ more mature methodologies have limitations in representing a model of the information system that can readily "e implemented using an o".ect%oriented programming language primarily due to their focus on functions or data$ not o".ects. 'his is not a statement that the older methodologies are inferior. 1ather$ they are .ust different and were well suited for the .o" they were intended for. D".ect%oriented analysis and design has good and "ad news associated with it. 'he "ad news is that there is yet another new methodology in the mar&etplace. 'he good news is that much can "e "orrowed from the other pervading methodologies and applied to the o".ect %oriented methodology$ which some "elieve ma&es it more evolutionary than revolutionary. !n other words$ e(perienced systems analysts need not throw out all their &nowledge and e(perience acquired using the other methodologies$ which would tend to demorali e the veterans in the field. 1ather than the o".ect%oriented analysis and design methodology "eing revolutionary$ it is evolutionary in the ?"orrowing from what we already &now? sense. 'he methodology notations and su"sequent models it represents are new$ yet similar to other notations. 'he most difficult aspect of learning an o".ect%oriented methodology and notation for e(perienced systems analysts is the transition from a functional or information (data) centered pro"lem%solving strategy to that of an o".ect pro"lem%solving strategy. 5oving from a ?function thin&? or ?data thin&? pro"lem%solving strategy to an ?o".ect thin&? strategy is not an easy one. /or e(ample$ .ust thin& of the difficulty you would have retraining yourself to type using a Divora& &ey"oard layout$ which is significantly different from the standard Nwerty &ey"oard layout that we are all familiar with> Study$ practice$ e(perience$ and time will all "e important for e(perienced systems analysts to ma&e a successful transition in their thin&ing a"out the pro"lem domain and then determining requirements and documenting them using an o".ect %oriented notation and methodology. 'he use of the o".ect%oriented methodology (or any other for that matter) for the novice systems analyst or trainee should "e less difficult due to the limited e(perience he or she has with other methodologies. !n other words$ novices have less e(perience and ha"its to retrain. Someone who does not &now how to type using a &ey"oard has little or no &ey"oarding memory and ha"its to retrain and could li&ely learn the Divora& &ey"oard with little difficulty. /or reference purposes$ names such as @ooch$ Coad$ Co($ /iresmith$ ;enderson%Sellers$ Jaco"son$ 5ellor$ 5eyer$ Ddell$ 1um"augh$ Shlaer$ #irfs%@roc&$ and Yourdon among others have made significant and documented contri"utions to the o".ect%oriented methodology classification. 'ools and the techniques that support them such as dynamic and static o".ect%oriented models$ sequence$ colla"oration and state diagrams$ and use cases are the "asis for o".ect%oriented modeling. !n :ovem"er +BBE the 1nified Modeling )anguage ,1M)- "ecame a universally recogni ed standard of the D".ect 5anagement Iroup (D5I). 'he M5L is a set of models and notations that give software developers a standard way to visuali e$ specify$ construct$ document
52
and communicate the artifacts of an information system. 'he M5L will "e used later in this "oo& for o".ect%oriented modeling. As we move through time the M5L continues to evolve and "e refined.
1ational Corporation (www.rational.com) - a ma.or contri"utor to the M5L - promotes an o".ect%oriented methodology called the 1ational Mnified ,rocess (1M,) as the process that "est compliments the M5L. 1M, version 3 is illustrated in /igure 8.2$ and it is "ecoming very popular and may someday "ecome the "asis for an D5I%sponsored o".ect%oriented methodology. 0O1NDA' ONA) C(A2AC'E2 S' CS O0 AN O34EC'"O2 EN'ED ME'(ODO)O!5 As discussed in Chapter +$ systems analysis and design is a comple( process. Accommodating this comple( process requires systems analysts to e(ploit commonly understood characteristics or principles for managing comple(ity. As cited earlier$ today6s information systems are comple( and involve tens of thousands$ hundreds of thousands$ or millions of lines of programming code. /or e(ample$ some &nowledgea"le software developers have estimated that 5icrosoft6s popular #indows Dperating System has more than 83 million lines of programming source code=#ow> 'hat6s a lot> !n fact the systems "eing developed today are far more sophisticated than those of .ust five years ago. A personal computer word processor was ?feature poor? "ac& then compared to the ones currently availa"le for purchase. Shrin&%wrap software has moved into the competitive arena of hundreds of thousands or even millions of units in commercial sales. As a result$ each new version or release of the software must e(ceed the features and "enefits of the older version. :ot only that$ new releases often must e(ceed the capa"ility of their strongest software competitor6s currently selling software version. Some common characteristics for managing comple(ity during systems analysis and design are availa"le for systems analysts to use to one degree or another regardless of the SDLC used to develop the information system. At least eight characteristics or principles for managing comple(ity are also considered foundational and are generally accepted characteristics of
53
o".ect%oriented analysis$ design$ and programming. 4ach of these common characteristics is presented here for your consideration. You may already "e familiar with many of them "ecause they often have a much "roader applica"ility to your own personal life$ not .ust to software development. 'hey are* 6% Co##on #ethods of organi7ation 8% A*straction 3% Encapsulation or infor#ation hiding 9% nheritance :% &ol$#orphis# ;% Message co##unication <% Associations =% 2euse :ot all o".ect%oriented "oo&s discuss all eight of these characteristics. ;owever$ "ecause ! "elieve they are important$ ! have included them here. 'hese eight concepts are not necessarily new to o".ect%oriented systems development as other older methodologies incorporate one or more of them in some way. ;owever$ together all eight form the fundamental "uilding "loc&s for o".ect%oriented technologies. 4ach is discussed ne(t.
6% Co##on #ethods of organi7ation assist with organi ing an information systems model as well as the software that is ultimately written. 'he common methods of organi ation that are applica"le here are* a. O*.ects and attri*utes or characteristics . /or e(ample$ you could "e the o".ect and your name$ address$ height$ weight$ color of eyes$ date of "irth$ and so on are some of your attri"utes or characteristics. ". >holes and parts. /or e(ample$ your television set is the ?whole? and the individual parts that ma&e up the television set are the ?parts.? A personal computer system=the whole=usually consists of a "o( with all &inds of hardware in it$ a printer$ a monitor$ a &ey"oard$ and a mouse= the parts. c. !roups and #e#*ers. Conceptually this is similar to wholes and parts$ "ut its e(amples are often different and do not seem to fit neatly into a ?wholes and parts? classification. /or e(ample$ a computer clu" would "e a group and the individual mem"ers of the computer clu" would "e the mem"ers. Your Systems Analysis and Design course would "e the group and the students in the course would "e the mem"ers. ,eople in general are quite familiar and comforta"le with the a"ove common methods of organi ation9 therefore they will "e a"le to related to our Systems Analysis and Design models that ta&e advantage of these concepts. 8% A*straction is the principle of ignoring those aspects of a pro"lem domain that are not relevant to the current purpose in order to concentrate more fully on those that are. A"straction is a concept that you use every day. !t has to do with the amount of detail you care to get involved in. !n systems analysis and design$ this is called levels of a*straction. Let6s say that your friend
54
decides to "a&e a ca&e. ;e offers you the choices of "oth helping him "a&e the ca&e and then helping him eat it or .ust helping him eat it. !f you choose the first option$ you are demonstrating a detailed level of a"straction "ecause you have chosen to get involved with the details of ma&ing a ca&e. !f you choose the second option$ you are demonstrating a generali ed level of a"straction "ecause you chose not to deal with the details of "a&ing the ca&e$ only eating it. 'elling your father that you love him is a"stract$ or generali ed$ while telling him one or more of the reasons why you love him is specific and thus a more detailed level of a"straction. !n systems analysis and design$ a"straction is used to identify essential information system requirements while simultaneously postponing or eliminating non%essential aspects. An a"straction intentionally ignores some qualities$ attri"utes$ or functions of an information system in order to focus attention on others. An a"straction is also a summary$ covering the highlights and leaving out the details. !t also omits the pieces of the system that are not necessary for understanding the system at a given level of detail. 5aps typically represent a good e(ample of a"straction. You can get maps of the Mnited States$ individual states$ counties$ cities$ ip codes$ and so on. 4ach map cited here in succession is less a"stract and hence more detailed than the prior one. !n addition$ a city map intentionally leaves off the details of the surrounding county$ state$ and country that it is a part of in order to allow you to focus on the details of the city. Another e(ample of a"straction would "e to view an aerial picture of your entire university campus. Such a picture would not have detailed information regarding a specific office on a specific floor within a specific "uilding on the campus. A"straction has "een a common characteristic in all of the prevailing information systems analysis and design methodologies. 'herefore$ e(perienced systems analysts can continue to utili e this system%"uilding characteristic as they transition to an o".ect%oriented methodology. 3% Encapsulation or infor#ation hiding is the notion that a software component (module$ su"routine$ operation$ method$ and so on) should isolate or hide a single design decision. 'his notion is "ased on the wor& of David ,amas dating "ac& to the early +BEFs. An e(ample of programming encapsulation may illustrate this notion "est. 'he creation and su"sequent use of a single software component to loo& up student account num"ers in a student data"ase isolates this loo&up feature from the rest of the software that ma&es up the information system. 4ach time the information system needs to loo& up a student account num"er$ this routine is used$ since the logic to loo& up student account num"ers has "een encapsulated within this one routine. !f a new loo&up routine is created$ tested$ and used each time there is a new requirement to loo& up a student account in the data"ase$ two potentially negative things happen. /irst$ prior wor&= software construction and testing as a minimum=is replicated. Second$ additional maintenance activity will "e required for the information system should it ever "e necessary to alter the student loo&up routine(s). !n systems analysis and design$ systems analysts decompose the pro"lem domain into small$ encapsulated units. 'hese analysis and design decisions eventually "ecome software modules. 4ncapsulation helps to locali e their volatility when changes and maintenance are required after they have "ecome software modules.
55
A further ela"oration of encapsulation or information hiding is any mechanism that allows certain portions of the information system to "e ?hidden.? 'his can "e useful in at least two different situations* a. #hen it is important that people only use or have access to a certain su"set of the complete information system. /or e(ample$ while an information system is "eing developed$ development team mem"ers may "e assigned to wor& on a certain part of the system and not allowed access to other parts of the system "eing wor&ed on "y other team mem"ers. Dnce the information system is operational$ certain users may only "e allowed to use a few of the features of the information system while other users may have access to many more features. ". 'o purposely prevent other components of the information system from "eing aware of or una"le to ta&e advantage of certain other components in the system. 'his situation addresses another aspect of encapsulation=assignment of responsi"ilities. Just as in real life you have certain responsi"ilities$ a specific component of an information system has its responsi"ility$ say dispensing cash in an A'5$ while other components of the same system have their responsi"ilities$ which e(clude the dispensing of cash since that function is done "y another component. Another way to thin& a"out encapsulation is from a programming perspective$ which has long since advocated the creation and use of small "loc&s of function%specific code (e.g.$ procedure$ su"routine$ paragraph$ and so on) that can "e assem"led into a wor&ing computer program in a modular fashion$ much li&e the plug%compati"le stereo components in homes today. 4ach of these "loc&s has encapsulated within it one or a few design functions. /or e(ample$ each of the following functions could "e represented "y a small "loc& of computer programming code and then "undled together to perform a higher%level function$ such as registering for courses for this coming school year = ?get student identification (!d) num"er$? ?validate student !d num"er$? ?chec& student !d num"er for outstanding fines$? ?get course !d to add to student6s schedule$? ?determine if a seat is availa"le for this course !d$? ?determine student !d num"er6s eligi"ility to ta&e this course !d$? and so on. /inally$ encapsulation has "een a common characteristic in all of the prevailing information systems methodologies. 'herefore$ e(perienced systems analysts can continue to utili e this system%"uilding characteristic as they transition to an o".ect%oriented methodology. 'here is one su"tle difference. #ith the older$ more mature methodologies$ encapsulation was usually limited to encapsulation of functions separately from encapsulation of data. #ith the o".ect%oriented methodology$ encapsulation incorporates "oth functions and data together into o".ects. 'his notion will "e discussed in more detail later in the "oo&. 9% nheritance is a mechanism for e(pressing similarity. Just as you inherited certain physical features from your mother and certain ones from your father$ so also can information system components inherit certain things from related components. /or e(ample$ /igure 8.3 shows that a hierarchical or parent%child relationship e(ists "etween a group called ,erson and groups of /aculty$ Administrator$ and Student. #e purposely are using the singular for each of these words in &eeping with the notation that is used throughout the "oo&$ "ut &eep in mind that Administrator means one or more administrators$ as does student and faculty.
56
A si"ling relationship e(ists "etween /aculty$ Administrator$ and Student. 'here are certain characteristics that can "e associated with ,erson and thus inherited "y all the children in the hierarchy=/aculty$ Administrator$ and Student=such as name$ address$ phone num"er$ and date of "irth to name a few. Dther characteristics may "e unique to a single si"ling. /or e(ample$ office hours may only "e applica"le to /aculty$ .o" title may only "e applica"le to Administrator$ and grade point average may only "e applica"le to Student. 'hese characteristics would "e associated with the specific child node in the hierarchy. Similarly$ there are certain things that a ,erson can do that would "e common to /aculty$ Administrator$ and Student$ such as eating at the cafeteria and wal&ing on campus. Li&ewise$ there are certain things that are unique to each of the children nodes. /or e(ample$ a /aculty person may assign grades and add students to the class$ whereas an Administrator person may manage people and &ey in administrative data to the computer$ while a Student person could register for courses and ta&e an e(am. 'hese actions would "e associated with the specific child node that each "elongs to. As is usually the case in real life$ inheritance in systems development is a one %way street= down the hierarchy=from the ?parent? node to each of the ?children? (si"lings) nodes. ;owever$ as you view /igure 8.3 you o"serve three arrows=each pointing upwards toward the ?parent.? 'he e(planation for this is that each of /aculty$ Administrator and Student ?e(tends from? or ?is an e(tension of? or ?is a speciali ation of? or ?inherits from? the ,erson=hence the upward%pointing arrows.
:% &ol$#orphis# in the general sense is the a"ility to ta&e on different forms. /or e(ample ; 0D can ta&e on three forms=water$ steam$ or ice. !n a sense$ you could say that you are polymorphic with respect to your "ehavior when approaching a traffic signal in your car. You respond differently depending on the status of the signal light. !n software$ for e(ample$ the print operation associated with te(tual characters and num"ers can print te(tual characters and num"ers ?"ecause it &nows how to do this?. 'he print operation associated with graphic sym"ols and images can print graphic sym"ols and images ?"ecause it &nows how to do this?. 4ach of the print operations .ust descri"ed will print something on a printer in the a"stract sense9 however$ at the detail level each of these print operations does its .o" a little differently "ecause what is "eing printed is of a different type=te(tual characters and num"ers$ graphic sym"ols$ and images. @ecause of the differences at the detail level$ the print operation is considered
57
polymorphic. ,olymorphism in computer programming isn6t new$ "ut its use during o".ect%oriented analysis and design "y systems analysts pro"a"ly is. ;% Message co##unication is the way o".ects in an o".ect%oriented methodology communicate with each other. !t is similar to a su"routine call with parameters or a paragraph or procedure call in some other conventional programming languages such as /ortran$ CD@DL$ C$ or ,ascal. 'his concept is widely understood "y practicing systems analysts so it$ too$ can "e directly transferred into an o".ect%oriented methodology "y them. <% Associations are useful to assist with relating things in an information system to each other. 'hings that happen at the same time could "e associated as well as things that happen under similar conditions. /or e(ample$ L!SA$ 5asterCard$ Discover$ and other credit card companies send out periodic statements showing us our "alance owing. 'hese companies often ta&e this opportunity to insert a num"er of advertisements along with the statement$ since the postage is often the same with or without the advertisements. Also$ /igure 8.36s hierarchy is an e(ample of association. =% 2euse% 4verywhere you loo& in your world you see reuse in one form or another. 'he same power cord can often "e used for your computer$ your monitor$ or your printer. Apartment windows often come in standard si es$ and do ens of a certain si e window are used in a large apartment comple(. 'he can of orange .uice you "ought last time pro"a"ly loo&s .ust li&e the one you "ought today. ;ow many shirts or "louses do you have that reuse the same type of "utton< ;ow often do you reuse a te(t"oo& that was used "y some other student "efore you< ;ave you ever reused a videocassette to record over some other event that you recorded at a previous time< 1euse is a much tal&ed a"out concept in systems analysis and design$ "ut one which is still struggling to ma&e a significant contri"ution to the development process due primarily to two factors. 'he first factor is the retraining of the mind%set of the analysts and programmers who are accustomed to creating their own systems models and code. 'his translates to the ?not invented here? mentality held "y some systems analysts and programmers. !n other words$ they want to create and de"ug their own ?whatever? rather than use someone else6s ?whatever? that does the same thing (and is already de"ugged ! might add>). 5anagement can address and overcome this pro"lem given proper amounts of time$ retraining$ and other motivators for the systems analysts and programmers who are resistant to reuse. 'he second factor relates to the administrative factors that must "e esta"lished for setting up a li"rary of reusa"le models and code. 'his is no easy tas& for a variety of reasons including strategy to accomplish$ personal$ organi ational$ cultural$ and legal aspects. As used in our everyday world$ reuse can ta&e one of three forms* ,6- sharing, ,8- cop$ing or cloning, or ,3- ad.usting. 4ach is discussed here. An e(ample of sharing is when you use a te(t"oo& and then sell it "ac& to the "oo&store$ which in turn resells it to another student. Dr everyone living in or visiting your apartment or home shares (reuses) the telephone you have. !n software development$ a su"routine$ module$ paragraph$ procedure$ service$ or file definition are all potentially reusa"le. A small procedure could "e created that only loo&s up student identification num"ers in a student data"ase and then responds
58
with valid or invalid. Such a procedure could "e used over and over again$ intact$ within an information system. An e(ample of cop$ing or cloning is what is done every day in the manufacturing industry. An automo"ile model is prototyped and then moved into production to produce thousands of that model. !n software development$ we could have a paragraph of a CD@DL program that we copy and put into another CD@DL program$ giving two paragraphs that are identical. An e(ample of ad.usting is a variation on the copying or cloning. Msing the automo"ile e(ample$ as a certain model moves down the manufacturing assem"ly line$ standard features for this automo"ile are assem"led (copying) as well as different com"inations of options are assem"led such as air conditioner$ CD player$ spoiler$ tinted glass$ and so on (ad.usting). Iranted that these options are standard reusa"le components .ust assem"led in different com"inations in the particular automo"ile. ;owever$ the final product$ the automo"ile$ is a variation on the standard ma&e and model. A variation of the ad.usting type of reuse is the situation in which the standard item is actually changed and then used in some other application. /or e(ample$ a computer modem ca"le can have two of its wires physically swapped within the ca"le housing$ and then this ca"le "ecomes a different &ind of modem ca"le called a null modem ca"le=an ad.ustment to the standard ca"le. An e(ample of ad.usting in systems analysis and design is when a programmer locates a su"routine$ module$ or paragraph$ and so on from a li"rary of reusa"le components. 'he su"routine "ecomes the programmer6s "eginning point for creating a new su"routine$ somewhat similar to the original li"rary version. 'hen the programmer "egins ma&ing ad.ustments to the su"routine$ such as removing some of the code in the su"routine$ changing other parts of the code$ and adding new code to this new su"routine to meet a specific purpose. 'he end result is a new su"routine. 'he eight characteristics descri"ed a"ove play pivotal parts in the o".ect%oriented systems analysis and design methodology. 'his is indeed good news "ecause most people=software developers and users of computers=are already familiar with most of them.
'(2EE C)ASS C C(A))EN!ES
N N0O2MA' ON S5S'EMS DE?E)O&MEN'
'hree of the most significant challenges that have continuously "een associated with the pervading analysis and design methodologies appear to "e resolved or at least significantly reduced with an o".ect%oriented analysis and design notation and methodology. 'he first of the three challenges is that most other methodologies construct separate models for the functional and information views of the proposed information system as shown in /igure 8.)a as Challenge ?A?. !n addition$ a third component="ehavior or user%interaction=is "ecoming more important in today6s information systems and needs to "e modeled as well. 'he popularity of interactive$ graphical user interfaces and o".ect%oriented operating systems$ such as #indows$ 5acintosh and others has shifted programming from a deterministic approach to an event %driven approach. 'his introduces the need for a third view of the system=a "ehavioral view$ and this view is rapidly "ecoming quite important.
59
'he function and data multiple models have value in that each depicts some portion of the same information system. 'he difficulty lies in the fact that neither systems analysts nor !D4 software tools have "een a"le to completely validate and verify the consistency and accuracy of the integration of the two models simply "ecause they each represent a different perspective of the information system. !n o".ect%oriented systems analysis and design several integrated models are used to represent all three views=function$ information$ and "ehavior. 'his is a very significant move forward "ecause more rigorous validation and verification of the integrated set of models is now possi"le.
'he second challenge that has continuously plagued information systems development is the prover"ial transition from analysis to design as illustrated in /igure 8.)" as Challenge ?@?. Dnce again$ in most of the older methodologies one or more analysis models are created and then a completely new model or set of models is drawn during design that communicates more specifically to the programmers for the impending programming effort. Analysis models have historically "een a communication tool "etween the systems analyst and the user. 'he design models have historically "een a communication tool "etween the systems analyst and the programmer. #ith the o".ect%oriented analysis and design notation and methodology there is no transition to design. #hat happens instead is a progressive e@pansion of the analysis models as they progress through design to include additional refinement details that address the programming tas& that is approaching. So systems analysts$ users$ and programmers deal with one model of the information system from analysis all the way through design$ coding$ testing$ and implementation. 'he resulting information system can "e validated "ac& to the original analysis model "ecause it is still the most valid model of the system even after the system is implemented.
60
'he third information systems development challenge is depicted in /igure 8.)c as Challenge ?C?. Software developers have historically had two common mindsets* +) ! write "etter code than any other programmer$ and 0) #hen ! need to ma&e a programming change ! go directly to the source code and figure out where to ma&e the change$ regardless of documentation availa"ility. 'he first of these two mindsets is pro"a"ly a "it distorted and fosters a ?start from scratch? software development philosophy rather than one that thin&s$ ?Let6s try to reuse someone else6s code as much as possi"le "efore writing my own code.? 'he second mindset simply can consume large amounts of development time as one loo&s through hundreds if not thousands of lines of source code to ma&e a change. Dften$ a programmer in the midst of ma&ing a software change decides to rewrite portions of the code "ecause it is su"%standard (called ?spaghetti code? in some software development circles). 'he notion of reuse is "ecoming more and more ?fashiona"le? (and economically Atime and moneyC necessary). !n addition$ modification of models is proving to "e less time%consuming than modifying source code assuming an !D4 software development tool is "eing used to maintain the models and automatically generate source code for the software developers. D".ect technology ena"led via an o".ect%oriented methodology coupled with o".ect%oriented models of the proposed information system significantly assists in overcoming these three historical information systems development challenges as illustrated in /igure 8.)d. 'he o".ect% oriented approach to developing information systems com"ines a ro"ust set of inter%related o".ect%oriented models that are more favora"ly integrated with each other starting with the static and dynamic models created during the early activities of the development lifecycle and culminating with the deployment models that could "e created near the end of the lifecycle. D".ect%oriented approach proponents argue that there is no transition from analysis to design or need to redraw analysis models to reflect physical design models as in the older methodologies. !n my opinion$ for now$ the o".ect%oriented approach is the "est the software development industry has to offer until something "etter comes along=and something "etter eventually will come along.
61
C)ASS 0 CA' ON '(EO25 D".ect%oriented methodologies and programming are "ased on classification theory$ a fundamental concept most of us learned prior to or during our first few years of elementary school. 'he ?common methods of organi ation? characteristic discussed earlier in this chapter is really a"out Classification 'heory. Classification theory simply states that people constantly and consistently
62
use three methods of organi ation to help clarify their thin&ing a"out something. 'he three methods are* 6% 'he differentiation of e@perience into particular o*.ects and their characteristicsA o*.ects and their characteristics . An e(ample is "eing a"le to distinguish "etween a tree and its si e or spatial relationship to other things in our world$ such as a roc&$ flower$ "ush$ "icycle$ and so on. 8% 'he distinction *etween whole o*.ects and their co#ponent partsAwholes and parts . /or e(ample$ a tree is made up of leaves$ "ranches$ and roots$ while a "icycle is made up of wheels$ rims$ spo&es$ pedals$ seat$ and handle"ars. 3% 'he for#ation of and the distinction *etween different classes of o*.ectsAclasses or groups of o*.ects% 4(amples include grouping trees (maple$ elm$ palm$ eucalyptus) into a tree class9 grouping "uildings (homes$ apartments$ offices$ churches$ schools) into a "uilding class. ,eople6s common understanding and use of classification theory is one strong reason why an o".ect%oriented perspective is a via"le approach to analy ing$ designing$ and "uilding information systems. ,eople are already familiar with it. Learning something totally new is not required. '(E 1N 0 ED MODE) N! )AN!1A!E ,1M)- AND AN O34EC'"O2 EN'ED ME'(ODO)O!5 Since their "eginning in the late +BGFs$ several methodologists$ researchers$ practitioners and authors have put forth specific o".ect%oriented notations and methodologies (refer to an earlier section of this chapter for some names9 also refer to the end of chapter references). !n one%way or another many of these people contri"uted and colla"orated to help shape the M5L into the worldwide standard that it is today. /ormally adopted in :ovem"er +BBE$ the M5L includes a set of nine models and notations for each of the models along with a #eta#odel=that is$ a model of the constructs in M5L. 'he complete set of M5L models and notations is e(tensive9 therefore$ for the purpose of this te(t$ a su"set of the M5L models and notation will "e presented$ discussed and used. !t is one thing for a group of professionals to create a worldwide uniform set of o".ect% oriented models and notations (the M5L). 5any other disciplines$ such as industrial architecture and electrical engineering$ have had standard model and notation sets for many$ many years. !t is an entirely different=and far more challenging=thing to arrive at a worldwide o".ect%oriented methodology standard. 1emem"er our earlier discussion a"out generic methodologies=traditional$ structured analysis O design$ information modeling and o".ect%oriented=and that most organi ations tailor these generic ones to create customi ed versions< Although we in the software development industry overwhelmingly want to create standardi ed models utili ing standardi ed notations$ we want to create and manipulate these notations and models in different ways=hence$ different methodologies. /or the purpose of this te(t a simple o".ect%oriented methodology will "e presented$ discussed and used. 'his simple methodology is "ased on aspects of a proposed standardi ed ?unified process? and other methodologies. 'his "oo& is not intended to "e the definitive wor& on the M5L nor the methodology to apply it. !nterested readers are directed to the @ooch$
63
Jaco"son$ and 1um"augh references at the end of the chapter for more definitive wor&s. ,art of the rationale for using a simple methodology in this "oo& is that more than li&ely any software development organi ation you (go to) wor& for will train you in its own unique o".ect%oriented methodology. 'he simplified o".ect%oriented methodology is presented here "efore giving an overview of the M5L. 1emem"er$ the methodology is the way in which we will create and manipulate (use) the M5L6s models and notations. 'he methodology consists of seven (E) activities as follows* +. !dentify the purpose of the information system. 0. !dentify the primary actors and features of the information system. 8. !dentify Mse Cases and create a Mse Case Diagram for the features. 2. !dentify D".ects and their Classes and create a Class Diagram. 3. Create !nteractionHScenario Diagrams. ). Create detail logic for Dperations. E. 1epeat activities +%) as necessary refining and fine%tuning the various diagrams. As you can see$ the methodology is listed sequentially a"ove$ primarily to illustrate the different activities that are performed during systems analysis. #hat are not shown in this sequential list are the notions of parallelis#, su*stitution, and o#ission. &arallelis# gives the pro.ect manager license to perform activities in parallel when a systems development situation permits. Su*stitution gives the pro.ect manager license to su"stitute activities out of the standard order presented in the a"ove list when a systems development situation permits. Li&ewise$ o#ission gives the pro.ect manager license to omit one or more detail activities shown in the list when the situation permits. A simple e(planation of each of the methodology activities is presented here since each one is ela"orated on in the following chapters. Activit$ 6: dentif$ the purpose of the infor#ation s$ste#% 'his activity needs to "e done prior to doing any o".ect modeling of the pro"lem domain. !n fact$ this activity should "e done "efore any type of modeling is done. 'he user and the systems analyst need to identify$ understand$ and document the system6s intended purpose. /or e(ample$ a university course registration system purpose could "e stated as$ ?'he information system will allow authori ed students to add$ change$ and delete their own course seat reservation.? Sometimes$ the purpose of the information system can also seem li&e a feature=see Activity 0 "elow. #hen this seems to "e the case$ the system6s purpose is usually "roader in scope than any single feature. 'his activity com"ined with activity 0 "elow is analogous to identifying the information system6s goals and o".ectives as discussed in Chapter 0. Activit$ 8: dentif$ the pri#ar$ actors and features of the infor#ation s$ste#% #or&ing and interacting with the user(s)$ the systems analyst should identify all of the significant (primary) actors and features associated with this new or changing information system. Dften$ this activity translates into identifying a list of .ust a few features (for e(ample$ less than a do en) in a small%scale information system or a small%scale one that is undergoing a few changes$ and do ens of features for a medium to large%scale information system or a medium to large%scale
64
one that is undergoing significant revision. 'his activity com"ined with activity + a"ove is analogous to identifying the information system6s goals and o".ectives as discussed in Chapter 0. A couple of features for a university course registration information system would "e ?register for course? and ?drop a course.? Actors represent roles that people or other information systems play with respect to this information system. A couple of actors for a university course registration information system would "e ?student?$ ?faculty?$ and ?registrar?. /eatures most often answer the following question$ ?#hat can actors do with the information system<? 'he emphasis is on functionality=what the system will do=rather than technology that addresses how the system will do it. Activit$ 3: dentif$ 1se Cases and create a 1se Case Diagra# for the features% Mse cases parallel features=one for each feature. 'he individual use cases are grouped together to create a Mse Case Diagram. 'his is the "eginning point for using the M5L and an o".ect%oriented methodology. As mentioned "efore$ activities + and 0 a"ove should "e done regardless of modeling$ notation or methodology. /igure 8.E illustrates a simple Mse Case Diagram showing four use cases that could "e part of a university course registration information system. Activit$ 9: dentif$ O*.ects and their Classes and create a Class Diagra#% D".ects represent real%world persons$ places$ things or concepts (e.g.$ an airline flight from Los Angeles to :ew Yor&). A Class represents a group of o".ects that have similar characteristics. /or e(ample$ there are a"out 8F$FFF student ?o".ects? attending our university this semester9 we could group them all together and call them the Student class. A Class Diagram shows the collection of all classes in the information system. /igure 8.+F near the end of this chapter illustrates a class diagram for a Lideo Store information system. Activit$ :: Create nteraction/Scenario Diagra#s% 4ach Mse Case (/igure 8.E) in a Mse Case diagram is e(panded to reveal the details of what it really ta&es to accomplish ?register for a course?$ ?manage the curriculum?$ etc. (for e(ample). 'his ela"oration is called a scenario and it represents a ?start%to%finish? series of actions (steps) necessary to accomplish the use case. Dne of two types of !nteraction Diagrams is used for this ela"oration=a SeBuence Diagra# or a Colla*oration Diagra#. 4ach of these diagrams is ?dynamic? in nature in the sense that if you follow the diagram you will "e a"le to envision ?what it ta&es? to perform the feature that it is descri"ing=registering for a course$ for e(ample. /igure 8.G illustrates a portion of a Sequence Diagram for the ?registering for a course? use case. Activit$ ;: Create detail logic for Operations% Dperations are the transformations and actions that an o".ect or class is responsi"le for. Dperations usually contain the "usiness rules$ policies$ procedures$ logic$ and algorithms that are necessary for an information system to "e useful. Dperations are usually identified as part of identifying o".ects and classes (Activity 2) or as part of creating the interaction diagrams (Activity 3) or a com"ination of "oth. !n /igure 8.G o"serve the names a"ove the arrows on the sequence diagram. 4ach of these names represents operations=the detail actions that the class directly a"ove the arrow6s ?tip? is responsi"le for ta&ing care of. 5ost of these operations need detail logic within them in order to do what their name implies they do$ and this logic is entered during activity ).
65
As mentioned earlier$ each of the a"ove activities will "e discussed and illustrated in much more detail in the following chapters as we learn how to create information system models using the M5L. 'he final section of this chapter presents an overview of a M5L Class Diagram for a Lideo Store !nformation System. 'he purpose for doing so is to give you a "etter appreciation of what one M5L diagram loo&s li&e as we prepare to move forward into the following chapters.
A 1M) Class Diagra# for a ?ideo Store nfor#ation S$ste# !f you were as&ed to draw an office "uilding or a home$ could you do it< ,ro"a"ly so> #hy could you draw an office "uilding or a home< You could do so for at least two reasons* (+) You have a
66
mental picture of what an office "uilding or home loo&s li&e (even though your mental picture may "e quite different from someone else6s mental picture of an office "uilding or home)$ and (0) you already &now the "asic notation needed to draw an office "uilding or home$ such as lines$ circles$ rectangles$ triangles$ squares$ windows$ doors$ patios$ porches$ roofs$ and so on. :ow if you were as&ed to draw a picture of a payroll information system or even a university course registration information system using the Mnified 5odeling Language (M5L)$ could you do it< ,ro"a"ly not$ unless you (+) have some understanding of how a payroll information system or a university course registration system functions$ and (0) &now what a the M5L loo&s li&e=its notation and models=and have some minimal understanding of how to use the M5L to draw the models of either of those information systems. #hat6s really required here< At least two things come to mind* (+) familiarity and understanding with a pro"lem domain (e.g.$ office "uilding$ home$ payroll system$ university course registration system)$ and (0) familiarity and understanding of specific notation and models. /amiliarity with and understanding of a pro"lem domain means that you have &nowledge of a specific pro"lem domain ranging from minimal &nowledge all the way to "eing a su*.ect #atter e@pert ,SME-=one who &nows a great deal a"out a pro"lem domain. Notation is a set of sym"ols used to communicate or represent something. An alpha"et is a universal e(ample of a notation. /amiliarity with a notation implies that you &now which notation sym"ols are availa"le to use$ and understanding of a notation implies that you &now the ?pac&aging? for integrating and com"ining the notation sym"ols into models. As you &now$ the real value of an alpha"et is "eing a"le to com"ine the alpha"etical sym"ols into meaningful words$ sentences$ paragraphs$ etc. Li&ewise$ "eing a"le to pac&age the M5L notations into the various M5L models (diagrams) is its real value. #hat follows now is a discussion of a simplistic$ partially completed M5L Class Diagram that represents the user requirements for a Lideo Store information system. 'he intent is to show you in advance what an o".ect%oriented M5L class diagram for a pro"lem domain loo&s li&e so you can see ?the "ig picture? "efore diving into all the details of the various M5L models in the following chapters. A colleague once made the following comment a"out te(t"oo&s. ;e said$ ?'e(t"oo&s are very good at e(plaining all of the ingredients of a tossed salad (lettuce$ tomatoes$ onions$ carrots$ celery$ and so on)$ "ut few te(t"oo&s actually show you a completed tossed salad.? 'he intent of this section is to show you the completed ?tossed salad? allowing for some license with respect to the o".ect%oriented M5L class diagram model really "eing complete. As we wal& through the following e(planation you may find it helpful to draw upon your su".ect matter e(pertise as a customer of your favorite video rental store (assuming you have one). A video saleHrental store information system is used for presenting the o".ect%oriented user requirements M5L class diagram model e(ample. 'he e(ample is incomplete from two perspectives. /irst$ the details of the video store information system pro"lem domain are omitted for simplification purposes. Second$ the M5L class diagram model that is presented is only showing the "asics of the M5L class diagram notation. As you might e(pect$ the difficulty of presenting an e(ample at this point in the "oo& is that you need to focus your attention on the o".ect %oriented model6s M5L notation rather than on the details of the specific video store pro"lem domain "eing depicted "y the model. ;opefully$ you have purchased or rented a video from a video store and$ "y
67
doing so$ have at least minimal &nowledge of the video store pro"lem domain. Some of you may wor& at a video store or have done so in the past$ ma&ing you somewhat of an S54. !f you fit into this classification$ reali e that the model presented here pro"a"ly does not e(actly represent the video store information system you have personal e(pertise with. 'his is in &eeping with Chapter +6s section on ?#hat ma&es systems analysis and design such a difficult activity? and the opening comments in this chapter that suggest that there are potentially many different solutions for every pro"lem domain. Since this is a model of a fa"ricated automated information system$ please recogni e that there could "e many other variations to the way this model is "eing presented. 'his video store model (with much more detail) was created "y a large team of three%do en or so ?aspiring systems analysts? (undergraduate students) wor&ing in the classroom for a"out two months during a semester. 'he instructor was serving dual roles acting as the senior systems analyst and simultaneously as the video store ownerHmanager (user). 'hese requirements may or may not "e the same as the ones you would come up with wor&ing with a different user in a similar pro"lem domain. 1emem"er$ the intent here is not to ma&e you su".ect matter e(perts for the video store pro"lem domain$ "ut to e(pose you to a partially completed M5L class diagram model of user requirements so that you will &now what one loo&s li&e ?early in the game?. /igure 8.B illustrates the more commonly used M5L class diagram notation sym"ols that are used in the Lideo Store class diagram in /igure6s8.+F$ 8.++a$ 8.++" and 8.++c. 'he notation is simplistic in that there are only a few sym"ols$ yet it is sophisticated enough to depict large and comple( information systems$ ones e(hi"iting functions$ data$ and "ehavior. 1eferring to /igure 8.B$ the sym"ols in the notation are the Class$ !enerali7ation Class relationship $ O*.ect association$ O*.ect Aggregation association $ and O*.ect Co#position association . 4ach of these is "riefly discussed as we wal& through the class diagram "ecause they will "e defined and descri"ed in greater detail in later chapters. 'o assist with the discussion of the Lideo Store6s M5L class diagram and its notation$ /igure 8.+F will "e used. /igure 8.+F is the M5L class diagram model for the video store6s information system for purchasing$ selling$ and renting inventory items$ such as video movies and games$ LC1s$ and concession items such as popcorn$ sodas and candy. !n addition$ the information system &eeps trac& of these same inventory items when they need to "e ordered so that the store will have enough of them to sell or rent to its customers. 'he video store6s user requirements will "e identified and discussed in the ne(t chapter. 'he intent here is to show you the resulting M5L class diagram model "ased on the user requirements that we assume have already "een identified. You may recall that a user requirements model of a video store6s mission$ goals$ o".ectives$ and tactics was presented in Chapter 0. Simply stated$ classes represent the things that an information system needs to &now a"out within a specific pro"lem domain. Classes can "e any of people$ places$ things$ or concepts$ such as employee$ vendor$ store location$ rental transaction$ video$ LC1$ and so on. Some classes will never contain o".ects=we refer to these as a"stract classes=while others will contain o".ects. A"stract classes are used to communicate Ienerali ation (%Speciali ation) relationships among classes. All other classes in the class diagram should contain o".ects although that is not a rule$
68
.ust a good guideline. D".ects are the actual instances of people$ places$ things$ and concepts and are always associated with a class=in other words$ o o".ects can stand alone in a class diagram9 they must "elong to a class. /or e(ample$ individual video o".ects associated with the Lideo class would "e each specific movie video that is availa"le for either rent or sale.
!n /igure 8.+F !nventory$ Saleltem$ 1entalltem$ and 'ransaction are a"stract classes "ecause they represent two layers of Ienerali ation class relationships. :one of them have (or will ever have) o".ect instances. Lideo$ Iame$ Concession!tem$ LC1$ 4mployee$ StoreLocation$ Sales'ransaction$ 1ental'ransaction$ Lendor$ 5em"er$ ,urchaseDrder$ Sale1entalLineltem$ and ,DLineltem are all e(amples of classes that can have o".ects and will more than li&ely have one or more o".ect instances. You might "e thin&ing$ ?;ow do you determine what is a class with o".ects and what is an a"stract class<? 'he determination of classes versus a"stract classes often surfaces during user requirements discussions with the users or later on as the systems analyst refines the class diagram. Classes and a"stract classes are treated similarly in most situations$ since a"stract classes are simply classes that are and always will "e void of o".ects. 'he way to distinguish an a"stract class from a class with o".ects on a M5L class diagram is to loo& for the Ienerali ation notation sym"ol. 'he class touching the arrowhead is a"stract="ut that is not a rule either$ .ust a good guideline. /le(i"ility in this regard is important.
69
Classes have attri*utes or characteristics that descri"e them in more detail. /or e(ample$ in /igure 8.B$ the 5em"er class has attri"utes mem"er:um"er$ first:ame$ last:ame$ telephone$ address$ city$ etc. Attri"utes are discussed in much more detail in a later chapter. Classes have operations that the class is responsi"le for accomplishing. !n /igure 8.B$ for e(ample$ the 5em"er class has chec&DutLideo$ chec&!nLideo$ and "uy!tem as its operations. Dperations are discussed in much more detail in a later chapter. 'he ne(t four M5L class diagram notation sym"ols are the Ienerali ation class relationship$ D".ect association$ D".ect Aggregation association$ and D".ect Composition association. All four of these notation sym"ols are used to associate classes with other classes in the M5L class diagram. All classes have responsi"ilities. Dne of their responsi"ilities answers the question$ C>ho# do DnowEC 'he Ienerali ation class relationship and the three o".ect associations represent this responsi"ility in the M5L class diagram. 4ach of these four relationship types is "riefly discussed ne(t.
'he !enerali7ation class relationship notation sym"ol is used to associate one generali ation class with one or more speciali ation classes in a hierarchical parent%child pattern type of relationship. /or e(ample$ a Sale!tem class$ the generali ation portion of the parent%child pattern$ may have several speciali ation classes$ such as Lideo$ Iame and Concession !tem. 1efer "ac& to /igure 8.3 for another e(ample of the generali ation ?parent%child? pattern. Dften speciali ations can "e thought of as "eing a ?type? or ?&ind? of the generali ation. /or e(ample$ a game is a type
70
of sale item as well as a type of rental item. 'he Ienerali ation relationship is a class relationship =as its name implies=and not a relationship "etween the o".ects of each of the classes involved in the relationship. 'he ne(t three notations are used to relate o".ects to other o".ects within classes. 'he O*.ect association M5L notation sym"ol is used to relate two class sym"ols with each other$ however in reality the relationship is really "etween o".ects in each of the classes=hence the name D".ect association. 'he D".ect association relationship is used when two un%related classes in the real%world need to "e related in order for an information system to perform its wor&. Dften this type of relationship is considered to "e ?wea&? in the sense that the only reason the two classes are related is for purposes of this information system. /or e(ample$ "oth Sales'ransaction and 1ental'ransaction classes in /igure 8.+F are connected to the 5em"er class e(plicitly "ecause mem"ers of the video store perform these two types of transactions. 5em"er o".ect=people li&e you and me=are very different from Sales'ransaction and 1ental'ransaction o".ects. Constraints are indicated on all three types of D".ect associations. /or e(ample$ referring to the Sales'ransaction to 5em"er D".ect association in /igure 8.+F$ a specific 5em"er may have ero or more (represented "y ?P? or ?F..P?) Sales'ransactions and a specific Sales'ransaction is related to only one specific 5em"er (represented "y ?+?). Some mem"ers never "uy anything in a video store9 they only rent and these constraints allow for this condition. 'he Aggregation O*.ect association (the clearHwhite diamond sym"ol) and the Co#position O*.ect association (the "lac& diamond sym"ol) M5L notation sym"ols are used to associate two class sym"ols in a ?#hole%,art? pattern type of relationship. 'he difference "etween these two associations will "e discussed in a later chapter$ and the ?whole? o".ect in the association is touching the diamond sym"ol while the ?part? o".ect in the association is touching the end of the line. /or now$ a generic e(ample of such an association is an Automo"ile class and an Automo"ile,art class. 'he Automo"ile class would "e the ?whole?$ and it would have several Automo"ile,art ?part? type classes such as Door$ #indow$ #heel$ Seat$ Iauge$ and so on associated with it. !n /igure 8.+F$ the ,urchaseDrder class represents a ?whole? portion of the whole%part pattern and the ,DLineltem class represents the ?part? portion of the pattern. Also the Sale1entalLineltem class is the ?part? portion of "oth the Sales'ransaction and the 1ental'ransaction classes. 'he constraint notations associated with these sym"ols in /igures 8.B and 8.+F will "e discussed in detail in a later chapter. @asically$ this notation represents constraints placed on the o".ect connection relationship. /or e(ample$ the ?+..P? notation ne(t to the diamond sym"ol in /igure 8.B6s Aggregation D".ect association notation is to indicate how many ?whole? o".ects are associated with one ?part? o".ect. 'he ?F..P? notation at the "ottom of the same sym"ol in /igure 8.B is to indicate how many ?part? o".ects are associated with one ?whole? o".ect. !n /igure 8.+F the Lendor class has a relationship with the ,urchaseDrder class. Lendor represents "usinesses or individuals that the video store purchases inventory from. ,urchaseDrder represents a "usiness transaction and identifies inventory items that are purchased from a vendor. 'he Lendor to ,urchaseDrder relationship constraints in /igure 8.+F
71
indicate that a specific Lendor may have ero or more (represented "y the ?P?) ,urchaseDrders and a specific ,urchaseDrder is related to only one specific Lendor (represented "y the ?+?). /igure 8.+F6s video store M5L class diagram omitted information a"out attri"utes and operations simply "ecause ! wanted to get the entire class diagram into one figure. /igures 8.++a$"$ c e(pand upon /igure 8.+F "y including the attri"utes and operations. Additional diagram model details "ecome important and necessary at some su".ective point during systems analysis. Loo&ing at /igure 8.+F$ the M5L class diagram model has two additional levels of detail* (+) attri"utes$ and (0) operations. Attri"utes and operations help communicate more a"out what data (attri"utes) are associated with the information system$ and what functions (operations) are performed "y the information system. As you loo& at /igure6s 8.++a$" and c$ &eep in mind that these three figures are the e(act same model as shown in /igure 8.+F$ .ust with additional details. Due to the e(tent of the details$ the model was divided into three sections in order to fit on the pages of this "oo&. Msing a computer%"ased !D4 tool to draw this M5L class diagram$ you would have it all connected even though you might only see sections of the diagram at any moment in time on the computer6s monitor (screen). As descri"ed earlier$ attri"utes are characteristics that descri"e a class in more detail. Sometimes the name of a class$ such as StoreLocation in /igure 8.+F$ is not sufficient to communicate its intended purpose in the system. Loo&ing at this class6s attri"utes might help communicate its intended purpose. /or e(ample$ StoreLocation6s attri"utes are store:um"er$ storeAddress$ storeCity$ storeState$ storeQipcode$ and store,hone. 'he data values associated with these attri"utes indicate that the system needs to &eep trac& of the video store6s identification information for various reasons. Dne reason could "e to print it on certain reports. Another reason could "e the need to consolidate two or more video store6s data together in the information system and still "e a"le to electronically separate it into the data "elonging to each store.
72
Are the attri"utes shown in /igure 8.++a$"$c all of the attri"utes that this information system will have< ,ro"a"ly not> As the systems analyst progresses through analysis and into design$ additional attri"utes may surface and "ecome important to &eep trac& of and would "e added to the information system via a change to the applica"le M5L models with the user6s approval. Attri"utes are discussed in much more detail in a later chapter. Dperations$ as descri"ed earlier$ represent the transformations$ actions or functions that a particular class of o".ects must accomplish in order to help fulfill the overall mission of the information system. An operation is associated with one and only one class$ the one in the real world most closely associated with the function to "e performed. 'hat is why there are more operations in the 5em"er class than any of the other classes. Reep in mind that a mem"er initiates much of what happens in a video store$ and the F#ottoG of a class ,o*.ect- is F do it #$selfG. Are these all of the operations that this information system will have< ,ro"a"ly not> As the systems analyst progresses through analysis and into design$ additional operations may surface and "ecome important and required for the information system to accomplish its mission. 'hese newly discovered operations would "e added to the information system via a change to the appropriate M5L models$ similar to the way attri"utes are added$ with the user6s approval. Dperations are discussed in much more detail in a later chapter.
73
As you loo& at the details in /igure 8.++6s class diagram$ you will notice that several classes have no attri"utes and operations shown in them. /or e(ample$ Lideo$ Iame$ Concession!tem$ and LC1 have no attri"utes and no operations listed in their respective class sym"ols. 'his is o&ay since each of these classes is the Speciali7ation part of a Ienerali ation class relationship. n a !enerali7ation class relationship, all speciali7ation classes inherit all the attri*utes and all the operations fro# the generali7ation% 'herefore$ Concession!tem has the same attri"utes and operations as !nventory and Saleltem com"ined. LC1 has the same attri"utes and operations as !nventory and 1ental!tem com"ined. /inally$ Lideo and Iame have the same e(act attri"utes and operations as !nventory$ Sale!tem$ and 1ental!tem com"ined.
'his concludes the review of the video store M5L class diagram model. 1emem"er$ /igures 8.+F and 8.++ are o".ect%oriented and represent the very important foundational and static structure (architecture) of the proposed video storeSs information system. 'here are still several other M5L models to create that will collectively represent the T"lueprintsU for the video storeSs information system. 'he ne(t few chapters will e(plore the simplistic o".ect%oriented methodology activities descri"ed earlier in this chapter as it is used to create and refine the M5L notations and models for defining and documenting the requirements for an information system.
74
S1MMA25 'his chapter has defined and descri"ed a methodology as the way one thin&s a"out or performs an activity in order to complete it successfully. 4ach of four ma.or methodology classifications was presented and discussed=traditional$ structured analysis and design$ information engineering$ and o".ect oriented. 4ight foundational "uilding "loc& concepts=common methods of organi ation$ a"straction$ encapsulation$ inheritance$ polymorphism$ message communication$ associations$ and reuse=for an o".ect%oriented methodology were also presented and discussed. :ot all of them are new$ which is a good thing. Another fundamental concept of an o".ect%oriented methodology was presented and discussed=Classification 'heory. 'his theory is common to most people$ thus ma&ing its use within an o".ect%oriented methodology a more natural activity. /ollowing this$ a simplistic o".ect%oriented systems analysis and design methodology was presented and "riefly discussed. 5uch more will "e discussed and presented regarding this methodology throughout the remainder of the "oo&. Mnderstanding and &nowledge of a pro"lem domain along with understanding and e(perience using a methodology and notation are important for successfully documenting user requirements
75
for an information system. 'he M5LSs Class Diagram notation consists of several sym"ols including Class$ Ienerali ation class relationship$ D".ect Association$ D".ect Aggregate Association$ and D".ect Composite Association. A partially completed M5L Class Diagram of a video store information system pro"lem domain was presented to show how the M5L Class Diagram notation sym"ols are com"ined to depict the user6s requirements for an information system using a Class Diagram. /inally$ the Class Diagram model was e(panded to reveal attri"utes and operations along with a discussion of these model features H1ES' ONS ,note: Buestions with an asterisD CIC are new in this edition and have not *een answered8.+ 8.0 8.8 8.2 #hat is a methodology< @riefly discuss the different ways of acquiring a methodology. ;ow would you "est descri"e the traditional methodology classification< Iiven your answer to the previous question$ what is the ma.or disadvantage of this type of methodology< 8.3 #hy is the structured analysis and design methodology sometimes called the data flow modeling methodology< 8.) ;ow has computer%aided software engineering (CAS4) or !D4 changed the structured methodology< 8.E #hat pro"lem%solving approach is at the heart of an information modeling methodology< 8.G ;ow does an information modeling methodology differ from the approach used in a structured analysis and design methodology< 8.B ;ow does the approach ta&en in an o".ect%oriented methodology differ from strategies employed "y the information modeling methodology< 8.+F List and descri"e the eight foundational characteristics of an o".ect%oriented methodology. 8.++ #hat role does a"straction play in an o".ect%oriented methodology< 8.+0 #hat is another term for encapsulation$ and what is its purpose within an information system< 8.+8 #hat is one of the main advantages of reuse within an o".ect%oriented methodology< 8.+2 Discuss a few of the road"loc&s that are standing in the way of industry acceptance of reuse. 8.+3 #hat significant aspect of an o".ect%oriented methodology resolves pro"lems associated with the older methodologies< 8.+) #hat are the three concepts within Classification 'heory and how do they relate to o".ect%oriented methodology< 8.+E #hat is meant "y reuse< #hat role does it play in systems analysis and design< 8.+G :ame and discuss the different types of reuse that are possi"le. 8.+BP Descri"e the Mnified 5odeling Language (M5L). 8.0FPList and "riefly descri"e the "asic M5L notation sym"ols.
76
8.0+ !f you wanted to draw a picture of an information system$ what would you need$ at minimum$ to underta&e this tas&< 8.00 Define notation and "riefly e(plain its importance in modeling an information system. 8.08 Define and give a few e(amples of the class and class%with%o".ects notations. 8.02 #hat is the importance of the class and class%with%o".ects sym"ol notations within the pro"lem domain component of the o".ect model< 8.03 #hat are the two additional elements usually found within the class and class%with%o".ects notations and what is their purpose< 8.0)P#hat is the purpose of the generali ation class relationship within the M5L< 8.0E Distinguish the whole%part o".ect connection sym"ol from the generali ation%speciali ation connection sym"ol. 8.0GP#hat is the main purpose of the ?P? and ?+? notation in an o".ect association< 8.0B #hat is the nature of relationships as sym"oli ed "y the o".ect association< 8.8FPDefine parallelism$ su"stitution and omission as they relate to information systems development. 8.8+ #hy is it sometimes helpful to identify attri"utes within a class earlier than usually done< 8.80 #hat distinguishes an operation from an attri"ute within a class< 2E0E2ENCES Am"ler$ S.$ ?4nhancing the Mnified ,rocess?$ Software Development$ Dcto"er +BBB$ pp. 88%8B. @ahrami$ A.$ D".ect%Driented Systems Development Msing the Mnified 5odeling Language $ !rwin 5cIraw%;ill$ @oston$ 5A$ +BBB. @ooch$ I.$ 1um"augh$ J. and Jaco"son$ !.$ 'he Mnified 5odeling Language Mser Iuide $ Addison% #esley$ 1eading$ 5A$ +BBB$ !S@: 7 F%0F+%3E+)G%2. @ooch$ I.$ D".ect% Driented Analysis and Design with Applications (0nd ed). 5enlo ,ar&$ CA* @en.aminHCummings$ +BB2. ?Classification 'heory$? 4ncyclopedia @ritannica$ +BG). Coad$ :orth$ ,.$ D. and 5ayfield$ 5.$ D".ect 5odels* Strategies$ ,atterns$ and Applications . ,rentice ;all$ 4nglewood Cliffs$ :J$ +BB3. Coad$ ,.$ and Yourdon$ 4.$ D".ect% Driented Analysis (0nd ed.). 4nglewood Cliffs$ :J* Yourdon ,ressH,rentice ;all$ +BB+. Coad$ ,.$ and Yourdon$ 4.$ D".ect% Driented Design. 4nglewood Cliffs$ :J* Yourdon ,ressH ,rentice ;all$ +BB+.
77
Co($ @.J.$ D".ect% Driented ,rogramming* An 4volutionary Approach . 1eading$ 5A* Addison% #esley$ +BG). Dahl$ Dle%Johan and :ygaard$ Rristen$ ?Simula$ An Algol%@ased Simulation Language?$ Communications of the AC5$ Lol. B$ :o. B$ Septem"er +B))$ pp. )E+%)EG. 4ri&sson$ ;. and ,en&er$ 5.$ M5L 'ool&it $ John #iley O Sons$ :ew Yor&$ :Y$ +BBG. /iresmith$ D.I.$ ?@asic D".ect%Driented Concepts and 'erminology* A Comparison of 5ethods and Languages$? #hite ,aper from Advanced Software 'echnology Specialists (AS'S)$ /ort #ayne$ !:$ January 8$ +BB2$ 8E pages. /owler$ 5.$ M5L Distilled $ Addison%#esley$ 1eading$ 5assachusetts$ +BBE. ;enderson%Sellers$ @.$ A @oo& of D".ect% Driented Rnowledge . :ew Yor&* ,rentice%;all$ +BB0. Jaco"son$ !.$ @ooch$ I. and 1um"augh$ J.$ 'he Mnified Software Development ,rocess $ Addison% #esley$ 1eading$ 5A$ +BBB$ !S@: 7 F%0F+%3E+)B%0. Jaco"son$ !.$ C;1!S'41SD:$ 5.$ JD:SSD:$ ,. and DL41IAA1D$ I.$ D".ect% Driented Software 4ngineering. :ew Yor&* Addison%#esley$ +BB0. Ray$ Alan C.$ ?5icroelectronics and the ,ersonal Computer?$ Scientific American $ Lol. 08E$ :o. 8$ pp. 08F%022. Larman$ C.$ Applying M5L and ,atterns$ ,rentice%;all$ Mpper Saddle 1iver$ :J$ +BBG. 5eyer$ @.$ D".ect% Driented Software Construction . ;emel ;empstead$ Mnited Ringdom* ,rentice ;all$ +BGG. Dlle$ '.#.$ et al.$ !nformation Systems 5ethodologies* A /ramewor& for Mnderstanding . #o&ingham$ 4ngland* Addison%#esley$ +BGG. Dlle$ '.#$ Sol$ ;.I. and 'ully$ C.J. (eds.)$ !nformation Systems Design 5ethodologies* A /eature Analysis. Amsterdam* :orth%;olland ,u"lishing Co.$ +BG8. Dlle$ '.#$ Sol$ ;.I. and L411M:%S'MA1'$ A.A. (eds.)$ !nformation Systems Design 5ethodologies* A Comparative 1eview . Amsterdam* :orth%;olland ,u"lishing Co.$ +BG0.
78
Nuatrani$ '.$ Lisual 5odeling with 1ational 1ose and M5L $ Addison%#esley$ 1eading$ 5assachusetts$ +BBG. 1um"augh$ J.$ Jaco"son$ !. and @ooch$ I.$ 'he Mnified 5odeling Language 1eference 5anual $ Addison%#esley$ 1eading$ 5A$ +BBB$ !S@: 7 F%0F+%8FBBG%V. 1um"augh$ J.$ @laha$ 5.$ ,remerlani$ #.$ 4ddy$ /. and Lorensen , #.$ D".ect% Driented 5odeling and Design. :ew Yor&* ,rentice ;all$ +BB+. Shlaer$ S. and 54LLD1$ S.J.$ D".ect% Driented Systems Analysis* 5odeling the #orld in Data . 4nglewood Cliffs$ :J* Yourdon ,ressH,rentice ;all$ +BGG. #irfs%@roc&$ 1.!.$ #il&erson$ @. and #iener$ L.$ Designing D".ect%Driented Software . :ew Yor&* ,rentice ;all$ +BBF. Yourdon$ 4.$ D".ect% Driented Systems Design* An !ntegrated Approach . :ew Yor&* ,rentice ;all +BB2.
79

An Overview of Methodologies, Models and Notations

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

An Overview of Methodologies, Models and Notations

Diunggah oleh

Hak Cipta:

Format Tersedia

Chapter 3 Conceptual Design: An Overview of Methodologies, Models and Notations DES !

Su##ar$ Co##ent Methodologies

'(2EE C)ASS C C(A))EN!ES

N N0O2MA' ON S5S'EMS DE?E)O&MEN'

Anda mungkin juga menyukai